Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software Quality Assurance”

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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRS1999

Model Checking Verification and Validation at JPL and the NASA Fairmont IV and V Facility

We show how a technology transfer effort was carried out. The successful use of model checking on a pilot JPL flight project demonstrates the usefulness and the efficacy of the approach. The pilot project was used to model a complex spacecraft controller. Software design and implementation validation were carried out successfully. To suggest future applications we also show how the implementation validation step can be automated. The effort was followed by the formal introduction of the modeling technique as a part of the JPL Quality Assurance process.

Schneider, Frank↗
NASA NTRS1990

Management and display of four-dimensional environmental data sets using McIDAS

Over the past four years, great strides have been made in the areas of data management and display of 4-D meteorological data sets. A survey was conducted of available and planned 4-D meteorological data sources. The data types were evaluated for their impact on the data management and display system. The requirements were analyzed for data base management generated by the 4-D data display system. The suitability of the existing data base management procedures and file structure were evaluated in light of the new requirements. Where needed, new data base management tools and file procedures were designed and implemented. The quality of the basic 4-D data sets was assured. The interpolation and extrapolation techniques of the 4-D data were investigated. The 4-D data from various sources were combined to make a uniform and consistent data set for display purposes. Data display software was designed to create abstract line graphic 3-D displays. Realistic shaded 3-D displays were created. Animation routines for these displays were developed in order to produce a dynamic 4-D presentation. A prototype dynamic color stereo workstation was implemented. A computer functional design specification was produced based on interactive studies and user feedback.

Hibbard, William L.↗
NASA NTRS1999

A Methodology for Writing High Quality Requirements Specification and Evaluating Existing Ones

Requirements development and management have always been critical in the implementation of software systems; engineers are unable to build what analysts can't define. It is generally accepted that the earlier in the life cycle potential risks are identified the easier it is to eliminate or manage the conditions that introduce that risk. Problems that are not found until testing are approximately 14 times more costly to fix than if the problem was found in the requirement phase. The requirements specification, as the first tangible representation of the capability to be produced, establishes the basis for all of the project's engineering management and assurance functions. If the quality of the requirements specification is poor it can give rise to risks in all areas of the project. Recently, automated tools have become available to support requirements management. The use of these tools not only provides support in the definition and tracing of requirements, but it also opens the door to effective use of metrics in characterizing and assessing the quality of the requirement specifications.

Rosenberg, Linda↗
NASA NTRS1999

A Methodology for Writing High Quality Requirement Specifications and for Evaluating Existing Ones

Requirements development and management have always been critical in the implementation of software systems-engineers are unable to build what analysts can not define. It is generally accepted that the earlier in the life cycle potential risks are identified the easier it is to eliminate or manage the conditions that introduce that risk. Problems that are not found until testing are approximately 14 times more costly to fix than if the problem was found in the requirement phase. The requirements specification, as the first tangible representation of the capability to be produced, establishes the basis for all of the project's engineering management and assurance functions. If the quality of the requirements specification is poor it can give rise to risks in all areas of the project. Recently, automated tools have become available to support requirements management. The use of these tools not only provides support in the definition and tracing of requirements, but it also opens the door to effective use of metrics in characterizing and assessing the quality of the requirement specifications.

Rosenberg, Linda↗
NASA NTRS2007

Design and Data Management System

The Design and Data Management System (DDMS) was developed to automate the NASA Engineering Order (EO) and Engineering Change Request (ECR) processes at the Propulsion Test Facilities at Stennis Space Center for efficient and effective Configuration Management (CM). Prior to the development of DDMS, the CM system was a manual, paper-based system that required an EO or ECR submitter to walk the changes through the acceptance process to obtain necessary approval signatures. This approval process could take up to two weeks, and was subject to a variety of human errors. The process also requires that the CM office make copies and distribute them to the Configuration Control Board members for review prior to meetings. At any point, there was a potential for an error or loss of the change records, meaning the configuration of record was not accurate. The new Web-based DDMS eliminates unnecessary copies, reduces the time needed to distribute the paperwork, reduces time to gain the necessary signatures, and prevents the variety of errors inherent in the previous manual system. After implementation of the DDMS, all EOs and ECRs can be automatically checked prior to submittal to ensure that the documentation is complete and accurate. Much of the configuration information can be documented in the DDMS through pull-down forms to ensure consistent entries by the engineers and technicians in the field. The software also can electronically route the documents through the signature process to obtain the necessary approvals needed for work authorization. The workflow of the system allows for backups and timestamps that determine the correct routing and completion of all required authorizations in a more timely manner, as well as assuring the quality and accuracy of the configuration documents.

Messer, Elizabeth↗
NASA NTRS2006

CCSDS Time-Critical Onboard Networking Service

The Consultative Committee for Space Data Systems (CCSDS) is developing recommendations for communication services onboard spacecraft. Today many different communication buses are used on spacecraft requiring software with the same basic functionality to be rewritten for each type of bus. This impacts on the application software resulting in custom software for almost every new mission. The Spacecraft Onboard Interface Services (SOIS) working group aims to provide a consistent interface to various onboard buses and sub-networks, enabling a common interface to the application software. The eventual goal is reusable software that can be easily ported to new missions and run on a range of onboard buses without substantial modification. The system engineer will then be able to select a bus based on its performance, power, etc and be confident that a particular choice of bus will not place excessive demands on software development. This paper describes the SOIS Intra-Networking Service which is designed to enable data transfer and multiplexing of a variety of internetworking protocols with a range of quality of service support, over underlying heterogeneous data links. The Intra-network service interface provides users with a common Quality of Service interface when transporting data across a variety of underlying data links. Supported Quality of Service (QoS) elements include: Priority, Resource Reservation and Retry/Redundancy. These three QoS elements combine and map into four TCONS services for onboard data communications: Best Effort, Assured, Reserved, and Guaranteed. Data to be transported is passed to the Intra-network service with a requested QoS. The requested QoS includes the type of service, priority and where appropriate, a channel identifier. The data is de-multiplexed, prioritized, and the required resources for transport are allocated. The data is then passed to the appropriate data link for transfer across the bus. The SOIS supported data links may inherently provide the quality of service support requested by the intra-network layer. In the case where the data link does not have the required level of support, the missing functionality is added by SOIS. As a result of this architecture, re-usable software applications can be designed and used across missions thereby promoting common mission operations. In addition, the protocol multiplexing function enables the blending of multiple onboard networks. This paper starts by giving an overview of the SOIS architecture in section 11, illustrating where the TCONS services fit into the overall architecture. It then describes the quality of service approach adopted, in section III. The prototyping efforts that have been going on are introduced in section JY. Finally, in section V the current status of the CCSDS recommendations is summarized.

Parkes, Steve↗
NASA NTRS1996

The Role of Independent V&V in Upstream Software Development Processes

This paper describes the role of Verification and Validation (V&V) during the requirements and high level design processes, and in particular the role of Independent V&V (IV&V). The job of IV&V during these phases is to ensure that the requirements are complete, consistent and valid, and to ensure that the high level design meets the requirements. This contrasts with the role of Quality Assurance (QA), which ensures that appropriate standards and process models are defined and applied. This paper describes the current state of practice for IV&V, concentrating on the process model used in NASA projects. We describe a case study, showing the processes by which problem reporting and tracking takes place, and how IV&V feeds into decision making by the development team. We then describe the problems faced in implementing IV&V. We conclude that despite a well defined process model, and tools to support it, IV&V is still beset by communication and coordination problems.

Easterbrook, Steve↗
NASA NTRS2012

The Algorithm Theoretical Basis Document for Level 1A Processing

The first process of the Geoscience Laser Altimeter System (GLAS) Science Algorithm Software converts the Level 0 data into the Level 1A Data Products. The Level 1A Data Products are the time ordered instrument data converted from counts to engineering units. This document defines the equations that convert the raw instrument data into engineering units. Required scale factors, bias values, and coefficients are defined in this document. Additionally, required quality assurance and browse products are defined in this document.

Jester, Peggy L.↗
NASA NTRS2016

Modifying a Commercial Centrifuge to Reduce Electromagnetic Interference and Evaluating Functionality of Ultrasound Equipment

The Project Management and Engineering Branch (SF4) supports the Human Health and Performance Directorate (HH&P) and is responsible for developing and supporting human systems hardware for the International Space Station (ISS). When a principal investigator's (PI) medical research project on the ISS is accepted, SF4 develops the necessary hardware and software to transport to the ISS. The two projects I primarily worked on were the centrifuge and ultrasound projects. Centrifuge: One concern with spacecraft such as the ISS is electromagnetic interference (EMI) from onboard equipment, typically from radio waves (frequencies of ~3 kHz to ~300 GHz), which can negatively affect nearby circuitry. Standard commercial centrifuges produce EMI above safety limits, so my task was to help reduce EMI production from this equipment. Two centrifuges were tested: one unmodified as a control and one modified. To reduce EMI below safety limits, one centrifuge was modified to become a Faraday shield, in which significant electrical contact was made between all regions of the centrifuge housing. This included removing non-conductive paint, applying conductive fabric to the lid and foam sealer, adding a 10,000 μF decoupling capacitor across the power supply, and adding copper adhesive-mount gaskets to the housing interior. EMI testing of both centrifuges was performed in the EMI/EMC Control Test and Measurement Facility. EMI for both centrifuges was below safety limits for frequencies between 10 MHz and 15 GHz (pass); however, between 14 kHz and 10 MHz, EMI for the unmodified centrifuge exceeded safety limits (fail) as expected. Alternatively, for the modified centrifuge with the Faraday shield, EMI was below the safely limit of 55 dBμV/m for electromagnetic frequencies between 14 kHz and 10 MHz. This result indicates our modifications were successful. The successful EMI test allowed us to communicate with the vendor what modifications they needed to make to their commercial unit to meet our specifications and to understand what needs to be done in lab to the new centrifuge. Our modifications will provide a standard for readying centrifuges for future missions. Once the new modified centrifuge arrives by the vendor, it will need to undergo EMI testing again for validation. The centrifuge is also in the process of compatibility testing with a custom stowage drawer, which is an ongoing project in SF4. Both of these items will be payloads on future missions to the ISS for various research purposes. Ultrasound: ISS currently has an onboard ultrasound (Ultrasound 2 system) for research and medical purposes. Every piece of medical flight hardware has an equivalent ground-unit so instrumentation can be routinely evaluated and transported to the ISS if necessary. The ground-unit ultrasound equipment must be evaluated every six months using a task performance sheet (TPS). A TPS is a document, written by the appropriate scientists and engineers, which describes how to run equipment and is written in such a way that astronauts with unspecialized training can follow the tasks. I was responsible for performing six TPSs on a combination of three ultrasounds and two video power converters (VPCs). Performing a TPS involves checking out and computationally documenting each piece of equipment removed from storage locations, setting up hardware and software, performing tasks to verify functionality, returning equipment, and logging items back into the computerized system. My work revealed all ground-unit ultrasounds were functioning properly. Because of proper function, a discrepancy report (DR) did not have to be opened. The TPS was then passed along to the Quality Engineering (QE) for review and ultimately given to Quality Assurance (QA). Other projects: In addition to my main projects, I participated in other tasks including troubleshooting an EEG headband, volunteering for an ultrasound training research study, and conformal coating printed circuit boards. My internship at SF4 has helped me understand how space systems hardware development for the ISS fits into NASA's mission and vision.

Greening, Gage J.↗
NASA NTRS1991

Quality assurance planning for lunar Mars exploration

A review is presented of the tools and techniques required to meet the challenge of total quality in the goal of traveling to Mars and returning to the moon. One program used by NASA to ensure the integrity of baselined requirements documents is configuration management (CM). CM is defined as an integrated management process that documents and identifies the functional and physical characteristics of a facility's systems, structures, computer software, and components. It also ensures that changes to these characteristics are properly assessed, developed, approved, implemented, verified, recorded, and incorporated into the facility's documentation. Three principal areas are discussed that will realize significant efficiencies and enhanced effectiveness, change assessment, change avoidance, and requirements management.

Myers, Kay↗
NASA NTRS1993

Tensoral: A system for post-processing turbulence simulation data

Many computer simulations in engineering and science -- and especially in computational fluid dynamics (CFD) -- produce huge quantities of numerical data. These data are often so large as to make even relatively simple post-processing of this data unwieldy. The data, once computed and quality-assured, is most likely analyzed by only a few people. As a result, much useful numerical data is under-utilized. Since future state-of-the-art simulations will produce even larger datasets, will use more complex flow geometries, and will be performed on more complex supercomputers, data management issues will become increasingly cumbersome. My goal is to provide software which will automate the present and future task of managing and post-processing large turbulence datasets. My research has focused on the development of these software tools -- specifically, through the development of a very high-level language called 'Tensoral'. The ultimate goal of Tensoral is to convert high-level mathematical expressions (tensor algebra, calculus, and statistics) into efficient low-level programs which numerically calculate these expressions given simulation datasets. This approach to the database and post-processing problem has several advantages. Using Tensoral the numerical and data management details of a simulation are shielded from the concerns of the end user. This shielding is carried out without sacrificing post-processor efficiency and robustness. Another advantage of Tensoral is that its very high-level nature lends itself to portability across a wide variety of computing (and supercomputing) platforms. This is especially important considering the rapidity of changes in supercomputing hardware.

Dresselhaus, Eliot↗
NASA NTRSDate not supplied

Quality Assurance of ISS LIS lightning Data

Optical lighting detection from space has been ongoing since 1995 from the Optical Transient detector (1995-2000), then later by the Lightning Imaging Sensors (LIS) on the Tropical Rainfall Measuring Mission (TRMM) satellite (1997-2015) and the International Space Station (ISS) (ISS 2017-present). A rapid readout (2 ms) 128x128 pixel CCD (Charge-coupled Device) array detects optical transients from lightning (events) and transmits the observations to ground. Ground processing determines whether individual events are likely due to lightning or noise. Likely lightning events are then grouped into groups, flashes, and areas and their location on the earth are determined. The lightning data are saved in orbit files; each file containing the time, location, and intensity of the lightning events, groups, flashes, and areas detected during one orbit. Even after this processing anomalies may exist in some of the orbits. A manual quality assurance (QA) procedure is performed monthly to assess the data and omit orbits with obvious anomalies from the dataset. These files are not included in the final dataset that has undergone QA. The manual QA was developed during the OTD mission to identify artifacts that made it through ground processing algorithms. The manual QA process was continued for the TRMM and ISS LIS missions. Many anomalies have been identified and software updates now address many of them. However, some anomalies still occur in the processed datasets. The manual QA process examines the data for obvious issues in the lightning files that passed through the processing algorithms. These files are considered anomalous and are not included in the final QA dataset. Some issues that may cause an orbit to be considered anomalous include: obvious noise (excess events that make it through the processing), suspect geolocation, and excessive missing data packets. As an example, one way noise manifests is as “streaks” in lightning climatology plots. These streaks are especially apparent in low lightning rate regions (eg., over oceans). Since there is no method at present to extract these anomalies during processing, orbit files with significant anomalies are identified and removed from the final QA ISS LIS dataset. The final QA dataset can be obtained files from the Global Hydrometeorological Resource Center (GHRC). This presentation will provide examples of the various anomalies and examine how often the various anomalies occur and how much data is lost due to the omission of the anomalous orbits. Comparisons with OTD and TRMM LIS will also be examined.

ISS↗
NASA NTRS2006

A Predictive Approach to Eliminating Errors in Software Code

NASA s Metrics Data Program Data Repository is a database that stores problem, product, and metrics data. The primary goal of this data repository is to provide project data to the software community. In doing so, the Metrics Data Program collects artifacts from a large NASA dataset, generates metrics on the artifacts, and then generates reports that are made available to the public at no cost. The data that are made available to general users have been sanitized and authorized for publication through the Metrics Data Program Web site by officials representing the projects from which the data originated. The data repository is operated by NASA s Independent Verification and Validation (IV&V) Facility, which is located in Fairmont, West Virginia, a high-tech hub for emerging innovation in the Mountain State. The IV&V Facility was founded in 1993, under the NASA Office of Safety and Mission Assurance, as a direct result of recommendations made by the National Research Council and the Report of the Presidential Commission on the Space Shuttle Challenger Accident. Today, under the direction of Goddard Space Flight Center, the IV&V Facility continues its mission to provide the highest achievable levels of safety and cost-effectiveness for mission-critical software. By extending its data to public users, the facility has helped improve the safety, reliability, and quality of complex software systems throughout private industry and other government agencies. Integrated Software Metrics, Inc., is one of the organizations that has benefited from studying the metrics data. As a result, the company has evolved into a leading developer of innovative software-error prediction tools that help organizations deliver better software, on time and on budget.

Source record↗
NASA NTRSDate not supplied

Genesis Solar Wind – Capture, Return, Curate and Analyze: Looking Backward and Creating a Timeline

Introduction: In 1997 NASA’S Discovery Program selected the Genesis mission proposal to return solar wind samples to Earth for laboratory analyses. Principal Investigator Donald S. Burnett and the science team defined the purity of collector materials and ability to analyze solar wind composition to the precision required for planetary science. As a small mission, focused on a well-defined science goal, yet needing careful attention to engineering details, the communication among scientists and engineers, nurtured by Don Burnett, was exceptional. Genesis Mission and Curation Legacy: Genesis, as the first U. S. spacecraft to return astromaterial samples since Apollo, not only integrated the mission planning and flight teams, but also the science and sample curation teams during the mission development period. Since Genesis is a sample return mission, the Science Team was essential in certifying the collectors (sample containers for solar atoms). From inception, Genesis established mission funding for returned sample curation. JSC was lead in contamination control during mission preparation, including establishment of an ISO 4 cleanroom facility and use of ultrapure water (UPW) for cleaning flight hardware (and, as it turned out, for cleaning collectors after the mishap). Reliable, fast communication among scientists, engineers and curators at the hands-on level established deep respect among team members and efficient decision-making. JSC’s 50-years of astromaterial sample curation provided experienced sample processors onsite during recovery in Utah (a deep bench for emergency response). Post-recovery curation included iterative collaboration with science sample users to clean or verify cleanliness of samples. The science legacy from Genesis is addressed by Burnett and Jurewicz, this volume. In The Beginning: After Apollo sample return, Burnett and Marcia Neugebauer at JPL began discussing a solar wind sample return, with Neugebauer arguing that separate collection of solar wind regimes was essential science. By 1992 a solar wind sample return mission was presented at a workshop, and by 1994 a mission was proposed named Suess-Urey. The mission was re-proposed under a new name GENESIS and selected in 1997. Susan Niebur captured the Genesis mission history and stories, from high level management documents and from many interviews with participants [2]. Her account lets readers glimpse personality of participants in quotations from interviews. Need and Scope for Detailed Technical Timeline: A timeline constructed from lower level task documents has been initiated to document the resources and skills actually used, as well as task sequence or concurrency. Timelines for high level mission events are captured in two documents [1] [2] and for detailed re-entry events in [3]. A detailed technical timeline for Genesis mission and curation activities will provide data points for lower level tasks, such as ISO 4 curation facility construction time, preparation for nominal sample field recovery, mishap recovery, and UPW expansion. Changes in technology context 1990-2024: Semiconductor technologies were easily accessible in the U.S.A. (1990-1999), and the Genesis team used those resources for cleanroom design and UPW system expansion. Image documentation was changing from film to digital during cleanroom construction and payload cleaning (1997-2001). Engineering design was done using computer aided design proprietary software, making more difficult the archiving of payload configuration and materials. Email of documents, tracked delivery service and virtual meeting capability greatly improved communication efficiency. Information sources – Pre-launch mission preparation: Examples of mission science, engineering and contamination control are collector purity testing, payload design/fabrication and ISO 4 cleanroom construction. Information on timing of these activities comes from facility readiness reviews, management reviews, shipping documents, procurement documents, test reports, travel documents, laboratory logs, Quality Assurance documents, dates on images, participant notebooks and emails. Information sources – Sample return re-entry and field recovery activities: Information comes from event timelines produced by Mid-Air Recovery team, Lockheed team lead notes and from chase video, JPL Quality Assurance. Information also comes from images and logbooks from UTTR cleanroom operations and from curatorial documents. Information sources – Resulting science and sample cleaning processes: Agendas from the annual gatherings of the science team initially trace testing for collector purity/cleanliness, and after sample recovery, include collector cleaning and cleanliness assessment. Post-recovery documents include curatorial orders and procedures, sample allocation documents and LPSC abstracts. Timeline Objectives: A simple spreadsheet timeline with headers DATE, EVENT, PEOPLE, COMMENT, INFORMATION SOURCE has been initiated and currently has over 90 entries. While this is not definitive historical research, it is a quick look at the evolution of Genesis curation with pointers to documents or people with information. Engineers for future missions may find useful points of comparison for development of facilities. References:[1] Genesis Mission Reference Document, (2011) JPL D-62382.[2] Niebur S. M., edited by Brown D. W. (2023) NASA’s Discovery Program: The First 20 Years of Competitive Planetary Exploration, NASA-SP-2023-4238.[3] Genesis Mishap Investigation Board Report, Vol. 1 (July 2005).

solar wind↗
NASA NTRS2023

Extending Aquatic Spectral Information with the First Radiometric IR-B Field Observations

Planetary radiometric observations enable remote sensing of biogeochemical parameters to describe spatiotemporal variability in aquatic ecosystems. For approximately the last half century, the science of aquatic radiometry has established a knowledge base using primarily, but not exclusively, visible wavelengths. Scientific subdisciplines supporting aquatic radiometry have evolved hardware, software, and procedures to maximize competency for exploiting visible wavelength information. This perspective culminates with the science requirement that visible spectral resolution must be continually increased to extract more information. Other sources of information, meanwhile, remain underexploited, particularly information from nonvisible wavelengths. Herein, absolute radiometry is used to evaluate spectral limits for deriving and exploiting aquatic data products, specifically the normalized water-leaving radiance, Γ(λ)⁠, and its derivative products. Radiometric observations presented herein are quality assured for individual wavebands, and spectral verification is conducted by analyzing celestial radiometric results, comparing agreement of above- and in-water observations at applicable wavelengths, and evaluating consistency with bio-optical models and optical theory. The results presented include the first absolute radiometric field observations of Γ(λ) within the IR-B spectral domain (i.e. spanning 1400–3000 nm), which indicate that IR-B signals confer greater and more variable flux than formerly ascribed. Black-pixel processing, a routine correction in satellite and in situ aquatic radiometry wherein a spectrum is offset corrected relative to a nonvisible waveband (often IR-B or a shorter legacy waveband) set to a null value, is shown to degrade aquatic spectra and derived biogeochemical parameters.

aquatic optics↗
NASA NTRS2012

Rapid Analysis, Self-Calibrating Array for Air Monitoring

Human space missions have critical needs for monitoring and control for life support systems. These systems have monitoring needs that include feedback for closed loop processes and quality control for environmental factors. Sensors and monitoring technologies assure that the air environment and water supply for the astronaut crew habitat fall within acceptable limits, and that the life support system is functioning properly and efficiently. The longer the flight duration and the more distant the destination, the more critical it becomes to have carefully monitored and automated control systems for life support. Past experiments with the JPL ENose have demonstrated a lifetime of the sensor array, with the software, of around 18 months. The lifetime of the calibration, for some analytes, was as long as 24 months. We are working on a sensor array and new algorithms that will include sensor response time in the analysis. The preliminary array analysis for two analytes shows that the analysis time, of an event, can be dropped from 45 minutes to less than10 minutes and array training time can be cut substantially. We will describe the lifetime testing of an array and show lifetime data on individual sensors. This progress will lead to more rapid identification of analytes, and faster training time of the array.

Self Calibrating↗
NASA NTRS1990

The FIFE information system

A description is given of the FIFE (First ISLSCP Field Experiment) information system, which was developed to serve FIFE investigators as a tool for designing the experiment and for organizing and manipulating the complex data set. Fulfilling these functions on an experiment-driven timeline led to abandoning the classical sequential development paradigm of software engineering in favor of a more responsive and broadly based approach. The design, development, and operation of the information system supporting the experiment had to be flexible and under direct day-to-day control of scientist/users. Because of the organization around scientific requirements, the system was able to incorporate diverse data types in a systematic way as they became available, to add scientific rigor by identifying data gaps at an early stage, and to provide real-time quality assurance. These factors are important for designing and building future databases and long-term information systems to support interdisciplinary scientific research.

Strebel, Donald E.↗
NASA NTRS1975

The Deep Space Network

This report presents DSN progress in flight project support, tracking and data acquisition (TDA) research and technology, network engineering, hardware and software implementation, and operations. Each issue presents material in some, but not all, of the following categories in the order indicated. - Description of the DSN - Mission Support Ongoing Planetary/Interplanetary Flight Projects Advanced Flight Projects - Radio Science - Special Projects - Supporting Research and Technology Tracking and Ground-Based Navigation Communications--Spacecraft/Ground Station Control and Operations Technology Network Control and Data Processing - Network and Facility Engineering and Implementation Network Network Operations Control Center Ground Communications Deep Space Stations - Operations Network Operations Network Operations Control Center Ground Communications Deep Space Stations - Program Planning TDA Planning Quality Assurance In each issue, the part entitled "Description of the DSN" describes the functions and facilities of the DSN and may report the current configuration of one of the five DSN systems (Tracking, Telemetry, Command, Monitor & Control, and Test & Training). The work described in this report series is either performed or managed by the Tracking and Data Acquisition organization of JPL for NASA.

Tracking and Data Acquisition organization↗