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 181 records · Page 10
All sourcesNASA NTRSDOE OSTI
NASA NTRS2003

Standards-and Component-Based Mission Operations Architecture at NASA's Goddard Space Flight Center

NASA Goddard Space Flight Center (GSFC) manages many of NASA s earth and space science satellite missions. A wide variety of commercial products and GSFC-developed software components are typically integrated into a unique system configuration for each mission. Independent development of the many mission operations center systems has led to systems that are expensive to integrate, difficult to infuse with new capabilities developed for other programs, and cumbersome to maintain. This traditional approach becomes even more problematic as NASA moves towards satellite constellations, new operations concepts, and even further budgets reductions. The GSFC Mission Services Evolution Center (GMSEC) is creating a new architecture for future missions at GSFC. Instead of selecting the best-in-class components and creating a standard control center system, GMSEC is developing component interface standards so that multiple products can plug-and-play into the configuration. Missions can then select the best components based on the merits of the product and not simply based on recent integration history at NASA. The GMSEC system utilizes a publish/subscribe information bus and standard XML-based key message interfaces. Functional components can either match directly to the interface standard, or adapters can be developed to match the product's interface to the GMSEC standard with out impacting the source product. Applications Program Interfaces (API's) are being developed to isolate the underlying middleware from the applications software and to allow the middleware product to be switched if necessary. Interface Control Documents (ICDs) between each pair of communicating components is replaced by a single message/API specification document. New applications must simply match to the information bus standards and need not worry about all of the other applications in the system. For legacy software, adapters can be developed to facilitate communications between the application and the information bus. As the approach has matured, it has become apparent that it can provide innovative solutions to some of the multi-satellite challenges facing GSFC.

Smith, Danford↗
NASA NTRS2011

Systems, methods and apparatus for generation and verification of policies in autonomic computing systems

Described herein is a method that produces fully (mathematically) tractable development of policies for autonomic systems from requirements through to code generation. This method is illustrated through an example showing how user formulated policies can be translated into a formal mode which can then be converted to code. The requirements-based programming method described provides faster, higher quality development and maintenance of autonomic systems based on user formulation of policies.Further, the systems, methods and apparatus described herein provide a way of analyzing policies for autonomic systems and facilities the generation of provably correct implementations automatically, which in turn provides reduced development time, reduced testing requirements, guarantees of correctness of the implementation with respect to the policies specified at the outset, and provides a higher degree of confidence that the policies are both complete and reasonable. The ability to specify the policy for the management of a system and then automatically generate an equivalent implementation greatly improves the quality of software, the survivability of future missions, in particular when the system will operate untended in very remote environments, and greatly reduces development lead times and costs.

Hinchey, Michael G.↗
NASA NTRS2013

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗
NASA NTRS2010

The Kepler Science Operations Center Pipeline Framework Extensions

The Kepler Science Operations Center (SOC) is responsible for several aspects of the Kepler Mission, including managing targets, generating on-board data compression tables, monitoring photometer health and status, processing the science data, and exporting the pipeline products to the mission archive. We describe how the generic pipeline framework software developed for Kepler is extended to achieve these goals, including pipeline configurations for processing science data and other support roles, and custom unit of work generators that control how the Kepler data are partitioned and distributed across the computing cluster. We describe the interface between the Java software that manages the retrieval and storage of the data for a given unit of work and the MATLAB algorithms that process these data. The data for each unit of work are packaged into a single file that contains everything needed by the science algorithms, allowing these files to be used to debug and evolve the algorithms offline.

Klaus, Todd C.↗
NASA NTRS2011

Safety and Mission Assurance: A NASA Perspective

Safety and Mission Assurance (S&MA) consists of the safety, reliability, maintainability, software assurance and quality disciplines, which are applied to reduce the probability of mishaps and ensure mission success. NASA uses a risk management process which requires various organizations to identify, analyze and mitigate/control risks associated with operations and decision making processes.

Higginbotham, Scott Alan↗
NASA NTRS2005

Apex Reference Manual 3.0 Beta

Apex is a toolkit for constructing software that behaves intelligently and responsively in demanding task environments. Reflecting its origin at NASA where Apex continues to be developed, current applications include: a) Providing autonomous mission management and tactical control capabilities for unmanned aerial vehicles including an autonomous surveillance helicopter and a simulation prototype of an unmanned fixed-wing aircraft to be used for wildfire mapping; b) Simulating human air traffic controllers, pilots and astronauts to help predict how people might respond to changes in equipment or procedures; and c) Predicting the precise duration and sequence of routine human behaviors based on a human-computer interaction engineering technique called CPM-GOMS. Among Apex s components are a set of implemented reasoning services, such as those for reactive planning and temporal pattern recognition; a software architecture that embeds and integrates these services and allows additional reasoning elements to be added as extensions; a formal language for specifying agent knowledge; a simulation environment to facilitate prototyping and analysis; and Sherpa, a set of tools for visualizing autonomy logic and runtime behavior. In combination, these are meant to provide a flexible and usable framework for creating, testing, and deploying intelligent agent software. Overall, our goal in developing Apex is to lower economic barriers to developing intelligent software agents. New ideas about how to extend or modify the system are evaluated in terms of their impact in reducing the time, expertise, and inventiveness required to build and maintain applications. For example, potential enhancements to the AI reasoning capabilities in the system are reviewed not only for usefulness and distinctiveness, but also for their impact on the readability and general usability of Apex s behavior representation language (PDL) and on the transparency of resulting behavior. A second central part of our approach is to iteratively refine Apex based on lessons learned from as diverse a set of applications as possible. Many applications have been developed by users outside the core development team including engineers, researchers, and students. Usability is thus a central concern for every aspect of Apex visible to a user, including PDL, Sherpa, the Apex installation process, APIs, and user documentation. Apex users vary in their areas of expertise and in their familiarity with autonomy technology. Focusing on usability, a development philosophy summarized by the project motto "Usable Autonomy," has been important part of enabling diverse users to employ Apex successfully and to provide feedback needed to guide iterative, user-centered refinement.

Freed, Michael A.↗
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 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 NTRS1972

Space shuttle orbiter guidance, naviagation and control software functional requirements: Horizontal flight operations

The shuttle GN&C software functions for horizontal flight operations are defined. Software functional requirements are grouped into two categories: first horizontal flight requirements and full mission horizontal flight requirements. The document privides the intial step in the shuttle GN&C software design process. It also serves as a management tool to identify analyses which are required to define requirements.

Source record↗
NASA NTRS2011

Planning the FUSE Mission Using the SOVA Algorithm

Three documents discuss the Sustainable Objective Valuation and Attainability (SOVA) algorithm and software as used to plan tasks (principally, scientific observations and associated maneuvers) for the Far Ultraviolet Spectroscopic Explorer (FUSE) satellite. SOVA is a means of managing risk in a complex system, based on a concept of computing the expected return value of a candidate ordered set of tasks as a product of pre-assigned task values and assessments of attainability made against qualitatively defined strategic objectives. For the FUSE mission, SOVA autonomously assembles a week-long schedule of target observations and associated maneuvers so as to maximize the expected scientific return value while keeping the satellite stable, managing the angular momentum of spacecraft attitude- control reaction wheels, and striving for other strategic objectives. A six-degree-of-freedom model of the spacecraft is used in simulating the tasks, and the attainability of a task is calculated at each step by use of strategic objectives as defined by use of fuzzy inference systems. SOVA utilizes a variant of a graph-search algorithm known as the A* search algorithm to assemble the tasks into a week-long target schedule, using the expected scientific return value to guide the search.

Lanzi, James↗
NASA NTRS2009

Recent Electric Propulsion Development Activities for NASA Science Missions

(The primary source of electric propulsion development throughout NASA is managed by the In-Space Propulsion Technology Project at the NASA Glenn Research Center for the Science Mission Directorate. The objective of the Electric Propulsion project area is to develop near-term electric propulsion technology to enhance or enable science missions while minimizing risk and cost to the end user. Major hardware tasks include developing NASA s Evolutionary Xenon Thruster (NEXT), developing a long-life High Voltage Hall Accelerator (HIVHAC), developing an advanced feed system, and developing cross-platform components. The objective of the NEXT task is to advance next generation ion propulsion technology readiness. The baseline NEXT system consists of a high-performance, 7-kW ion thruster; a high-efficiency, 7-kW power processor unit (PPU); a highly flexible advanced xenon propellant management system (PMS); a lightweight engine gimbal; and key elements of a digital control interface unit (DCIU) including software algorithms. This design approach was selected to provide future NASA science missions with the greatest value in mission performance benefit at a low total development cost. The objective of the HIVHAC task is to advance the Hall thruster technology readiness for science mission applications. The task seeks to increase specific impulse, throttle-ability and lifetime to make Hall propulsion systems applicable to deep space science missions. The primary application focus for the resulting Hall propulsion system would be cost-capped missions, such as competitively selected, Discovery-class missions. The objective of the advanced xenon feed system task is to demonstrate novel manufacturing techniques that will significantly reduce mass, volume, and footprint size of xenon feed systems over conventional feed systems. This task has focused on the development of a flow control module, which consists of a three-channel flow system based on a piezo-electrically actuated valve concept, as well as a pressure control module, which will regulate pressure from the propellant tank. Cross-platform component standardization and simplification are being investigated through the Standard Architecture task to reduce first user costs for implementing electric propulsion systems. Progress on current hardware development, recent test activities and future plans are discussed.

Pencil, Eric J.↗
NASA NTRS2024

ISS Technology Demonstrations for Future Spaceflight Medical Systems

Throughout the history of human spaceflight, crewmembers have experienced various in-flight medical conditions including illness and injury. Planned missions to the Moon and Mars will require capabilities to maintain the health of future space travelers. Mass, power, and volume available in the vehicles and habitats for these missions will be severely constrained; resupply of resources will be limited or non-existent, as will opportunities for evacuation to Earth. Furthermore, ground-based support will be hampered by communication latencies and blackouts. These vehicle and mission constraints will necessitate a medical system that has been efficiently planned, providing on-board procedural guidance in addition to a variety of medical devices and consumable resources. Medical capabilities required for the diagnosis and treatment of potential medical conditions during future spaceflight missions may include real-time health monitoring, medical imaging, and biomarker analyses ( e.g., blood or urine). Terrestrial medicine shares these needs, thus many of these medical capabilities could likely be satisfied by Commercial-Off-The-Shelf (COTS) devices and methodologies; however, in some cases the unique space environment and increased mission duration will drive the need to modify technologies and the way care is provided. NASA’s Human Research Program (HRP) Exploration Medical Capability (ExMC) Element and Mars Campaign Office’s Exploration Medical Integrated Product Team (XMIPT) are working together to decrease medical risk during exploration missions. Flight-tested medical diagnostic and treatment technologies are necessary to effectively manage medical conditions relevant to exploration missions while meeting vehicle constraints, integrating with medical decision-support tools, and enabling increasingly Earth-independent operations. Several projects have leveraged the ISS as a testbed for exploration, including 1) i n- situ blood analysis, 2) medical inventory, 3) intravenous fluid generation, and 4) autonomous medical procedure guidance. Management of several in-flight medical conditions, such as bacterial and viral infections and acute radiation syndrome, is dramatically improved with ability to assess blood cell populations, electrolytes, and metabolites. I n December 2020 and January 2021 ExMC performed an ISS technology demonstration (Tech Demo) of the HemoCue® WBC DIFF analyzer (HemoCue, Brea, CA), a COTS device that was modified to enable functionality in a spaceflight environment. This Tech Demo marked the first time that hematology measurements were successfully performed real-time in microgravity. Also modified and demonstrated was the reusable Handheld Electrolytes and Lab Technology for Humans (rHEALTH) ONE analyzer (rHEALTH, Bedford, MA), which uses flow cytometry and sheath-based hydrodynamic focusing methodologies. The rHEALTH ONE ISS Tech Demo in May 2022 demonstrated test results obtained in-flight matched those on the ground. NASA currently relies on crew self-reporting to manage and maintain medical inventory on ISS.The ability to maintain an accurate inventory becomes more critical during long duration missions since the crew will need to be increasingly autonomous in finding and utilizing medical items, including those scenarios when alternative treatments need to be considered due to limited or no resupply. HRP’s Medical Consumables Tracking (MCT) project was developed by ZIN Technologies, Inc. (Cleveland, OH), and demonstrated real-time tracking of medical supplies aboard the ISS between December 2016 and July 2018. The MCT system design utilized Radio Frequency Identification Device (RFID) technology to perform automated inventory and was installed in the Crew Health Care System (CHeCS) Resupply Stowage Rack (RSR). The challenge of limited shelf life, exacerbated by the lack of resupply opportunities, affects a plethora of medical system components including consumables, pharmaceuticals, and intravenous (IV) fluid. In 2010, ExMC funded ZIN Technologies, Inc. (Cleveland, OH), to develop the Intravenous Fluid Generation (IVGEN) system. IV fluids were successfully generated with IVGEN using the potable water supply on ISS during ISS Expedition 23. The XMIPT is in the process of developing a miniaturized version of the original IVGEN hardware for a future Tech Demo aboard the ISS. Current ISS medical operations rely heavily on preflight training and real-time remote guidance, both of which become impractical or impossible for exploration missions. The primary goal of the Autonomous Medical Officer Support (AMOS) Software Tech Demos on ISS was to confirm telemedical proof-of-concept for autonomous medical imaging in an operational setting. This novel software tool shifts emphasis from preflight training and real-time remote guidance to in-flight just-in-time instruction, a new and necessary paradigm for crew medical autonomy. AMOS introduces a novel, streamlined skill management concept for exploration missions featuring comprehensive training and guidance modules for ultrasound examinations using the ISS Ultrasound 2 (a modified GE Vivid-q™; General Electric HealthCare, Chicago, IL). With no prior crew training or remote guidance, two Tech Demos on the ISS (April 2020 and June 2022) resulted in high quality, clinically useful image sets. We will provide a review of historical, current, and planned medical devices and technologies considered for inclusion within future spaceflight medical systems and summarize hardware development activities and medical device tech demos conducted on the ISS.

Astronaut health and performance↗
NASA NTRS2008

Proven and Robust Ground Support Systems - GSFC Success and Lessons Learned

Over the past fifteen years, Goddard Space Flight Center has developed several successful science missions in-house: the Wilkinson Microwave Anisotropy Probe (WMAP), the Imager for Magnetopause-to-Aurora Global Exploration (IMAGE), the Earth Observing 1 (EO-1) [1], and the Space Technology 5 (ST-5)[2] missions, several Small Explorers, and several balloon missions. Currently in development are the Solar Dynamics Observatory (SDO) [3] and the Lunar Reconnaissance Orbiter (LRO)[4]. What is not well known is that these missions have been supported during spacecraft and/or instrument integration and test, flight software development, and mission operations by two in house satellite Telemetry and Command (T & C) Systems, the Integrated Test and Operations System (ITOS) and the Advanced Spacecraft Integration and System Test (ASIST). The advantages of an in-house satellite Telemetry and Command system are primarily in the flexibility of management and maintenance - the developers are considered a part of the mission team, get involved early in the development process of the spacecraft and mission operations-control center, and provide on-site, on-call support that goes beyond Help Desk and simple software fixes. On the other hand, care must be taken to ensure that the system remains generic enough for cost effective re-use from one mission to the next. The software is designed such that many features are user-configurable. Where user-configurable options were impractical, features were designed so as to be easy for the development team to modify. Adding support for a new ground message header, for example, is a one-day effort because of the software framework on which that code rests. This paper will discuss the many features of the Goddard satellite Telemetry and Command systems that have contributed to the success of the missions listed above. These features include flexible user interfaces, distributed parallel commanding and telemetry decommutation, a procedure language, the interfaces and tools needed for a high degree of automation, and instantly accessible archives of spacecraft telemetry. It will discuss some of the problems overcome during development, including secure commanding over networks or the Internet, constellation support for the three satellites that comprise the ST-5 mission, and geographically distributed telemetry end users.

Pfarr, Barbara↗
NASA NTRS2007

Automatic Command Sequence Generation

Automatic Sequence Generator (Autogen) Version 3.0 software automatically generates command sequences for the Mars Reconnaissance Orbiter (MRO) and several other JPL spacecraft operated by the multi-mission support team. Autogen uses standard JPL sequencing tools like APGEN, ASP, SEQGEN, and the DOM database to automate the generation of uplink command products, Spacecraft Command Message Format (SCMF) files, and the corresponding ground command products, DSN Keywords Files (DKF). Autogen supports all the major multi-mission mission phases including the cruise, aerobraking, mapping/science, and relay mission phases. Autogen is a Perl script, which functions within the mission operations UNIX environment. It consists of two parts: a set of model files and the autogen Perl script. Autogen encodes the behaviors of the system into a model and encodes algorithms for context sensitive customizations of the modeled behaviors. The model includes knowledge of different mission phases and how the resultant command products must differ for these phases. The executable software portion of Autogen, automates the setup and use of APGEN for constructing a spacecraft activity sequence file (SASF). The setup includes file retrieval through the DOM (Distributed Object Manager), an object database used to store project files. This step retrieves all the needed input files for generating the command products. Depending on the mission phase, Autogen also uses the ASP (Automated Sequence Processor) and SEQGEN to generate the command product sent to the spacecraft. Autogen also provides the means for customizing sequences through the use of configuration files. By automating the majority of the sequencing generation process, Autogen eliminates many sequence generation errors commonly introduced by manually constructing spacecraft command sequences. Through the layering of commands into the sequence by a series of scheduling algorithms, users are able to rapidly and reliably construct the desired uplink command products. With the aid of Autogen, sequences may be produced in a matter of hours instead of weeks, with a significant reduction in the number of people on the sequence team. As a result, the uplink product generation process is significantly streamlined and mission risk is significantly reduced. Autogen is used for operations of MRO, Mars Global Surveyor (MGS), Mars Exploration Rover (MER), Mars Odyssey, and will be used for operations of Phoenix. Autogen Version 3.0 is the operational version of Autogen including the MRO adaptation for the cruise mission phase, and was also used for development of the aerobraking and mapping mission phases for MRO.

Fisher, Forest↗
NASA NTRS2021

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service.Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations.The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-to-station handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an in-orbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗
NASA NTRS2002

Restoring Redundancy to the MAP Propulsion System

The Microwave Anisotropy Probe (MAP) is a follow-on to the Differential Microwave Radiometer (DMR) instrument on the Cosmic Background Explorer (COBE). Due to the MAP project's limited mass, power, and financial resources, a traditional reliability concept including fully redundant components was not feasible. The MAP design employs selective hardware redundancy, along with backup software modes and algorithms, to improve the odds of mission success. In particular, MAP's propulsion system, which is used for orbit maneuvers and momentum management, uses eight thrusters positioned and oriented in such a way that its thruster-based attitude control modes can maintain three-axis attitude control in the event of the failure of any one thruster.

O'Donnell, James R., Jr.↗
NASA NTRS2003

Agent-Supported Mission Operations Teamwork

This slide presentation reviews the development of software agents to support of mission operations teamwork. The goals of the work was to make automation by agents easy to use, supervise and direct, manage information and communication to decrease distraction, interruptions, workload and errors, reduce mission impact of off-nominal situations and increase morale and decrease turnover. The accomplishments or the project are: 1. Collaborative agents - mixed initiative and creation of instructions for mediating agent 2. Methods for prototyping, evaluating and evolving socio-technical systems 3. Technology infusion: teamwork tools in mISSIons 4. Demonstrations in simulation testbed An example of the use of agent is given, the use of an agent to monitor a N2 tank leak. An incomplete instruction to the agent is handled with mediating assistants, or Intelligent Briefing and Response Assistant (IBRA). The IBRA Engine also watches data stream for triggers and executes Act-Whenever actions. There is also a Briefing and Response Instruction (BRI) which is easy for a discipline specialist to create through a BRI editor.

Malin, Jane T.↗
NASA NTRS2021

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service. Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations. The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-tostation handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an inorbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗