Search NASA⌕ Search

SEARCH · Search NASA

Results for “uplink process”

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

Simplifying operations with an uplink/downlink integration toolkit

The Operations Engineering Lab (OEL) at JPL has developed a simple, generic toolkit to integrate the uplink/downlink processes, (often called closing the loop), in JPL's Multimission Ground Data System. This toolkit provides capabilities for integrating telemetry verification points with predicted spacecraft commands and ground events in the Mission Sequence Of Events (SOE) document. In the JPL ground data system, the uplink processing functions and the downlink processing functions are separate subsystems that are not well integrated because of the nature of planetary missions with large one-way light times for spacecraft-to-ground communication. Our new closed-loop monitoring tool allows an analyst or mission controller to view and save uplink commands and ground events with their corresponding downlinked telemetry values regardless of the delay in downlink telemetry and without requiring real-time intervention by the user. An SOE document is a time-ordered list of all the planned ground and spacecraft events, including all commands, sequence loads, ground events, significant mission activities, spacecraft status, and resource allocations. The SOE document is generated by expansion and integration of spacecraft sequence files, ground station allocations, navigation files, and other ground event files. This SOE generation process has been automated within the OEL and includes a graphical, object-oriented SOE editor and real-time viewing tool running under X/Motif. The SOE toolkit was used as the framework for the integrated implementation. The SOE is used by flight engineers to coordinate their operations tasks, serving as a predict data set in ground operations and mission control. The closed-loop SOE toolkit allows simple, automated integration of predicted uplink events with correlated telemetry points in a single SOE document for on-screen viewing and archiving. It automatically interfaces with existing real-time or non real-time sources of information, to display actual values from the telemetry data stream. This toolkit was designed to greatly simplify the user's ability to access and view telemetry data, and also provide a means to view this data in the context of the commands and ground events that are used to interpret it. A closed-loop system can prove especially useful in small missions with limited resources requiring automated monitoring tools. This paper will discuss the toolkit implementation, including design trade-offs and future plans for enhancing the automated capabilities.

Murphy, Susan C.↗
NASA NTRS2006

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

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

missions operations↗
NASA NTRS1988

A new multi-mission data system for space flight support through the 1990's

The Space Flight Operations Center (SFOC) is described with attention given to historical and technical aspects. The SFOC is designed to support each new JPL mission with all of its mission-unique processing as a ready adaptation of some set of baseline capabilities. Another goal of the SFOC is to allow the migration of current older JPL missions from their current systems that use aging and costly hardware and software to newer systems with similar functionality. Upon its completion, the planned support includes both downlink and uplink processing for a projected six mission set.

Gainsborough, A. J.↗
NASA NTRS1981

HiMAT onboard flight computer system architecture and qualification

Two highly maneuverable aircraft technology (HiMAT) remotely piloted research vehicles (RPRV's) are being flight tested at NASA Dryden Flight Research Center, Edwards, California, to demonstrate and evaluate a number of technological advances applicable to future fighter aircraft. Closed-loop primary flight control is performed from a ground-based cockpit utilizing a digital computer and up/down telemetry links. A backup flight control system for emergency operation resides in one of two onboard computers. Other functions of the onboard computer system are uplink processing, downlink processing, engine control, failure detection, and redundancy management. This paper describes the architecture, functions, and flight qualification of the HiMAT onboard flight computer systems.

Myers, A. F.↗
NASA NTRS1993

The instant sequencing task: Toward constraint-checking a complex spacecraft command sequence interactively

Robotic spacecraft are controlled by sets of commands called 'sequences.' These sequences must be checked against mission constraints. Making our existing constraint checking program faster would enable new capabilities in our uplink process. Therefore, we are rewriting this program to run on a parallel computer. To do so, we had to determine how to run constraint-checking algorithms in parallel and create a new method of specifying spacecraft models and constraints. This new specification gives us a means of representing flight systems and their predicted response to commands which could be used in a variety of applications throughout the command process, particularly during anomaly or high-activity operations. This commonality could reduce operations cost and risk for future complex missions. Lessons learned in applying some parts of this system to the TOPEX/Poseidon mission will be described.

Horvath, Joan C.↗
NASA NTRS2014

Use of Semi-Autonomous Tools for ISS Commanding and Monitoring

As the International Space Station (ISS) has moved into a utilization phase, operations have shifted to become more ground-based with fewer mission control personnel monitoring and commanding multiple ISS systems. This shift to fewer people monitoring more systems has prompted use of semi-autonomous console tools in the ISS Mission Control Center (MCC) to help flight controllers command and monitor the ISS. These console tools perform routine operational procedures while keeping the human operator "in the loop" to monitor and intervene when off-nominal events arise. Two such tools, the Pre-positioned Load (PPL) Loader and Automatic Operators Recorder Manager (AutoORM), are used by the ISS Communications RF Onboard Networks Utilization Specialist (CRONUS) flight control position. CRONUS is responsible for simultaneously commanding and monitoring the ISS Command & Data Handling (C&DH) and Communications and Tracking (C&T) systems. PPL Loader is used to uplink small pieces of frequently changed software data tables, called PPLs, to ISS computers to support different ISS operations. In order to uplink a PPL, a data load command must be built that contains multiple user-input fields. Next, a multiple step commanding and verification procedure must be performed to enable an onboard computer for software uplink, uplink the PPL, verify the PPL has incorporated correctly, and disable the computer for software uplink. PPL Loader provides different levels of automation in both building and uplinking these commands. In its manual mode, PPL Loader automatically builds the PPL data load commands but allows the flight controller to verify and save the commands for future uplink. In its auto mode, PPL Loader automatically builds the PPL data load commands for flight controller verification, but automatically performs the PPL uplink procedure by sending commands and performing verification checks while notifying CRONUS of procedure step completion. If an off-nominal condition occurs during procedure execution, PPL Loader notifies CRONUS through popup messages, allowing CRONUS to examine the situation and choose an option of how PPL loader should proceed with the procedure. The use of PPL Loader to perform frequent, routine PPL uplinks offloads CRONUS to better monitor two ISS systems. It also reduces procedure performance time and decreases risk of command errors. AutoORM identifies ISS communication outage periods and builds commands to lock, playback, and unlock ISS Operations Recorder files. Operation Recorder files are circular buffer files of continually recorded ISS telemetry data. Sections of these files can be locked from further writing, be played back to capture telemetry data that occurred during an ISS loss of signal (LOS) period, and then be unlocked for future recording use. Downlinked Operation Recorder files are used by mission support teams for data analysis, especially if failures occur during LOS. The commands to lock, playback, and unlock Operations Recorder files are encompassed in three different operational procedures and contain multiple user-input fields. AutoORM provides different levels of automation for building and uplinking the commands to lock, playback, and unlock Operations Recorder files. In its automatic mode, AutoORM automatically detects ISS LOS periods, then generates and uplinks the commands to lock, playback, and unlock Operations Recorder files when MCC regains signal with ISS. AutoORM also features semi-autonomous and manual modes which integrate CRONUS more into the command verification and uplink process. AutoORMs ability to automatically detect ISS LOS periods and build the necessary commands to preserve, playback, and release recorded telemetry data greatly offloads CRONUS to perform more high-level cognitive tasks, such as mission planning and anomaly troubleshooting. Additionally, since Operations Recorder commands contain numerical time input fields which are tedious for a human to manually build, AutoORM's ability to automatically build commands reduces operational command errors. PPL Loader and AutoORM demonstrate principles of semi-autonomous operational tools that will benefit future space mission operations. Both tools employ different levels of automation to perform simple and routine procedures, thereby offloading human operators to perform higher-level cognitive tasks. Because both tools provide procedure execution status and highlight off-nominal indications, the flight controller is able to intervene during procedure execution if needed. Semi-autonomous tools and systems that can perform routine procedures, yet keep human operators informed of execution, will be essential in future long-duration missions where the onboard crew will be solely responsible for spacecraft monitoring and control.

Brzezinski, Amy S.↗
NASA NTRS2022

The Psyche Planning Software Subsystem: Creating a Robust Toolset for a Discovery-class Mission

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.

Ramanathan, Keshav↗
NASA NTRS2005

Analyzing MER Uplink Reports

The MER project includes two rovers working simultaneously on opposite sides of Mars each receiving commands only once a day. Creating this uplink is critical, since a failed uplink means a lost day and a waste of money. Examining the process of creating this uplink, I tracked the use of the system developed for requesting observations as well as the development, from stage to stage, in forming an activity plan. I found the system for requesting observations was commonly misused, if used at all. There are half a dozen reports to document the creation of the uplink plan and often there are discrepancies among them. Despite this, the uplink process worked very well and MER has been one of the most successful missions for NASA in recent memory. Still it is clear there is room for improvement.

Savin, Stephen C.↗
NASA NTRS2013

MPST Software: grl_suppdoc

Due to the nature of the GRAIL mission, the GRAIL Mission Planning and Sequence Team (MPST) is required to generate ground and uplink products faster than ever done before. The existing correct_transmitter_min_dur tool that provides a similar function to grl_suppdoc lacks the ability to operate accurately or quickly enough to support the rapid turnaround required of the GRAIL MPST. The GRAIL MPST was required to build this new tool to facilitate the ground and uplink generation processes to meet a tight sequence development timeline. The grl_suppdoc tool enables the GRAIL MPST to generate automatically Deep Space Network (DSN) transmitter suppressions based on short uplinks that are found in the ground/modeled Predicted Events File (PEF). The grl_suppdoc script automatically generates applicable DSN uplink suppressions in the form of a Spacecraft Activity Sequence File (SASF) to protect the GRAIL project from short DSN uplink windows, which can be cause for operator error at the DSN antennas. Currently, no software exists that provides this functionality at the efficiency required for GRAIL sequence team operations. Compared to a manual process, this script reduces human error and saves considerable man-hours by automating and streamlining the mission planning and sequencing task for the GRAIL mission.

Call, Jared A.↗
NASA NTRS2019

Streamlining Pre-Launch Support for Missions with Highly Variable Trajectories

As the Goddard Space Flight Center's (GSFC) Flight Dynamics Facility (FDF) continues to ensure mission success in support of Human Space Flight (HSF) and Launch Vehicle (LV) missions, it continues to improve on different areas of mission support. The FDF processes numerous different types of trajectory profiles, and, for each trajectory, the FDF provides multiple acquisition data vectors to the Space Network (SN) White Sands Complex (WSC) for further processing and uplinking to the SN's Tracking and Data Relay Satellites (TDRSs), tracking the vehicle and maintaining communications throughout required support. Some trajectories target a specific orbit plane through Right Ascension of the Ascending Node (RAAN), or yaw, steering, which can yield to high variability across the launch window. Because of this, there can be a large number of trajectory profiles to process and generate acquisition data for that ensure TDRS is accurately pointing to the launch vehicle. Processing many trajectory profiles by FDF and WSC increases the complexity and level of effort associated with support. FDF employs a legacy boundary on the range difference between trajectories, which determines the number of discrete trajectory cases required to maintain communication with TDRS over the full launch window. An analysis was performed to determine a new boundary, taking into consideration current support requirements. The results show the boundary can be expanded beyond the currently employed legacy value without an impact on communication. In doing so, the number of trajectory profiles processed can be reduced, reducing the complexity and level of effort required, with no impact to mission safety.

Flight Operations↗
NASA NTRS1994

Low Cost Uplink Concepts

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.

ground system architecture generic uplink process ↗
NASA NTRS1994

Fault Protection Design for the Command and Data Subsystem on the Cassini Spacecraft

The Command and Data Subsystem (CDS) on Cassini is responsible for uplink command processing, spacecraft intercommunications and control, and downlink telemetry formatting. The 10.7 year mission life, 160 minute round-trip light time, and extended periods of operation without continuous ground communications drive the CDS design in directions of redundancy, autonomy, and fault protection to accomodate the mission objectives.

Cassini↗
NASA NTRS1998

Parallel processing spacecraft communication system

An uplink controlling assembly speeds data processing using a special parallel codeblock technique. A correct start sequence initiates processing of a frame. Two possible start sequences can be used; and the one which is used determines whether data polarity is inverted or non-inverted. Processing continues until uncorrectable errors are found. The frame ends by intentionally sending a block with an uncorrectable error. Each of the codeblocks in the frame has a channel ID. Each channel ID can be separately processed in parallel. This obviates the problem of waiting for error correction processing. If that channel number is zero, however, it indicates that the frame of data represents a critical command only. That data is handled in a special way, independent of the software. Otherwise, the processed data further handled using special double buffering techniques to avoid problems from overrun. When overrun does occur, the system takes action to lose only the oldest data.

Bolotin, Gary S.↗
NASA NTRS2010

Automation of Cassini Support Imaging Uplink Command Development

"Support imaging" is imagery requested by other Cassini science teams to aid in the interpretation of their data. The generation of the spacecraft command sequences for these images is performed by the Cassini Instrument Operations Team. The process initially established for doing this was very labor-intensive, tedious and prone to human error. Team management recognized this process as one that could easily benefit from automation. Team members were tasked to document the existing manual process, develop a plan and strategy to automate the process, implement the plan and strategy, test and validate the new automated process, and deliver the new software tools and documentation to Flight Operations for use during the Cassini extended mission. In addition to the goals of higher efficiency and lower risk in the processing of support imaging requests, an effort was made to maximize adaptability of the process to accommodate uplink procedure changes and the potential addition of new capabilities outside the scope of the initial effort.

Ly-Hollins, Lisa↗
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 NTRS2013

Robot Sequencing and Visualization Program (RSVP)

The Robot Sequencing and Visualization Program (RSVP) is being used in the Mars Science Laboratory (MSL) mission for downlink data visualization and command sequence generation. RSVP reads and writes downlink data products from the operations data server (ODS) and writes uplink data products to the ODS. The primary users of RSVP are members of the Rover Planner team (part of the Integrated Planning and Execution Team (IPE)), who use it to perform traversability/articulation analyses, take activity plan input from the Science and Mission Planning teams, and create a set of rover sequences to be sent to the rover every sol. The primary inputs to RSVP are downlink data products and activity plans in the ODS database. The primary outputs are command sequences to be placed in the ODS for further processing prior to uplink to each rover. RSVP is composed of two main subsystems. The first, called the Robot Sequence Editor (RoSE), understands the MSL activity and command dictionaries and takes care of converting incoming activity level inputs into command sequences. The Rover Planners use the RoSE component of RSVP to put together command sequences and to view and manage command level resources like time, power, temperature, etc. (via a transparent realtime connection to SEQGEN). The second component of RSVP is called HyperDrive, a set of high-fidelity computer graphics displays of the Martian surface in 3D and in stereo. The Rover Planners can explore the environment around the rover, create commands related to motion of all kinds, and see the simulated result of those commands via its underlying tight coupling with flight navigation, motor, and arm software. This software is the evolutionary replacement for the Rover Sequencing and Visualization software used to create command sequences (and visualize the Martian surface) for the Mars Exploration Rover mission.

Cooper, Brian K.↗
NASA NTRS2008

Cassini's Maneuver Automation Software (MAS) Process: How to Successfully Command 200 Navigation Maneuvers

To keep Cassini on its complex trajectory, more than 200 orbit trim maneuvers (OTMs) have been planned from July 2004 to July 2010. With only a few days between many of these OTMs, the operations process of planning and executing the necessary commands had to be automated. The resulting Maneuver Automation Software (MAS) process minimizes the workforce required for, and maximizes the efficiency of, the maneuver design and uplink activities. The MAS process is a well-organized and logically constructed interface between Cassini's Navigation (NAV), Spacecraft Operations (SCO), and Ground Software teams. Upon delivery of an orbit determination (OD) from NAV, the MAS process can generate a maneuver design and all related uplink and verification products within 30 minutes. To date, all 112 OTMs executed by the Cassini spacecraft have been successful. MAS was even used to successfully design and execute a maneuver while the spacecraft was in safe mode.

Yang, Genevie Velarde↗