Search NASA⌕ Search

SEARCH · Search NASA

Results for “mission management ground data systems”

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 109 records · Page 6

Architecting the Human Space Flight Program with Systems Modeling Language (SysML)

The next generation of missions in NASA's Human Space Flight program focuses on the development and deployment of highly complex systems (e.g., Orion Multi-Purpose Crew Vehicle, Space Launch System, 21st Century Ground System) that will enable astronauts to venture beyond low Earth orbit and explore the moon, near-Earth asteroids, and beyond. Architecting these highly complex system-of-systems requires formal systems engineering techniques for managing the evolution of the technical features in the information exchange domain (e.g., data exchanges, communication networks, ground software) and also, formal correlation of the technical architecture to stakeholders' programmatic concerns (e.g., budget, schedule, risk) and design development (e.g., assumptions, constraints, trades, tracking of unknowns). This paper will describe how the authors have applied System Modeling Language (SysML) to implement model-based systems engineering for managing the description of the End-to-End Information System (EEIS) architecture and associated development activities and ultimately enables stakeholders to understand, reason, and answer questions about the EEIS under design for proposed lunar Exploration Missions 1 and 2 (EM-1 and EM-2).

scheduling↗

NASCOM system development plan: System description, capabilities, and plans, FY 94-2

The Nascom System Development Plan (NSDP) for FY 94-2 contains 17 sections. It is a management document containing the approved plan for maintaining the Nascom Network System. Topics covered include an overview of Nascom systems and services, major ground communication support systems, low-speed data system, voice system, high-speed data system, Nascom support for NASA networks, Nascom planning for NASA missions, and network upgrade and advanced systems developments and plans.

Source record↗

Designing Autonomy into Interfaces for Long-Duration Missions

As NASA develops technologies for long-duration crewed missions, we must understand how communication between ground control teams and astronauts differs from the current dynamic to adapt new concepts for long-duration mission operations. Today, ground control teams support astronauts with immediate availability to answer questions, resolve issues, and manage activities. In the near future, however, extended communication delays during long-duration missions will require astronauts to become more autonomous. As many of the responsibilities shift from the ground control teams to the astronauts on-board, the concept of operations must also change from how it functions today. With increased astronaut autonomy, software tools must be developed that enable efficient completion of mission tasks without increased mental workload. Designing software tools to facilitate crew autonomy requires development teams to know which data will enhance quick decision making while providing necessary context for situational awareness of systems being managed on-board. NASA's Autonomous Systems and Operations (ASO) team is presently developing a software interface tool, EXPRESS (EXpedite the PRocessing of Experiments for Space Station) 2.5 to enable a long-duration crew to schedule activities for and operate autonomous systems. This paper describes details of the integrated human factors approach that drove the design of the elements of the software tool, including self-managed scheduling, constraint-driven planning, autonomous system fault recovery, and recommended troubleshooting actions. Additionally, this paper will chronicle ASO modifications of the user interface after the team's first flight demonstration, how it was based on lessons learned during software development, as well as from crew feedback in order to develop the current version which will be demonstrated on ISS in 2021. In the upcoming ISS demonstration, the astronaut crew will be given scenarios for scheduling and operating autonomous system activities, including off-nominal scenarios and autonomous system recoveries. The demonstration of the EXPRESS 2.5 tool is a step towards improved levels of autonomy as our new journeys take us farther into space.

autonomy↗

Ares I-X Flight Test--The Future Begins Here

In less than one year, the National Aeronautics and Space Administration (NASA) will launch the Ares I-X mission. This will be the first flight of the Ares I crew launch vehicle, which, together with the Ares V cargo launch vehicle, will send humans to the Moon and beyond. Personnel from the Ares I-X Mission Management Office (MMO) are finalizing designs and fabricating vehicle hardware for a 2009 launch. Ares I-X will be a suborbital development flight test that will gather critical data about the flight dynamics of the integrated launch vehicle stack; understand how to control its roll during flight; better characterize the severe stage separation environments that the upper stage engine will experience during future flights; and demonstrate the first stage recovery system. NASA also will modify the launch infrastructure and ground and mission operations. The Ares I-X Flight Test Vehicle (FTV) will incorporate flight and mockup hardware similar in mass and weight to the operational vehicle. It will be powered by a four-segment Solid Rocket Booster (SRB), which is currently in Shuttle inventory, and will include a fifth spacer segment and new forward structures to make the booster approximately the same size and weight as the five-segment SRB. The Ares I-X flight profile will closely approximate the flight conditions that the Ares I will experience through Mach 4.5, up to approximately 130,000 feet (39,600 meters (m)) and through maximum dynamic pressure ('Max Q') of approximately 800 pounds per square foot (38.3 kilopascals (kPa)). Data from the Ares I-X flight will support the Ares I Critical Design Review (CDR), scheduled for 2010. Work continues on Ares I-X design and hardware fabrication. All of the individual elements are undergoing CDRs, followed by a two-part integrated vehicle CDR in March and July 2008. The various hardware elements are on schedule to begin deliveries to Kennedy Space Center (KSC) in early September 2008. Ares I-X is the first step in the long journey to the Moon and farther destinations. This suborbital test will be NASA's first flight of a new human-rated launch vehicle in more than a generation. This promises to be an exciting time for NASA and the nation, as we reach for new goals in space exploration. A visual presentation is included.

Davis, Stephan R.↗

Ares I-X Flight Test - On the Fast Track to the Future

In less than two years, the National Aeronautics and Space Administration (NASA) will launch the Ares I-X mission. This will be the first flight of the Ares I crew launch vehicle, which, together with the Ares V cargo launch vehicle, will send humans to the Moon and beyond. Personnel from the Ares I-X Mission Management Office (MMO) are finalizing designs and fabricating vehicle hardware for an April 2009 launch. Ares I-X will be a suborbital development flight test that will gather critical data about the flight dynamics of the integrated launch vehicle stack; understand how to control its roll during flight; better characterize the severe stage separation environments that the upper stage engine will experience during future flights; and demonstrate the first stage recovery system. NASA also will modify the launch infrastructure and ground and mission operations. The Ares I-X Flight Test Vehicle (FTV) will incorporate flight and mockup hardware similar in mass and weight to the operational vehicle. It will be powered by a four-segment Solid Rocket Booster (SRB), which is currently in Shuttle inventory, and will include a fifth spacer segment and new forward structures to make the booster approximately the same size and weight as the five-segment SRB. The Ares I-X flight profile will closely approximate the flight conditions that the Ares I will experience through Mach 4.5, up to approximately130,OOO feet and through maximum dynamic pressure ("Max Q") of approximately 800 pounds per square foot. Data from the Ares I-X flight will support the Ares I Critical Design Review (CDR), scheduled for 2010. Work continues on Ares I-X design and hardware fabrication. All of the individual elements are undergoing CDRs, followed by an integrated vehicle CDR in March 2008. The various hardware elements are on schedule to begin deliveries to Kennedy Space Center (KSC) in early September 2008.

Davis, Stephan R.↗

Distributed science operations for JPL planetary missions

Advances in spacecraft, flight instruments, and ground systems provide an impetus and an opportunity for scientific investigation teams to take direct control of their instruments' operations and data collection while at the same time, providing a cost effective and flexible approach in support of increasingly complex science missions. Operations of science instruments have generally been integrated into planetary flight and ground systems at a very detailed level. That approach has been successful, but the cost of incorporating instrument expertise into the central mission operations system has been high. This paper discusses an approach to simplify planetary science operations by distributing instrument computing and data management tasks from the central mission operations system to each investigator's home center of observational expertise. Some early results of this operations concept will be presented based on the Mars Observer (MO) Project experience and Cassini Project plans.

Benson, Richard D.↗

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗

LST data management and mission operations concept

A candidate design concept for an LST ground facility is described. The design objectives were to use NASA institutional hardware, software and facilities wherever practical, and to maximize efficiency of telescope use. The pointing control performance requirements of LST are summarized, and the major data interfaces of the candidate ground system are diagrammed.

Walker, R.↗

Automated File Transfer and Storage Management Concepts for Space

This presentation will summarize work that has been done to prototype and analyze approaches for automated file transfer and storage management for space missions. The concepts were prototyped in an environment with data files being generated at the target mission rates and stored in onboard files. The space-to-ground link was implemented using a channel simulator to introduce representative mission delays and errors. The system was operated for days with data files building up on the spacecraft and periodically being transferred to ground storage during a limited contact time. Overall performance was measured to identify limits under which the entire data volume could be transferred automatically while still fitting into the mission s limited contact time. The overall concepts, measurements, and results will be presented.

Hogie, Keith↗

Medical Data Architecture Platform and Recommended Requirements for a Medical Data System for Exploration Missions

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically- relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions. In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗

Mars Pathfinder Mission Operations Concept

Mars Pathfinder is one of the first of NASA's Discovery series of low cost planetary missions. A number of innovative design, fabrication, and management techniques have been adopted during the development phase to stay within the percent 150M (FY

Low↗

Smashing the Stovepipe: Leveraging the GMSEC Open Architecture and Advanced IT Automation to Rapidly Prototype, Develop and Deploy Next-Generation Multi-Mission Ground Systems

Satellite/Payload Ground Systems - Typically highly-customized to a specific mission's use cases - Utilize hundreds (or thousands!) of specialized point-to-point interfaces for data flows / file transfers Documentation and tracking of these complex interfaces requires extensive time to develop and extremely high staffing costs Implementation and testing of these interfaces are even more cost-prohibitive, and documentation often lags behind implementation resulting in inconsistencies down the road With expanding threat vectors, IT Security, Information Assurance and Operational Security have become key Ground System architecture drivers New Federal security-related directives are generated on a daily basis, imposing new requirements on current / existing ground systems - These mandated activities and data calls typically carry little or no additional funding for implementation As a result, Ground System Sustaining Engineering groups and Information Technology staff continually struggle to keep up with the rolling tide of security Advancing security concerns and shrinking budgets are pushing these large stove-piped ground systems to begin sharing resources - I.e. Operational / SysAdmin staff, IT security baselines, architecture decisions or even networks / hosting infrastructure Refactoring these existing ground systems into multi-mission assets proves extremely challenging due to what is typically very tight coupling between legacy components As a result, many "Multi-Mission" ops. environments end up simply sharing compute resources and networks due to the difficulty of refactoring into true multi-mission systems Utilizing continuous integration / rapid system deployment technologies in conjunction with an open architecture messaging approach allows System Engineers and Architects to worry less about the low-level details of interfaces between components and configuration of systems GMSEC messaging is inherently designed to support multi-mission requirements, and allows components to aggregate data across multiple homogeneous or heterogeneous satellites or payloads - The highly-successful Goddard Science and Planetary Operations Control Center (SPOCC) utilizes GMSEC as the hub for it's automation and situational awareness capability Shifts focus towards getting GS to a final configuration-managed baseline, as well as multi-mission / big-picture capabilities that help increase situational awareness, promote cross-mission sharing and establish enhanced fleet management capabilities across all levels of the enterprise.

GMSEC↗

The feasibility study and evaluation of applying expert system techniques to the mission operations for the AXAF-I spacecraft

Advanced X-ray Astrophysics Facility - Imaging (AXAF-I) is a spacecraft for X-ray emitting sources observation and has been tentatively scheduled for a space shuttle launch in late 1998 at the Kennedy Space Center. Its main objectives are 'to determine the nature of astronomical objects ranging from normal stars to quasars, to understand the nature of the physical processes which take place in and between astronomical objects, and to add to our understanding of the history and evolution of the universe.' The AXAF-I will have an expected five year life time for the science mission phase. During the science mission phase, the monitoring and management operation of the flight and ground systems is personnel intensive, requiring system experts on duty around the clock. The purpose of the expert system presented in this report is intended to reduce the level of expertise, training, and personnel requirement for the mission operation. The telemetry data from the spacecraft can be divided into two categories: the science observation data and the engineering status data. The science data contains the outputs from the X-ray sensing devices and will be forwarded to the AXAF-I Science Center for interpretation; while the engineering status data will be monitored by the Operation Control Center (OCC) for the operation diagnosis of the spacecraft. The expert system is designed to assist the operation controllers at the OCC to perform the daily mission operations. Since there are hundreds of engineering telemetry data points and the interpretation of the telemetry depends on many factors, e.g., sun or eclipse, the monitoring of the AXAF-I is not a trivial task. In this phase of expert system development, the focus has been limited to the engineering data interpretation, i.e., warnings will be provided to the operation controllers to signal any anomaly. The system is hosted in a Silicon Graphics Indigo-2 workstation running the IRIX operating system. The expert system tool used is the G2 system from Gensym (Gensy).

Chang, Kai H.↗

Evaluating the Viability of Compact and Portable X-Ray Systems for an Exploration Medical System in a Ground Demonstration

MOTIVATION FOR INCLUDING X-RAY CAPABILITIES For upcoming exploration missions, the need for enhanced medical care becomes critical due to extended mission durations, significant communication delays, and minimal evacuation opportunities. Previous evidence by our team has revealed that among the 119 medical conditions targeted for management during spaceflight within NASA Exploration Medical Capability’s IMPACT Condition List, at least 36 could benefit from radiography (XR). Utilizing XR for diagnosis and management is hypothesized to significantly improve management of crew health by enabling the immediate evaluation and confirmation of potential injuries or illnesses. Beyond clinical applications, XR also holds potential for non-destructive testing (NDT). This includes applications such as assessing the structural integrity of the spacecraft, analyzing surface and meteorite samples, and inspecting onboard electronics. THREE CANDIDATE X-RAY SYSTEMS CHOSEN FOR GROUND DEMONSTRATION The Exploration Medical Capability Element (ExMC) and the Exploration Medical Integrated Product Team (XMIPT) of the Mars Campaign Office initiated early background work for ground demonstrations. In FY21, ExMC published a Concept of Operations to guide requirements development. By FY23, XMIPT and yet2, a technology scouting and open innovation consulting firm, had completed a market survey and trade study to identify potential miniature XR systems. Selection criteria included commercial-off-the-shelf availability, low mass and volume, and regulatory compliance. The top three candidate devices—Remedi REMEX-KA6, MinXray Impact, and FujiFilm Xair—were acquired to characterize the requirements and capabilities of each device. To facilitate testing, phantoms, and radiographic personal protective equipment (PPE) were purchased, and a dedicated space was designated for XRS usage at Glenn Research Center. During this presentation, the mass, volume, and power requirements for each of the three piloted devices are revealed, as well as information regarding the detector, mA, and kV of the devices. GOAL AND OBJECTIVES OF A MINI XRS GROUND DEMONSTRATION The primary goal of ExMC/XMIPT technology demonstrations is to bridge the gap in available, flight-ready medical device technology by flight-testing diagnostic and treatment technologies essential for managing medical conditions during exploration missions. These technologies must adhere to vehicle constraints such as mass, volume, power, and data requirements, integrate seamlessly with medical decision-support tools, and support increasingly Earth-independent operations. There are three main objectives for the future ground demonstration of these three devices. First, we aim to determine the full capabilities of these three miniature XR systems within the context of the spaceflight environment. While medical applications are the primary focus for the miniature XR, a comprehensive exploration of non-medical uses has been initiated by an XMIPT-sponsored NASA SPARK campaign to identify collaborators. Second, we plan to establish criteria and to use insights gained from evaluating each miniature XR against those criteria to select the most suitable system among the three candidates. Third, we intend to evaluate their suitability for flight certification, which includes assessing its durability for launch, reentry, and exposure to high background radiation, as well as its compatibility with existing data architecture systems. Numerous subject matter experts from NASA and partner institutions will support these objectives.

C A Haddix↗

Exploration Medical Capability Clinical Decision Support System Concept of Operations

The Clinical Decision Support (CDS) project supports the Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP). Specifically, the CDS project addresses the ExMC gap, Medical-701: Enhance medical capabilities within an exploration medical system. For long-duration, deep space missions, computational and data resources will play an important role in maintaining crew health, wellness and performance where the crew will need to be more self-reliant as we enter a new era in space exploration to return to the moon and explore Mars. These ambitious goals will require significant change in in-flight medical care due to constraints on mass, volume, power, crew time, skills reduction over time and medical evacuation capabilities. These constraints make it absolutely necessary to develop transformative solutions using new technologies. Unlike the current paradigm for crew health in low-Earth orbit missions that rely on constant communication with Mission Control, the deep space missions will experience communication delays and possibly, no communications for finite periods of time. Hence, crew health management will benefit from analytics’ capabilities to augment decision support. A comprehensive, multi-functional on-board clinical decision support system (CDSS) will help crews assess and diagnose conditions, decide appropriate responses, and guide the provision of tailored and evidence-based treatments, while reflecting contextual factors and constraints. The context may include present and historical data, viable diagnostic equipment, available supplies and medications, and vehicle and environmental health. Communication time with ground-based personnel is delayed or non-existent during significant portions of the mission so the crew will need to autonomously respond to health, performance and medical situations, particularly those that are unplanned. The CDSS must also provide additional capabilities as complex as training for an emergency situation while augmenting non-expert practitioner skillsets if the Crew Medical Officer (CMO) is incapacitated, and as routine as facilitating delayed communication with flight surgeons on the ground. The CDSS must connect complex issues involving health, wellness, task performance and environmental domains. Furthermore, CDSS functionality will focus on semi-autonomous and autonomous decision-making by the crew that is necessary to address challenges in executing a self-contained medical system that enables health care without assistance from ground clinical experts. The document, ExMC CDSS Architecture Recommendation, (HRP- 48032) establishes a description of the envisioned CDSS architecture. The analytics, descriptive or advanced, contained in a CDSS will interface with the integrated crew health and performance architecture that provides the appropriate data sets. The aim of the CDS project is to develop requirements for a CDSS through a series of test-bed prototype developments and demonstrations.

HRP↗

Evaluation of cryogenic system test options for the OTV on-orbit propellant depot

Future space missions to geosynchronous, lunar, and planetary orbits will require an orbital depot for stockpiling propellants. This depot will provide long-term storage of cryogens, requiring new technologies for fluid management in microgravity and further development of thermal management technologies for minimization of cryogen boiloff. Preliminary evaluations have been made to define a test program approach for reducing technical risk through verifying performance models and building a base of engineering data for depot design. A number of testing options were defined and evaluated, leading to selection of ground testing combined with an orbital systems test. Ground testing is inadequate because of critical microgravity concerns; extending testing aboard the Space Station was eliminated because the data would not be available soon enough to benefit the propellant depot design. The orbital test would either be a short-term test carried out in the cargo bay of the Space Shuttle Orbiter using a nonhazardous cryogen or a longer term test carried out with hydrogen aboard a free-flying experiment orbited with an expendable launch vehicle.

Schuster, John R.↗

A knowledge-based flight status monitor for real-time application in digital avionics systems

The Dryden Flight Research Facility of the National Aeronautics and Space Administration (NASA) Ames Research Center (Ames-Dryden) is the principal NASA facility for the flight testing and evaluation of new and complex avionics systems. To aid in the interpretation of system health and status data, a knowledge-based flight status monitor was designed. The monitor was designed to use fault indicators from the onboard system which are telemetered to the ground and processed by a rule-based model of the aircraft failure management system to give timely advice and recommendations in the mission control room. One of the important constraints on the flight status monitor is the need to operate in real time, and to pursue this aspect, a joint research activity between NASA Ames-Dryden and the Royal Aerospace Establishment (RAE) on real-time knowledge-based systems was established. Under this agreement, the original LISP knowledge base for the flight status monitor was reimplemented using the intelligent knowledge-based system toolkit, MUSE, which was developed under RAE sponsorship. Details of the flight status monitor and the MUSE implementation are presented.

Duke, E. L.↗

Mark IVA DSN 26-meter Subnet

The Office of Space Tracking and Data Systems' Networks Consolidation Program (NCP), managed by the Jet Propulsion Laboratory (JPL), includes the implementation of a 26-meter Tracking and Communications Subnet as a part of the Mark IV A Deep Space Network (DSN). The incorporatin of this subnet into the DSN will contribute to the NCP goal of consolidating the two NASA ground tracking networks into one tracking network. The 26-meter Tracking and Communication Subnet was designed to provide the capability to support, at each Deep Space Communication Complex, the tracking and data communication requirements of the earth-orbital missions that cannot be supported by the Tracking and Data Relay Satellite System when it becomes operational. Implementation activities and planned capabilities of the subnet are discussed.

Gordon, D. D.↗