SEARCH · Search NASA

Results for “Communication Network Scheduling”

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.

SourceResearch connectionFrom yearThrough year

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

At least 181 records · Page 10

All sources NASA NTRS DOE OSTI

NASA NTRS1994

Constraint based scheduling for the Goddard Space Flight Center distributed Active Archive Center's data archive and distribution system

The Goddard Space Flight Center (GSFC) Distributed Active Archive Center (DAAC) has been operational since October 1, 1993. Its mission is to support the Earth Observing System (EOS) by providing rapid access to EOS data and analysis products, and to test Earth Observing System Data and Information System (EOSDIS) design concepts. One of the challenges is to ensure quick and easy retrieval of any data archived within the DAAC's Data Archive and Distributed System (DADS). Over the 15-year life of EOS project, an estimated several Petabytes (10(exp 15)) of data will be permanently stored. Accessing that amount of information is a formidable task that will require innovative approaches. As a precursor of the full EOS system, the GSFC DAAC with a few Terabits of storage, has implemented a prototype of a constraint-based task and resource scheduler to improve the performance of the DADS. This Honeywell Task and Resource Scheduler (HTRS), developed by Honeywell Technology Center in cooperation the Information Science and Technology Branch/935, the Code X Operations Technology Program, and the GSFC DAAC, makes better use of limited resources, prevents backlog of data, provides information about resources bottlenecks and performance characteristics. The prototype which is developed concurrently with the GSFC Version 0 (V0) DADS, models DADS activities such as ingestion and distribution with priority, precedence, resource requirements (disk and network bandwidth) and temporal constraints. HTRS supports schedule updates, insertions, and retrieval of task information via an Application Program Interface (API). The prototype has demonstrated with a few examples, the substantial advantages of using HTRS over scheduling algorithms such as a First In First Out (FIFO) queue. The kernel scheduling engine for HTRS, called Kronos, has been successfully applied to several other domains such as space shuttle mission scheduling, demand flow manufacturing, and avionics communications scheduling.

Short, Nick, Jr.↗

NASA NTRS2017

Lunar and Lagrangian Point L1 L2 CubeSat Communication and Navigation Considerations

CubeSats have grown in sophistication to the point that relatively low-cost mission solutions could be undertaken for planetary exploration. There are unique considerations for lunar and L1/L2 CubeSat communication and navigation compared with low earth orbit CubeSats. This paper explores those considerations as they relate to the Lunar IceCube Mission. The Lunar IceCube is a CubeSat mission led by Morehead State University with participation from NASA Goddard Space Flight Center, Jet Propulsion Laboratory, the Busek Company and Vermont Tech. It will search for surface water ice and other resources from a high inclination lunar orbit. Lunar IceCube is one of a select group of CubeSats designed to explore beyond low-earth orbit that will fly on NASA’s Space Launch System (SLS) as secondary payloads for Exploration Mission (EM) 1. Lunar IceCube and the EM-1 CubeSats will lay the groundwork for future lunar and L1/L2 CubeSat missions. This paper discusses communication and navigation needs for the Lunar IceCube mission and navigation and radiation tolerance requirements related to lunar and L1/L2 orbits. Potential CubeSat radios and antennas for such missions are investigated and compared. Ground station coverage, link analysis, and ground station solutions are also discussed. This paper will describe modifications in process for the Morehead ground station, as well as further enhancements of the Morehead ground station and NASA Near Earth Network (NEN) that are being considered. The potential NEN enhancements include upgrading current NEN Cortex receiver with Forward Error Correction (FEC) Turbo Code, providing X-band uplink capability, and adding ranging options. The benefits of ground station enhancements for CubeSats flown on NASA Exploration Missions (EM) are presented. This paper also describes how the NEN may support lunar and L1/L2 CubeSats without any enhancements. In addition, NEN is studying other initiatives to better support the CubeSat community, including streamlining the compatibility testing, planning and scheduling associated with CubeSat missions. Because of the lower cost, opportunity for simultaneous multipoint observations, it is inevitable that CubeSats will continue to increase in popularity for not only LEO missions, but for lunar and L1/L2 missions as well. The challenges for lunar and L1/L2 missions for communication and navigation are much greater than for LEO missions, but are not insurmountable. Advancements in flight hardware and ground infrastructure will ease the burden.

CubeSat↗

NASA NTRS1987

Intersatellite Link (ISL) application to commercial communications satellites. Volume 2: Technical final report

Intersatellite Link (ISL) applications can improve and expand communication satellite services in a number of ways. As the demand for orbital slots within prime regions of the geostationary arc increases, attention is being focused on ISLs as a method to utilize this resource more efficiently and circumvent saturation. Various GEO-to-GEO applications were determined that provide potential benefits over existing communication systems. A set of criteria was developed to assess the potential applications. Intersatellite link models, network system architectures, and payload configurations were developed. For each of the chosen ISL applications, ISL versus non-ISL satellite systems architectures were derived. Both microwave and optical ISL implementation approaches were evaluated for payload sizing and cost analysis. The technological availability for ISL implementations was assessed. Critical subsystems technology areas were identified, and an estamate of the schedule and cost to advance the technology to the requiered state of readiness was made.

Young, S. Lee↗

NASA NTRS1993

The application of automated operations at the Institutional Processing Center

The JPL Institutional and Mission Computing Division, Communications, Computing and Network Services Section, with its mission contractor, OAO Corporation, have for some time been applying automation to the operation of JPL's Information Processing Center (IPC). Automation does not come in one easy to use package. Automation for a data processing center is made up of many different software and hardware products supported by trained personnel. The IPC automation effort formally began with console automation, and has since spiraled out to include production scheduling, data entry, report distribution, online reporting, failure reporting and resolution, documentation, library storage, and operator and user education, while requiring the interaction of multi-vendor and locally developed software. To begin the process, automation goals are determined. Then a team including operations personnel is formed to research and evaluate available options. By acquiring knowledge of current products and those in development, taking an active role in industry organizations, and learning of other data center's experiences, a forecast can be developed as to what direction technology is moving. With IPC management's approval, an implementation plan is developed and resources identified to test or implement new systems. As an example, IPC's new automated data entry system was researched by Data Entry, Production Control, and Advance Planning personnel. A proposal was then submitted to management for review. A determination to implement the new system was made and elements/personnel involved with the initial planning performed the implementation. The final steps of the implementation were educating data entry personnel in the areas effected and procedural changes necessary to the successful operation of the new system.

Barr, Thomas H.↗

NASA NTRS2014

A Geosynchronous Orbit Optical Communications Relay Architecture

NASA is planning to fly a Next Generation Tracking and Data Relay Satellite (TDRS) next decade. While the requirements and architecture for that satellite are unknown at this time, NASA is investing in communications technologies that could be deployed on the satellite to provide new communications services. One of those new technologies is optical communications. The Laser Communications Relay Demonstration (LCRD) project, scheduled for launch in December 2017 as a hosted payload on a commercial communications satellite, is a critical pathfinder towards NASA providing optical communications services on the Next Generation TDRS. While it is obvious that a small to medium sized optical communications terminal could be flown on a GEO satellite to provide support to Near Earth missions, it is also possible to deploy a large terminal on the satellite to support Deep Space missions. Onboard data processing and Delay Tolerant Networking (DTN) are two additional technologies that could be used to optimize optical communications link services and enable additional mission and network operations. This paper provides a possible architecture for the optical communications augmentation of a Next Generation TDRS and touches on the critical technology work currently being done at NASA. It will also describe the impact of clouds on such an architecture and possible mitigation techniques.

optics↗

NASA NTRS1992

Evolutionary Telemetry and Command Processor (TCP) architecture

A low cost, modular, high performance, and compact Telemetry and Command Processor (TCP) is being built as the foundation of command and data handling subsystems for the next generation of satellites. The TCP product line will support command and telemetry requirements for small to large spacecraft and from low to high rate data transmission. It is compatible with the latest TDRSS, STDN and SGLS transponders and provides CCSDS protocol communications in addition to standard TDM formats. Its high performance computer provides computing resources for hosted flight software. Layered and modular software provides common services using standardized interfaces to applications thereby enhancing software re-use, transportability, and interoperability. The TCP architecture is based on existing standards, distributed networking, distributed and open system computing, and packet technology. The first TCP application is planned for the 94 SDIO SPAS 3 mission. The architecture enhances rapid tailoring of functions thereby reducing costs and schedules developed for individual spacecraft missions.

Schneider, John R.↗

NASA NTRS2018

Streamlining Ground Station Network Compatibility Test for Small Satellites

A team of eight subject matter experts at NASA Goddard Space Flight Center (GSFC) completed a Lean Six Sigma project to identify process improvements for the compatibility test process for small satellites planning to use the NASA Near Earth Network (NEN). Ground station network compatibility testing is designed to reduce the risk to missions by resolving issues between the spacecraft's flight communication and navigation components and the ground systems prior to launch. Compatibility testing, which consists of a series of tests performed over a period of months and documented in reports, is an important step meant to prevent post-launch anomalies that could lead to expensive troubleshooting or mission failure. Compared to traditional missions, small satellite missions typically have a smaller budget and compressed schedules, which can result in small satellite projects' willingness to accept the risk associated with less comprehensive compatibility testing. Optimization and or refinement of the compatibility test process for small satellite missions could alleviate some of the pressures inherent with these factors. The goal of the Lean Six Sigma project was to develop alternative scalable methods of compatibility testing for small satellites. The Lean Six Sigma approach and the results of the project are reviewed in this paper.

Streamlining↗

NASA NTRS2012

Lunar Reconnaissance Orbiter (LRO) Command and Data Handling Flight Electronics Subsystem

A document describes a high-performance, modular, and state-of-the-art Command and Data Handling (C&DH) system developed for use on the Lunar Reconnaissance Orbiter (LRO) mission. This system implements a complete hardware C&DH subsystem in a single chassis enclosure that includes a processor card, 48 Gbytes of solid-state recorder memory, data buses including MIL-STD-1553B, custom RS-422, SpaceWire, analog collection, switched power services, and interfaces to the Ka-Band and S-Band RF communications systems. The C&DH team capitalized on extensive experience with hardware and software with PCI bus design, SpaceWire networking, Actel FPGA design, digital flight design techniques, and the use of VxWorks for the real-time operating system. The resulting hardware architecture was implemented to meet the LRO mission requirements. The C&DH comprises an enclosure, a backplane, a low-voltage power converter, a single-board computer, a communications interface board, four data storage boards, a housekeeping and digital input/output board, and an analog data acquisition board. The interfaces between the C&DH and the instruments and avionics are connected through a SpaceWire network, a MIL-STD-1553 bus, and a combination of synchronous and asynchronous serial data transfers over RS-422 and LVDS (low-voltage differential-signaling) electrical interfaces. The C&DH acts as the spacecraft data system with an instrument data manager providing all software and internal bus scheduling, ingestion of science data, distribution of commands, and performing science operations in real time.

Nguyen, Quang↗

NASA NTRS2017

On the Development and Application of High Data Rate Architecture (HiDRA) in Future Space Networks

Historically, space missions have been severely constrained by their ability to downlink the data they have collected. These constraints are a result of relatively low link rates on the spacecraft as well as limitations on the time during which data can be sent. As part of a coherent strategy to address existing limitations and get more data to the ground more quickly, the Space Communications and Navigation (SCaN) program has been developing an architecture for a future solar system Internet. The High Data Rate Architecture (HiDRA) project is designed to fit into such a future SCaN network. HiDRA's goal is to describe a general packet-based networking capability which can be used to provide assets with efficient networking capabilities while simultaneously reducing the capital costs and operational costs of developing and flying future space systems.Along these lines, this paper begins by reviewing various characteristics of modern satellite design as well as relevant characteristics of emerging technologies (such as free-space optical links capable of working at 100+ Gbps). Next, the paper describes HiDRA's design, and how the system is able to both integrate and support the operation of not only today's high-rate systems, but also the high-rate systems likely to be found in the future. This section also explores both existing and future networking technologies, such as Delay Tolerant Networking (DTN) protocol (RFC4838 citeRFC:1, RFC5050citeRFC:2), and explains how HiDRA supports them. Additionally, this section explores how HiDRA is used for scheduling data movement through both proactive and reactive link management. After this, the paper moves on to explore a reference implementation of HiDRA. This implementation is currently being realized based on a Field Programmable Gate Array (FPGA) memory and interface controller that is itself controlled by a local computer running DTN software. Next, this paper explores HiDRA's natural evolution, which includes an integration path for software-defined networking (SDN) switches. This section also describes considerations for both near-Earth and deep-space instantiations of HiDRA, describing how differences in latencies between the environments will necessarily influence how the system is configured and the networks operate. Finally, this paper describes future work. This section includes a description of a potential ISS implementation which will allow rapid advancement through the technology readiness levels (TRL). This section also explores work being done to support HiDRA's successful implementation and operation in a heterogeneous network: such a network could include communications equipment spanning many vintages and capabilities, and one significant aspect of HiDRA's future development involves balancing compatibility with capability.

DTN↗

NASA NTRS2011

Delay and Disruption Tolerant Networking MACHETE Model

To verify satisfaction of communication requirements imposed by unique missions, as early as 2000, the Communications Networking Group at the Jet Propulsion Laboratory (JPL) saw the need for an environment to support interplanetary communication protocol design, validation, and characterization. JPL's Multi-mission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE), described in Simulator of Space Communication Networks (NPO-41373) NASA Tech Briefs, Vol. 29, No. 8 (August 2005), p. 44, combines various commercial, non-commercial, and in-house custom tools for simulation and performance analysis of space networks. The MACHETE environment supports orbital analysis, link budget analysis, communications network simulations, and hardware-in-the-loop testing. As NASA is expanding its Space Communications and Navigation (SCaN) capabilities to support planned and future missions, building infrastructure to maintain services and developing enabling technologies, an important and broader role is seen for MACHETE in design-phase evaluation of future SCaN architectures. To support evaluation of the developing Delay Tolerant Networking (DTN) field and its applicability for space networks, JPL developed MACHETE models for DTN Bundle Protocol (BP) and Licklider/Long-haul Transmission Protocol (LTP). DTN is an Internet Research Task Force (IRTF) architecture providing communication in and/or through highly stressed networking environments such as space exploration and battlefield networks. Stressed networking environments include those with intermittent (predictable and unknown) connectivity, large and/or variable delays, and high bit error rates. To provide its services over existing domain specific protocols, the DTN protocols reside at the application layer of the TCP/IP stack, forming a store-and-forward overlay network. The key capabilities of the Bundle Protocol include custody-based reliability, the ability to cope with intermittent connectivity, the ability to take advantage of scheduled and opportunistic connectivity, and late binding of names to addresses.

Segui, John S.↗

NASA NTRS2011

The Impact of Traffic Prioritization on Deep Space Network Mission Traffic

A select number of missions supported by NASA's Deep Space Network (DSN) are demanding very high data rates. For example, the Kepler Mission was launched March 7, 2009 and at that time required the highest data rate of any NASA mission, with maximum rates of 4.33 Mb/s being provided via Ka band downlinks. The James Webb Space Telescope will require a maximum 28 Mb/s science downlink data rate also using Ka band links; as of this writing the launch is scheduled for a June 2014 launch. The Lunar Reconnaissance Orbiter, launched June 18, 2009, has demonstrated data rates at 100 Mb/s at lunar-Earth distances using NASA's Near Earth Network (NEN) and K-band. As further advances are made in high data rate space telecommunications, particularly with emerging optical systems, it is expected that large surges in demand on the supporting ground systems will ensue. A performance analysis of the impact of high variance in demand has been conducted using our Multi-mission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE) simulation tool. A comparison is made regarding the incorporation of Quality of Service (QoS) mechanisms and the resulting ground-to-ground Wide Area Network (WAN) bandwidth necessary to meet latency requirements across different user missions. It is shown that substantial reduction in WAN bandwidth may be realized through QoS techniques when low data rate users with low-latency needs are mixed with high data rate users having delay-tolerant traffic.

prioritization↗

NASA NTRS2011

The Impact of Traffic Prioritization on Deep Space Network Mission Traffic

quality of service↗

NASA NTRS1991

Space Network Control Conference on Resource Allocation Concepts and Approaches

The results are presented of the Space Network Control (SNC) Conference. In the late 1990s, when the Advanced Tracking and Data Relay Satellite System is operational, Space Network communication services will be supported and controlled by the SNC. The goals of the conference were to survey existing resource allocation concepts and approaches, to identify solutions applicable to the Space Network, and to identify avenues of study in support of the SNC development. The conference was divided into three sessions: (1) Concepts for Space Network Allocation; (2) SNC and User Payload Operations Control Center (POCC) Human-Computer Interface Concepts; and (3) Resource Allocation Tools, Technology, and Algorithms. Key recommendations addressed approaches to achieving higher levels of automation in the scheduling process.

Moe, Karen L.↗

NASA NTRS1998

The SGI/Cray T3E: Experiences and Insights

The NASA Goddard Space Flight Center is home to the fifth most powerful supercomputer in the world, a 1024 processor SGI/Cray T3E-600. The original 512 processor system was placed at Goddard in March, 1997 as part of a cooperative agreement between the High Performance Computing and Communications Program's Earth and Space Sciences Project (ESS) and SGI/Cray Research. The goal of this system is to facilitate achievement of the Project milestones of 10, 50 and 100 GFLOPS sustained performance on selected Earth and space science application codes. The additional 512 processors were purchased in March, 1998 by the NASA Earth Science Enterprise for the NASA Seasonal to Interannual Prediction Project (NSIPP). These two "halves" still operate as a single system, and must satisfy the unique requirements of both aforementioned groups, as well as guest researchers from the Earth, space, microgravity, manned space flight and aeronautics communities. Few large scalable parallel systems are configured for capability computing, so models are hard to find. This unique environment has created a challenging system administration task, and has yielded some insights into the supercomputing needs of the various NASA Enterprises, as well as insights into the strengths and weaknesses of the T3E architecture and software. The T3E is a distributed memory system in which the processing elements (PE's) are connected by a low latency, high bandwidth bidirectional 3-D torus. Due to the focus on high speed communication between PE's, the T3E requires PE's to be allocated contiguously per job. Further, jobs will only execute on the user specified number of PE's and PE timesharing is possible but impractical. With a highly varied job mix in both size and runtime of jobs, the resulting scenario is PE fragmentation and an inability to achieve near 100% utilization. SGI/Cray has provided several scheduling and configuration tools to minimize the impact of fragmentation. These tools include PScheD (the political scheduler), GRM (the global resource manager) and NQE (the Network Queuing Environment). Features and impact of these tools will be discussed, as will resulting performance and utilization data. As a distributed memory system, the T3E is designed to be programmed through explicit message passing. Consequently, certain assumptions related to code design are made by the operating system (UNICOS/mk) and its scheduling tools. With the exception of HPF, which does run on the T3E, however poorly, alternative programming styles have the potential to impact the T3E in unexpected and undesirable ways. Several examples will be presented (preceeded with the disclaimer, "Don't try this at home! Violators will be prosecuted!")

Bernard, Lisa Hamet↗

NASA NTRSDate not supplied

Flight and Direct to Earth/Space Relay Communication System Architecture for GSFC CubeSat Missions

The CubeSat platform is finding increasing use in space science applications due to its low cost and comparative ease of launch. It is becoming a key scientific discovery tool in low Earth orbit (LEO) and beyond, including geosynchronous equatorial orbit (GEO), the Lagrange Points, Lunar missions, and more. The increasing complexity of these missions and their scientific goals must be supported by equal advancements in communications technology. Higher data rates and greater reliability are required every year. However, the reduced Size, Weight, and Power (SWaP) constraints of CubeSat platforms introduce unique challenges in the area of satellite communications. There is currently a lack of communication equipment tailored specifically to the CubeSat platform. This lack of standardized, tested equipment extends development time and reduces mission confidence. Furthermore, missions utilizing the CubeSat platform are often subject to more difficult design constraints. Antenna placement, size, and pointing are often subordinate to the requirements of the payload instruments and mission goals. Traditional link margin estimation techniques are insufficient in these cases, as they emphasize worst case scenarios. In reality the actual link parameters may vary widely even during a single pass. This presents new challenges in predicting communications performance and scheduling ground station contacts, but also new opportunities for improving efficiency. This paper presents the integration, testing, and validation process for a new software defined radio (SDR) designed for the CubeSat platform in conjunction with Vulcan Wireless, Inc. The SDR is planned for use on 5 upcoming CubeSat missions at NASAs Goddard Space Flight Center (GSFC) including a Geosynchronous Transfer Orbit (GTO) mission and it may also serve as a standard and well-tested option for future missions by enabling a standardized, rapid and low cost CubeSat communication system network integration process. Detailed simulations have been developed to estimate the communication performance of these missions, taking the unique antenna placements and attitude behavior of each satellite into account. These simulations allow a much more accurate analysis of the expected link margin, which varies considerably during each pass for the NASA Space Relay (SR) and Direct to Earth (DTE) network. The modelling procedures are outlined, and the results are used to predict communications performance of the missions.

Space Networks↗

NASA NTRSDate not supplied

Cloud-Based Demodulation and Data Distribution of a Satellite Downlink

Ground station networks connected to the cloud allow space missions to have global communications coverage without operating their own infrastructure. In this work, we describe the communications architecture for the TechEdSat-13 mission, which performed the first in-space characterization of a neuromorphic processor. The mission utilizes a commercial provider for S-band downlinks. A suite of cloud services and open-source software such as GNU Radio are leveraged to demodulate signals received by an AWS ground station during passes with TechEdSat-13 and store recovered data. Once a pass is scheduled, the entire process takes place without human intervention. On-orbit results the past year of operations are presented, demonstrating the advantages of this approach over traditional operator-owned ground stations. Use of software-defined radio makes possible custom signal processing. The homogeneity of apertures and their interfaces to the cloud simplifies scaling across many sites. This abundance of candidate links lays the groundwork for intelligent scheduling agents to optimize pass selection across several factors, automatically recover from failed contacts, and gather metrics to learn from past performance.

cloud demodulation↗

NASA NTRS2013

Unique Challenges Testing SDRs for Space

This paper describes the approach used by the Space Communication and Navigation (SCaN) Testbed team to qualify three Software Defined Radios (SDR) for operation in space and the characterization of the platform to enable upgrades on-orbit. The three SDRs represent a significant portion of the new technologies being studied on board the SCAN Testbed, which is operating on an external truss on the International Space Station (ISS). The SCaN Testbed provides experimenters an opportunity to develop and demonstrate experimental waveforms and applications for communication, networking, and navigation concepts and advance the understanding of developing and operating SDRs in space. Qualifying a Software Defined Radio for the space environment requires additional consideration versus a hardware radio. Tests that incorporate characterization of the platform to provide information necessary for future waveforms, which might exercise extended capabilities of the hardware, are needed. The development life cycle for the radio follows the software development life cycle, where changes can be incorporated at various stages of development and test. It also enables flexibility to be added with minor additional effort. Although this provides tremendous advantages, managing the complexity inherent in a software implementation requires a testing beyond the traditional hardware radio test plan. Due to schedule and resource limitations and parallel development activities, the subsystem testing of the SDRs at the vendor sites was primarily limited to typical fixed transceiver type of testing. NASA's Glenn Research Center (GRC) was responsible for the integration and testing of the SDRs into the SCaN Testbed system and conducting the investigation of the SDR to advance the technology to be accepted by missions. This paper will describe the unique tests that were conducted at both the subsystem and system level, including environmental testing, and present results. For example, test waveforms were developed to measure the gain of the transmit system across the tunable frequency band. These were used during thermal vacuum testing to enable characterization of the integrated system in the wide operational temperature range of space. Receive power indicators were used for Electromagnetic Interference tests (EMI) to understand the platform's susceptibility to external interferers independent of the waveform. Additional approaches and lessons learned during the SCaN Testbed subsystem and system level testing will be discussed that may help future SDR integrators.

transmitters receivers↗

NASA NTRS2012

CASSIUS: The Cassini Uplink Scheduler

The Cassini Uplink Scheduler (CASSIUS) is cross-platform software used to generate a radiation sequence plan for commands being sent to the Cassini spacecraft. Because signals must travel through varying amounts of Earth's atmosphere, several different modes of constant telemetry rates have been devised. These modes guarantee that the spacecraft and the Deep Space Network agree with respect to the data transmission rate. However, the memory readout of a command will be lost if it occurs on a telemetry mode boundary. Given a list of spacecraft message files as well as the available telemetry modes, CASSIUS can find an uplink sequence that ensures safe transmission of each file. In addition, it can predict when the two on-board solid state recorders will swap. CASSIUS prevents data corruption by making sure that commands are not planned for memory readout during telemetry rate changes or a solid state recorder swap.

Cassini mission↗