SUPAR (Seamless Uplink Process Architecture and Representation)
Current uplink architectures, software and procedures have been developed over decades in attempts to cope with missions of ever increasing complexity.
SEARCH · Search NASA
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.
Current uplink architectures, software and procedures have been developed over decades in attempts to cope with missions of ever increasing complexity.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
In order to minimize the cost of developing sequences of commands for small, low cost missions, a cost effective set of uplink tools used in conjunction with an appropriate ground system architecture (including a multi-mission operations facility) must be utilized.
The International Space Station (ISS) is in an operational configuration with final assembly complete. To fully utilize ISS and extend the operational life, it became necessary to upgrade and extend the onboard systems with the Obsolescence Driven Avionics Redesign (ODAR) project. ODAR enabled a joint project between the Johnson Space Center (JSC) and Marshall Space Flight Center (MSFC) focused on upgrading the onboard payload and Ku-Band systems, expanding the voice and video capabilities, and including more modern protocols allowing unprecedented access for payload investigators to their on-orbit payloads. The MSFC Huntsville Operations Support Center (HOSC) was tasked with developing a high-rate enhanced Functionally Distributed Processor (eFDP) to handle 300Mbps Return Link data, double the legacy rate, and incorporate a Line Outage Recorder (LOR). The eFDP also provides a 25Mbps uplink transmission rate with a Space Link Extension (SLE) interface. HOSC also updated the Payload Data Services System (PDSS) to incorporate the latest Consultative Committee for Space Data Systems (CCSDS) protocols, most notably the use of the Internet Protocol (IP) Encapsulation, in addition to the legacy capabilities. The Central Command Processor was also updated to interact with the new onboard and ground capabilities of Mission Control Center -- Houston (MCC-H) for the uplink functionality. The architecture, implementation, and lessons learned, including integration and incorporation of Commercial Off The Shelf (COTS) hardware and software into the operational mission of the ISS, is described herein. The applicability of this new technology provides new benefits to ISS payload users and ensures better utilization of the ISS by the science community
Psyche is a Discovery-class mission to the small metal-rich asteroid (16) Psyche, and is slated to launch in 2022. Psyche, like many missions, requires low-cost activity planning and sequence generation that serves as the backbone to overall uplink design. Such tools must be maintainable over long periods of operations, and powerful enough to solve complex issues that deep-space one-off missions encounter. In this paper we introduce cost-effective solutions that leverage inner- and open-source principles to meet a variety of common and novel use cases.The uplink process that was designed to meet these challenges is presented, as well as the data-flow through the high-level architecture of the planning software subsystem. The user-facing planning tools are described, particularly the Science Opportunity Analyzer, the Plan Editor, Psyche’s planning automation in the Blackbird framework, and Psyche Simulation Reports. All these applications are either new or have been substantially revamped to meet Psyche’s concept of operations. In particular, ensuring the entire toolchain can correctly process epoch-relative activities is discussed. Underlying the main applications are a common set of dependencies developed and maintained by a new cross-mission association of planning developers. In this way, Psyche can inherit well-tested functionality which saves effort and ensures its developers can focus on solving domain challenges. Quality control of the applications and libraries is ensured with a code-review and unit-test based novel ‘CM lite’ process. Collaboration with international industry and academia using the open-source modules is already occurring.The planning and scheduling software is designed to maximize operator awareness of the integrated plan at every step of the process and use common interfaces and file formats to easily transfer information. Design choices plus the team’s test-driven development process enables more expansive capabilities compared to the decentralized planning and sequence generation functions typical of Discovery-class orbiters without significant development cost increases. Benefits and drawbacks of Psyche’s approach are discussed, including comparison to other missions and tools where appropriate.
This viewgraph presentation reviews the architectural description of the Mission Data Processing and Control System (MPCS). MPCS is an event-driven, multi-mission ground data processing components providing uplink, downlink, and data management capabilities which will support the Mars Science Laboratory (MSL) project as its first target mission. MPCS is designed with these factors (1) Enabling plug and play architecture (2) MPCS has strong inheritance from GDS components that have been developed for other Flight Projects (MER, MRO, DAWN, MSAP), and are currently being used in operations and ATLO, and (3) MPCS components are Java-based, platform independent, and are designed to consume and produce XML-formatted data
This paper details an architectural description of the Mission Data Processing and Control System (MPCS), an event-driven, multi-mission ground data processing components providing uplink, downlink, and data management capabilities which will support the Mars Science Laboratory (MSL) project as its first target mission. MPCS is developed based on a set of small reusable components, implemented in Java, each designed with a specific function and well-defined interfaces. An industry standard messaging bus is used to transfer information among system components. Components generate standard messages which are used to capture system information, as well as triggers to support the event-driven architecture of the system. Event-driven systems are highly desirable for processing high-rate telemetry (science and engineering) data, and for supporting automation for many mission operations processes.
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.
These reflections share insight gleaned from Cassini-Huygens experience in supporting uplink operations tasks with software. Of particular interest are developed applications that were not widely adopted and tasks for which the appropriate application was not planned. After several years of operations, tasks are better understood providing a clearer picture of the mapping of requirements to applications. The impact on system design of the changing user profile due to distributed operations and greater participation of scientists in operations is also explored. Suggestions are made for improving the architecture, requirements, and design of future systems for uplink operations.
These reflections share insight gleaned from Cassini-Huygens experience in supporting uplink operations tasks with software. Of particular interest are developed applications that were not widely adopted and tasks for which the appropriate application was not planned. After several years of operations, tasks are better understood providing a clearer picture of the mapping of requirements to applications. The impact on system design of the changing user profile due to distributed operations and greater participation of scientists in operations is also explored. Suggestions are made for improving the architecture, requirements, and design of future systems for uplink operations.
NASA s Vision for Space Exploration outlines a very ambitious program for the next several decades of the Space Agency endeavors. Ahead is the completion of the International Space Station (ISS); safely flight the shuttle (STS) until 2010; develop and fly the Crew Exploration Vehicle (Orion) by no later than 2014; return to the moon by no later than 2020; extend human presence across the solar system and beyond; implement a sustainable and affordable human and robotic program; develop supporting innovative technologies, knowledge and infrastructure; and promote international and commercial participation in exploration. To achieve these goals, a series of enabling technologies must be developed or matured in a timely manner. Some of these technologies are: spacecraft RF technology (e.g., high power sources and large antennas which using surface receive arrays can get up to 1 Gbps from Mars), uplink arraying (reduce reliance on large ground-based antennas and high operation costs; single point of failure; enable greater data-rates or greater effective distance; scalable, evolvable, flexible scheduling), software define radio (i.e., reconfigurable, flexible interoperability allows for in flight updates open architecture; reduces mass, power, volume), and optical communications (high capacity communications with low mass/power required; significantly increases data rates for deep space). This presentation will discuss some of the work being performed at the NASA Glenn Research Center, Cleveland, Ohio, in antenna technology as well as other on-going RF communications efforts.
Within human factors there is burgeoning interest in the "human-autonomy teaming" (HAT) concept as a way to address the challenges of interacting with complex, increasingly autonomous systems. The HAT concept comes out of an aspiration to interact with increasingly autonomous systems as a team member, rather than simply use automation as a tool. The authors, and others, have proposed core tenets for HAT that include bi-directional communication, automation and system transparency, and advanced coordination between human and automated teammates via predefined, dynamic task sequences known as "plays." It is believed that, with proper implementation, HAT should foster appropriate teamwork, thus increasing trust and reliance on the system, which in turn will reduce workload, increase situation awareness, and improve performance. To this end, HAT has been demonstrated and/or studied in multiple applications including search and rescue operations, healthcare and medicine, autonomous vehicles, photography, and aviation. The current paper presents one such effort to apply HAT. It details the design of a HAT agent, developed by Human Automation Teaming Solutions, Inc., to facilitate teamwork between the automation and the human operator of an advanced ground dispatch station. This dispatch station was developed to support a NASA project investigating a concept called Reduced Crew Operations (RCO); consequently, we have named the agent R-HATS. Part of the RCO concept involves a ground operator providing enhanced support to a large number of aircraft with a single pilot on the flight deck. When assisted by R-HATS, operators can monitor and support or manage a large number of aircraft and use plays to respond in real-time to complicated, workload-intensive events (e.g., an airport closure). A play is a plan that encapsulates goals, tasks, and a task allocation strategy appropriate for a particular situation. In the current implementation, when a play is initiated by a user, R-HATS determines what tasks need to be completed and has the ability to autonomously execute them (e.g., determining diversion options and uplinking new routes to aircraft) when it is safe and appropriate. R-HATS has been designed to both support end users and researchers in RCO and HAT. Additionally, R-HATS and its underlying architecture were developed with generalizability in mind as a modular software applicable outside of RCO/aviation domains. This paper will also discuss future further development and testing of RHATS.
Within human factors there is burgeoning interest in the Human-Autonomy Teaming (HAT) concept as away to address the challenges of interacting with complex, increasingly autonomous systems. The HAT concept comes out of an aspiration to interact with increasingly autonomous automation as a team member, rather than simply use automation as a tool. The authors, and others, have proposed core tenets for HAT that include bi-directional communication, automation and system transparency, and advanced coordination between human and automated teammates via predefined, dynamic task sequences known as plays (Shively et al., 2017). It is believed that, with proper implementation, HAT should foster appropriate teamwork, thus increasing trust and reliance on the system, which in turn will reduce workload, increase situation awareness, and improve performance. To this end, HAT has been demonstrated and/or studied in multiple applications including search and rescue operations (Nourbakhsh et al., 2005), healthcare and medicine (Tsui Yanco, 2007), autonomous vehicles (Parasuraman, Barnes, Cosenzo, Mulgund, 2007), photography (Lachter, Brandt, Sadler, Shively, in press), and aviation (Shively et al., in press). The current paper presents one such effort to apply HAT. It details the design of a R-HAT Agent developed as part of a NASA Research Agreement awarded to Human-Autonomy Teaming Solutions Inc. (HATS Inc), and developed in collaboration with the Human-Autonomy Teaming Laboratory at NASA Ames Research Center. The role of this Agent is to mediate interaction between the automation and the human operator of an advanced ground dispatch station, with this mediation based upon previously mentioned core tenets for HAT and the many lessons learned from the HAT research literature. This dispatch station was developed to support a NASA project investigating a concept called Reduced Crew Operations (RCO; Lachter, Brandt, Battiste, Matessa, Johnson, in press). Part of the RCO concept involves a ground operator providing enhanced support to a large number of aircraft with a single pilot on the flight deck. When assisted by the Agent, operators can monitor and support or manage a large number of aircraft and use plays to respond in real-time to complicated, workload-intensive events (e.g., an airport closure). A play is a plan that encapsulates goals, tasks, and a task allocation strategy appropriate for a particular situation. In the current implementation, when a play is initiated by a user, the Agent determines what tasks need to be done and has the ability to autonomously execute them (e.g., determining diversion options and uplinking new routes to aircraft) when it is safe and appropriate. The R-HAT Agent has been designed to both support end users and research in RCO and HAT. Additionally, the Agent and its underlying architecture were developed with generalizability in mind as a modular piece of software applicable outside of RCO aviation in domains such as those mentioned above. This paper will also discuss future further development and testing of the R-HAT Agent.
Distributed satellite systems is an enabling technology for many future NASA/DoD earth and space science missions, such as MMS, MAXIM, Leonardo, and LISA [1, 2, 3]. While formation flying offers significant science benefits, to reduce the operating costs for these missions it will be essential that these multiple vehicles effectively act as a single spacecraft by performing coordinated observations. Autonomous guidance, navigation, and control as part of a coordinated fleet-autonomy is a key technology that will help accomplish this complex goal. This is no small task, as most current space missions require significant input from the ground for even relatively simple decisions such as thruster burns. Work for the NMP DS1 mission focused on the development of the New Millennium Remote Agent (NMRA) architecture for autonomous spacecraft control systems. NMRA integrates traditional real-time monitoring and control with components for constraint-based planning, robust multi-threaded execution, and model-based diagnosis and reconfiguration. The complexity of using an autonomous approach for space flight software was evident when most of its capabilities were stripped off prior to launch (although more capability was uplinked subsequently, and the resulting demonstration was very successful).
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.
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.
This report provides the test results and performance analysis of the multichannel error correction code decoder (MED) system for a regenerative satellite with asynchronous, frequency-division multiple access (FDMA) uplink channels. It discusses the system performance relative to various critical parameters: the coding length, data pattern, unique word value, unique word threshold, and adjacent-channel interference. Testing was performed under laboratory conditions and used a computer control interface with specifically developed control software to vary these parameters. Needed technologies - the high-speed Bose Chaudhuri-Hocquenghem (BCH) codec from Harris Corporation and the TRW multichannel demultiplexer/demodulator (MCDD) - were fully integrated into the mesh very small aperture terminal (VSAT) onboard processing architecture and were demonstrated.