Search NASA⌕ Search

SEARCH · Search NASA

Results for “ground operational support system”

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

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

At least 145 records · Page 8

Delay/Disruption Tolerant Networking for the International Space Station (ISS)

Disruption Tolerant Networking (DTN) is an emerging data networking technology designed to abstract the hardware communication layer from the spacecraft/payload computing resources. DTN is specifically designed to operate in environments where link delays and disruptions are common (e.g., space-based networks). The National Aeronautics and Space Administration (NASA) has demonstrated DTN on several missions, such as the Deep Impact Networking (DINET) experiment, the Earth Observing Mission 1 (EO-1) and the Lunar Laser Communication Demonstration (LLCD). To further the maturation of DTN, NASA is implementing DTN protocols on the International Space Station (ISS). This paper explains the architecture of the ISS DTN network, the operational support for the system, the results from integrated ground testing, and the future work for DTN expansion.

Schlesinger, Adam↗

APRES Prototype Mission Planner System Demonstration

Activity Planning with Resources for the Exploration of Space (APRES) is a mixed-initiative mission planning system for ground operations. APRES has been designed to support multi-spacecraft missions. The APRES Interface is browser-based and includes a plan editor, a timeline plan display, a temporal constraint editor, display of the state and numeric chronicles, and a violation resolution manager. Automation support is supplied by the APRES Service, which includes components that provide the following capabilities:(1) plan simulation, which determines the state and numeric chronicles (values of the model variables over time) and determines when "processes" are triggered and terminated based on world states in the execution trace, (2) violation detection of constraints and flight rules encoded in the domain model, and of the temporal constraints created by the user, (3) violation resolution suggestions as to how to fix the plan's violations via rescheduling. The user controls when and how to utilize the automation support. Demo video included with paper, runtime 8:54 in color with sound.

John L. Bresina↗

Ground and Onboard Automated Scheduling for the Mars 2020 Rover Mission

The Mars 2020 Rover mission is using automated scheduling in two capacities. As of March 2021 a ground-based scheduler automatically schedules rover wake/sleep and preheats to support Mars 2020 daily operations. Included in the ground system is an explainable scheduling tool that allows users in-sight into the schedule developed by the automated scheduler. An onboard scheduler that will allow the rover autonomously better account for variations in execution is in development for use later in the mission.

Towey, Shannon↗

X-57 Cockpit Interface Control Document (ICD-CEPT-006)

The Cockpit Interface Control Document defines the hardware interfaces between the X-57 cockpit and subsystems. It provides locational and operational information in support of ground and flight operations with details on controls and displays that include Modes of Operation, Start-Up and Shut- Down Sequence diagrams and captures the current state of the MOD II Avionics Power Architecture. There is also preliminary information of the MOD III and MOD IV configurations. Microsoft PowerPoint was chosen for the document as early development required frequent meetings with multiple customers including aircraft operators (pilots), ground operations, support contractors and power, instrumentation, and human systems integration engineers and PowerPoint enabled presentations that could be quickly modified based on customer and developer interaction. One of the driving requirements for the cockpit design was to keep the left side panel as close the stock Tecnam panel as possible to reduce the failure risk of flight critical indicators. The original annunciator panel in the left side panel was modified to alert the pilot to failures in critical X-57 subsystems and an operator audio alert capability was added for these subsystems. Power-Up switches for the aircraft low voltage 13.8 VDC systems are located at the bottom of the left side panel and center panel, the same location as the stock Tecnam 13.8 VDC switches. The switches for energizing the high voltage system were located in the overhead panel to reduce the risk of inadvertently energizing the high voltage system during the low voltage power-up sequence. The Cruise Motor ARM switches were also located in the overhead panel and correspond to the same location as the stock Tecnam ignition switches. The stock Tecnam throttle levers and prop pitch levers were retained for the X-57. The throttle levers were renamed torque levers since they controlled the commanded torque to the cruise motors. The prop pitch levers provide a commanded RPM signal to an electronic prop pitch controller. X-57 specific displays, located in the right-side panel, are driven by dedicated sensors that monitor right and left side cruise motor RPM, right and left high voltage “Traction Bus” A and B (voltage, current and power) and the Avionics Bus DC converters (A and B) voltage and current. An X-57 Multi-Function Display (MFD) located in the center panel displays CAN Bus parameters. CAN Bus architecture is not certified for flight so these displays could not be used for safety critical information but were designed to be used for test point information only.

Laura Kushner↗

Reliability, Maintainability, and Availability: Consideration During the Design Phase in Ground Systems to Ensure Successful Launch Support

The future of Space Exploration includes missions to the moon, asteroids, Mars, and beyond. To get there, the mission concept is to launch multiple launch vehicles months, even years apart. In order to achieve this, launch vehicles, payloads (satellites and crew capsules), and ground systems must be highly reliable and/or available, to include maintenance concepts and procedures in the event of a launch scrub. In order to achieve this high probability of mission success, Ground Systems Development and Operations (GSDO) has allocated Reliability, Maintainability, and Availability (RMA) requirements to all hardware and software required for both launch operations and, in the event of a launch scrub, required to support a repair of the ground systems, launch vehicle, or payload. This is done concurrently with the design process (30/60/90 reviews).

Gillespie, Amanda M.↗

Multi-Spacecraft Autonomous Positioning System

As the number of spacecraft in simultaneous operation continues to grow, there is an increased dependency on ground-based navigation support. The current baseline system for deep space navigation utilizes Earth-based radiometric tracking, requiring long-duration observations to perform orbit determination and generate a state update. The age, complexity, and high utilization of the ground assets pose a risk to spacecraft navigation performance. In order to perform complex operations at large distances from Earth, such as extraterrestrial landing and proximity operations, autonomous systems are required. With increasingly complex mission operations, the need for frequent and Earth-independent navigation capabilities is further reinforced. The Multi-spacecraft Autonomous Positioning System (MAPS) takes advantage of the growing interspacecraft communication network and infrastructure to allow for Earth-autonomous state measurements to enable network-based space navigation. A notional concept of operations is given in figure 1. This network is already being implemented and routinely used in Martian communications through the use of the Mars Reconnaissance Orbiter and Mars Odyssey spacecraft as relays for surface assets. The growth of this communications architecture is continued through MAVEN, and future potential commercial Mars telecom orbiters. This growing network provides an initial Marslocal capability for inter-spacecraft communication and navigation. These navigation updates are enabled by cross-communication between assets in the network, coupled with onboard navigation estimation routines to integrate packet travel time to generate ranging measurements. Inter-spacecraft communication allows for frequent state broadcasts and time updates from trusted references. The architecture is a software-based solution, enabling its implementation on a wide variety of current assets, with the operational constraints and measurement accuracy determined by onboard systems.

Anzalone, Evan↗

Mars Reconnaissance Orbiter, Ground Data System, Receivables and Deliverables (REC/DELs)

This paper presents one JPL element manager's approach to describe a complex Ground Data System (GDS) with its receivables and deliverables (REC/DEL). The Mars Reconnaissance Orbiter (MRO) Ground Data System is the integrated set of ground software, hardware, facilities and networks that support mission operation. REC/DEL is a powerful tool for specifying hierarchy of commitments among systems and teams. Receivable of a system is a deliverable of another system. Focusing on tangible products enables the manager to objectively measure progress in a schedule. Jet Propulsion Laboratory mandates the use of REC/DEL for flight projects. Tutorial and training is provided for managers to create integrated REC/DEL database using automated systems. Project schedules are based on REC/DELs. This paper is not focusing on the mechanics of REC/DEL database creation, but it provides a guideline how one systematically creates categories of deliverables and receivables for ground data system components.

guidelines↗

Mars Reconnaissance Orbiter, Ground Data System, Receivables and Deliverables (REC/DELs)

This paper presents one JPL element manager's approach to describe a complex Ground Data System (GDS) with its receivables and deliverables (REC/DEL). The Mars Reconnaissance Orbiter (MRO) Ground Data System is the integrated set of ground software, hardware, facilities and networks that support mission operation. REC/DEL is a powerful tool for specifying hierarchy of commitments among systems and teams. Receivable of a system is a deliverable of another system. Focusing on tangible products enables the manager to objectively measure progress in a schedule. The Jet Propulsion Laboratory mandates the use of REC/DEL for flight projects. Tutorial and training is provided for managers to create an integrated REC/DEL database using automated systems. Project schedules are based on REC/DELs. This paper is not focusing on the mechanics of REC/DEL database creation, but it provides a guideline how one systematically creates categories of deliverables and receivables for ground data system components...

ground data system (GDS)↗

Exploration Technologies for Operations

Although the International Space Station (ISS) assembly has been completed, the Operations support teams continue to seek more efficient and effective ways to prepare for and conduct the ISS operations and future exploration missions beyond low earth orbit. This search for improvement has led to a significant collaboration between the NASA research and advanced software development community at NASA Ames Research Center and the Mission Operations community at NASA Johnson Space Center. Since 2001, NASA Ames Research Center has been developing and applying its advanced intelligent systems and human systems integration research to mission operations tools for several of the unmanned Mars missions operations. Since 2006, NASA Ames Research Center has also been developing and applying its advanced intelligent systems and human systems integration research to mission operations tools for manned operations support with the Mission Operations Directorate at NASA Johnson Space Center. This paper discusses the completion of the development and deployment of a variety of intelligent and human systems technologies adopted for manned mission operations. The technologies associated with the projects include advanced software systems for operations and human-centered computing. Human-centered computing looks to the processes and procedures that people do to perform any given job, then attempts to identify opportunities to improve these processes and procedures. In particular, for mission operations, improvements are quantified by specifically identifying how a tool can increase a persons efficiency, enhance a persons functional capability, andor improve the assurance of a persons decisions. The Ames development team has collaborated with the Mission Operations team to identify areas of efficiencies through technology infusion applications in support of the Plan, Train, and Fly activities of human-spaceflight mission operations. The specific applications discussed in this paper are in the areas of mission planning systems, mission operations design modeling and workflow automation, advanced systems monitoring, mission control technologies, search tools, training management tools, spacecraft solar array management, spacecraft power management, and spacecraft attitude planning. We discuss these specific projects between the Ames Research Center and the Johnson Space Centers Mission Operations Directorate, and how these technologies and projects are enhancing the mission operations support for the International Space Station. We also discuss the challenges, problems, and successes associated with long-distance and multi-year development projects between the research team at Ames and the Mission Operations customers at Johnson Space center. Finally, we discuss how these technology infusion applications and underlying technologies might be used in the future to support on-board operations of the crew and spacecraft systems as human exploration expands beyond low earth orbit to destinations in the solar system where communications delays will require more on-board autonomy and planning by the crew. Longer communications delays will require that the ground mission operations support will be primarily strategic in nature, while the tactical level of planning, systems monitoring and control, and failure analysisisolationrecovery will be the responsibility of both the spacecraft autonomous systems and the crew. Our expectation is that the technologies

mission operations↗

Mars Observer screen display design for a multimission environment

The Multi Mission Control Team (MMCT) is responsible for support to real time operations of the Mars Observer Mission. The team has the responsibility for monitoring the ground data system for the integrity of the telemetry and command data links. It also supports the Mars Observers Spacecraft Team in monitoring spacecraft events. The Data Monitor and Display subsystem (DMD) workstation provides the data interface with the ground data system. DMD workstation displays were developed to support the Mission Controllers in accomplishing their assigned tasks for supporting the Mars Observer mission. The display design concepts that were used in the Mar Observer MMCT displays to minimize the cognitive demands on the controllers and enhance the MMCT operations were presented. The Data Monitor and Display subsystem (DMD) is the controllers window into the spacecraft and the ground data system. The DMD is a workstation that provides a variety of formatted data displays to the controller. The displays present both spacecraft telemetry data and ground system monitor data. Some displays are preplanned and developed prior to the operations in which they are used. These are called fixed displays and are quite versatile in format and content. Other displays and plots can be created in real time. These displays have limited formats but flexibility in content. These are called list or message displays. They can be rapidly generated by the controller as needed. The MMCT display repertoire provides a mix of displays appropriate to the needs of the MMCT controllers.

Chafin, Roy L.↗

The IOAG Recommendations on Spacecraft Emergency Cross Support

In 2014, the Inter-agency Operations Advisory Group (IOAG) chartered a multi-agency team effort to study how to best handle spacecraft emergency as part of cross support among network assets. The original intent is to put in place for the first time a process and guidelines to make emergency support as part of a permanent cross-support capability between space agencies. From the perspective of space communications service providers, a few key issues, common to all agencies, concerning the Spacecraft Emergency Cross Support (SECS) have been explored. They are: context of emergency support, provision of emergency support under a cross-support agreement, provision of emergency support with no cross-support agreement, legal and liability issues, response time, support priority, services provided, sustaining emergency support capabilities, and charge for the support. The positions of the various participating agencies with respect to these issues have been collected, analyzed, and finally harmonized to form the recommended IOAG positions. A central challenge most communications service providers are facing is that since the spacecraft emergency is an unplanned critical event, it typically requires fast response to the emergency call, hence lacking an international standard process for the operational interfaces seems to exacerbate the difficulty in providing SECS. For reducing the response time, i.e. from the time of accepting a request for SECS to the readiness for support, it is recommended that a “cross-support emergency system” be established by IOAG member agencies. Along with it, the IOAG core services, just-in-time ground communications line, cross support service management (CSSM), and standard operations procedures (SOP) for operational interfaces form the basic foundation of the “cross support emergency system”. Of the above, new to the cross support conducted thus far in the IOAG community is the concept of the SOP specifically for the interfaces between the service provider and service user during the SECS. Use cases, salient features, and definition of the key operational activities/tasks relevant to the interfaces are addressed by the effort. Underpinning such a system is the availability of the RF license granted by the local authority, at national and/or regional level, for a given ground station to communicate with and track the spacecraft in emergency mode at the uplink and downlink frequencies assigned to that spacecraft. That means it is critical for the IOAG member agencies to obtain a priori all-band licenses (for the entire X-band or S-band) for some, if not all, of their ground stations that are most capable of or likely to provide SECS. It is also recommended that certain prior arrangements be made with the relevant local licensing authorities for a process that will allow expedited authorization to transmit/receive signals to/from the declared spacecraft over the declared ground stations specifically and solely for the emergency case. Our analysis of the SECS has also uncovered a few fundamental programmatic issues. Recognizing any IOAG positions reached on these issues do not necessarily lead to any binding authority, it is recommended that they, along with those key attributes of the cross support emergency system, be explicitly stated as multi-agency guidelines to guide the implementation and provision of the SECS. The paper will present the results of the working group on Spacecraft Emergency Cross Support and, in particular, its findings, products and recommendations. It will also identify the next steps of this work that may include the production of some international standards as an extension of this work, or the process to make this emergency system usable by other spacecraft operators beyond the space agencies.

Tai, Wallace S.↗

The IOAG Recommendations on Spacecraft Emergency Cross Support

In 2014, the Inter-agency Operations Advisory Group (IOAG) chartered a multi-agency team effort to study how to best handle spacecraft emergency as part of cross support among network assets. The original intent is to put in place for the first time a process and guidelines to make emergency support as part of a permanent cross-support capability between space agencies. From the perspective of space communications service providers, a few key issues, common to all agencies, concerning the Spacecraft Emergency Cross Support (SECS) have been explored. They are: context of emergency support, provision of emergency support under a cross-support agreement, provision of emergency support with no cross-support agreement, legal and liability issues, response time, support priority, services provided, sustaining emergency support capabilities, and charge for the support. The positions of the various participating agencies with respect to these issues have been collected, analyzed, and finally harmonized to form the recommended IOAG positions. A central challenge most communications service providers are facing is that since the spacecraft emergency is an unplanned critical event, it typically requires fast response to the emergency call, hence lacking an international standard process for the operational interfaces seems to exacerbate the difficulty in providing SECS. For reducing the response time, i.e. from the time of accepting a request for SECS to the readiness for support, it is recommended that a “cross-support emergency system” be established by IOAG member agencies. Along with it, the IOAG core services, just-in-time ground communications line, cross support service management (CSSM), and standard operations procedures (SOP) for operational interfaces form the basic foundation of the “cross support emergency system”. Of the above, new to the cross support conducted thus far in the IOAG community is the concept of the SOP specifically for the interfaces between the service provider and service user during the SECS. Use cases, salient features, and definition of the key operational activities/tasks relevant to the interfaces are addressed by the effort. Underpinning such a system is the availability of the RF license granted by the local authority, at national and/or regional level, for a given ground station to communicate with and track the spacecraft in emergency mode at the uplink and downlink frequencies assigned to that spacecraft. That means it is critical for the IOAG member agencies to obtain a priori all-band licenses (for the entire X-band or S-band) for some, if not all, of their ground stations that are most capable of or likely to provide SECS. It is also recommended that certain prior arrangements be made with the relevant local licensing authorities for a process that will allow expedited authorization to transmit/receive signals to/from the declared spacecraft over the declared ground stations specifically and solely for the emergency case. Our analysis of the SECS has also uncovered a few fundamental programmatic issues. Recognizing any IOAG positions reached on these issues do not necessarily lead to any binding authority, it is recommended that they, along with those key attributes of the cross support emergency system, be explicitly stated as multi-agency guidelines to guide the implementation and provision of the SECS. The paper will present the results of the working group on Spacecraft Emergency Cross Support and, in particular, its findings, products and recommendations. It will also identify the next steps of this work that may include the production of some international standards as an extension of this work, or the process to make this emergency system usable by other spacecraft operators beyond the space agencies.

Tai, Wallace S.↗

Development and Evaluation of an Airborne Separation Assurance System for Autonomous Aircraft Operations

NASA Langley Research Center is developing an Autonomous Operations Planner (AOP) that functions as an Airborne Separation Assurance System for autonomous flight operations. This development effort supports NASA s Distributed Air-Ground Traffic Management (DAG-TM) operational concept, designed to significantly increase capacity of the national airspace system, while maintaining safety. Autonomous aircraft pilots use the AOP to maintain traffic separation from other autonomous aircraft and managed aircraft flying under today's Instrument Flight Rules, while maintaining traffic flow management constraints assigned by Air Traffic Service Providers. AOP is designed to facilitate eventual implementation through careful modeling of its operational environment, interfaces with other aircraft systems and data links, and conformance with established flight deck conventions and human factors guidelines. AOP uses currently available or anticipated data exchanged over modeled Arinc 429 data buses and an Automatic Dependent Surveillance Broadcast 1090 MHz link. It provides pilots with conflict detection, prevention, and resolution functions and works with the Flight Management System to maintain assigned traffic flow management constraints. The AOP design has been enhanced over the course of several experiments conducted at NASA Langley and is being prepared for an upcoming Joint Air/Ground Simulation with NASA Ames Research Center.

Barhydt, Richard↗

Flight operations.

Flight operations for manned spacecraft covering mission planning, flight control systems and operations and recovery phase

SPACECRAFT CONTROL↗

Automated support for system's engineering and operations - The development of new paradigms

Technological developments in spacecraft ground operations are reviewed. The technological, operations-oriented, managerial, and economic factors driving the evolution of the Mission Operations Control Center (MOCC), and its predecessor the Operational Control Center are examined. The functional components of the various MOCC subsystems are outlined. A brief overview is given of the concepts behind the The Knowledge-Based Software Engineering Environment, the Generic Spacecraft Analysis Assistant, and the Knowledge From Pictures tool.

Truszkowski, Walt↗

Mission operations and data systems

A communications system for performing the basic functions of mission operations, orbit and attitude determination, and data processing is described. A block diagram is provided to show the relationships of these functions with the spacecraft in orbit and the experiments to be conducted on board the spacecraft. Specific areas of application are discussed as follows: (1) software operating systems for the ATS-F satellite testing and ground support, (2) inversion of the RAE-1 satellite (Explorer 38 satellite) in orbit, (3) ALSEP differential Doppler tracking, (4) minitrack calibration using satellite data, (5) angles-only orbit extraction, and (6) image processing system performance prediction and product quality evaluation techniques. Block diagrams of the various systems are provided to show the steps involved in the operations.

Source record↗

Operational Assessment of Apollo Lunar Surface Extravehicular Activity

Quantifying the operational variability of extravehicular activity (EVA) execution is critical to help design and build future support systems to enable astronauts to monitor and manage operations in deep-space, where ground support operators will no longer be able to react instantly and manage execution deviations due to the significant communication latency. This study quantifies the operational variability exhibited during Apollo 14-17 lunar surface EVA operations to better understand the challenges and natural tendencies of timeline execution and life support system performance involved in surface operations. Each EVA (11 in total) is individually summarized as well as aggregated to provide descriptive trends exhibited throughout the Apollo missions. This work extends previous EVA task analyses by calculating deviations between planned and as-performed timelines as well as examining metabolic rate and consumables usage throughout the execution of each EVA. The intent of this work is to convey the natural variability of EVA operations and to provide operational context for coping with the variability inherent to EVA execution as a means to support future concepts of operations.

planning and scheduling↗