SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
The use of remotely sensed data is reported in the eradication of the screwworm and in the study of the role of the weather in the activity and development of the screwworm fly. As a result, the Screwworm Eradication Data System (SEDS) algorithm was developed.
Alternative data systems for a global crop production forecasting system were studied with the aid of a unique simulation facility called the Data System Dynamic Simulator (DSDS). Information system requirements were determined and compared with existing and planned data systems, and deficiencies were identified and analyzed. A first step was to determine the data load for an operational global crop production forecasting system as a function of data frequency, crop types, biophases, cloud coverage, and number of satellites. The DSDS was used to correlate the interrelated influence of orbital parameters, crop calendars, and cloud conditions to generate global data loading profiles. Some of the more important conclusions and the main features of the simulation system are presented.
The Soil Moisture Active Passive (SMAP) Mission is a first tier mission in NASA's Earth Science Decadal Survey. SMAP will provide a global mapping of soil moisture and its freeze/thaw states. This mapping will be used to enhance the understanding of processes that link the terrestrial water, energy, and carbon cycles, and to enhance weather and forecast capabilities. NASA's Jet Propulsion Laboratory has been selected as the lead center for the development and operation of SMAP. The Jet Propulsion Laboratory (JPL) has an extensive history of successful deep space exploration. JPL missions have typically been large scale Class A missions with significant budget and staffing. SMAP represents a new area of JPL focus towards low cost Earth science missions. Success in this new area requires changes to the way that JPL has traditionally provided the Mission Operations System (MOS)/Ground Data System (GDS) functions. The operation of SMAP requires more routine operations activities and support for higher data rates and data volumes than have been achieved in the past. These activities must be addressed by a reduced operations team and support staff. To meet this challenge, the SMAP ground data system provides automation that will perform unattended operations, including automated commanding of the SMAP spacecraft.
NASA's deployment of major space complexes such as Space Station Freedom (SSF) and the Earth Observing System (EOS) will demand increased functionality and performance from ground based telemetry acquisition systems well above current system capabilities. Adaptation of space telemetry data transport and processing standards such as those specified by the Consultative Committee for Space Data Systems (CCSDS) standards and those required for commercial ground distribution of telemetry data, will drive these functional and performance requirements. In addition, budget limitations will force the requirement for higher modularity, flexibility, and interchangeability at lower cost in new ground telemetry data system elements. At NASA's Goddard Space Flight Center (GSFC), the design and development of generic ground telemetry data system elements, over the last five years, has resulted in significant solutions to these problems. This solution, referred to as the functional components approach includes both hardware and software components ready for end user application. The hardware functional components consist of modern data flow architectures utilizing Application Specific Integrated Circuits (ASIC's) developed specifically to support NASA's telemetry data systems needs and designed to meet a range of data rate requirements up to 300 Mbps. Real-time operating system software components support both embedded local software intelligence, and overall system control, status, processing, and interface requirements. These components, hardware and software, form the superstructure upon which project specific elements are added to complete a telemetry ground data system installation. This paper describes the functional components approach, some specific component examples, and a project example of the evolution from VLSI component, to basic board level functional component, to integrated telemetry data system.
NASA's Earth Science Data Systems (ESDS) Program has evolved over the last two decades, and currently has several core and community components. Core components provide the basic operational capabilities to process, archive, manage and distribute data from NASA missions. Community components provide a path for peer-reviewed research in Earth Science Informatics to feed into the evolution of the core components. The Earth Observing System Data and Information System (EOSDIS) is a core component consisting of twelve Distributed Active Archive Centers (DAACs) and eight Science Investigator-led Processing Systems spread across the U.S. The presentation covers how the ESDS Program continues to evolve and benefits from as well as contributes to advances in Earth Science Informatics.
The Multimission Ground Data System (MGDS) at NASA's Jet Propulsion Laboratory has brought improvements and new technologies to mission operations. It was designed as a generic data system to meet the needs of multiple missions and avoid re-inventing capabilities for each new mission and thus reduce costs. It is based on adaptable tools that can be customized to support different missions and operations scenarios. The MGDS is based on a distributed client/server architecture, with powerful Unix workstations, incorporating standards and open system architectures. The distributed architecture allows remote operations and user science data exchange, while also providing capabilities for centralized ground system monitor and control. The MGDS has proved its capabilities in supporting multiple large-class missions simultaneously, including the Voyager, Galileo, Magellan, Ulysses, and Mars Observer missions. The Operations Engineering Lab (OEL) at JPL has been leading Customer Adaptation Training (CAT) teams for adapting and customizing MGDS for the various operations and engineering teams. These CAT teams have typically consisted of only a few engineers who are familiar with operations and with the MGDS software and architecture. Our experience has provided a unique opportunity to work directly with the spacecraft and instrument operations teams and understand their requirements and how the MGDS can be adapted and customized to minimize their operations costs. As part of this work, we have developed workstation configurations, automation tools, and integrated user interfaces at minimal cost that have significantly improved productivity. We have also proved that these customized data systems are most successful if they are focused on the people and the tasks they perform and if they are based upon user confidence in the development team resulting from daily interactions. This paper will describe lessons learned in adapting JPL's MGDS to fly the Voyager, Galileo, and Mars Observer missions. We will explain how powerful, existing ground data systems can be adapted and packaged in a cost effective way for operations of small and large planetary missions. We will also describe how the MGDS was adapted to support operations within the Galileo Spacecraft Testbed. The Galileo testbed provided a unique opportunity to adapt MGDS to support command and control operations for a small autonomous operations team of a handful of engineers flying the Galileo Spacecraft flight system model.
The paper describes the development by NASA of the data system dynamic simulation (DSDS) which provides a data system simulation capability for a broad range of programs, with the capability to model and simulate all or any portion of an end-to-end data system to multiple levels of fidelity. Versatility is achieved by specifying parameters which define the performance characteristics of data system components, and by specifying control and data paths in a data system. DSDS helps reduce overall simulation cost and the time required for obtaining a data systems analysis, and helps provide both early realistic representations of data systems and the flexibility to study design changes and operating strategies.
During the launch of Mars Odyssey, ground data system (GDS) engineers experienced a glitch in the ground data system that caused us to re-evaluate how we looked at spacecraft telemetry, particularly during the spacecraft development period and for critical spacecraft events in flight. Spacecraft telemetry told the subsystem and instrument engineers about the health and status of the spacecraft, but there was surprisingly little information about how well the ground data system was doing in getting information from the spacecraft to the engineers.The problem for the Mars Odyssey launch was with a single channel not updating as often as expected. Spacecraft engineers considered calling off the Launch but eventually decided that this particular channel did not provide information that was crucial for launch. It was only after the post launch acquisition of the Odyssey signal that ground data system engineers heard there had been a concern about the channel....
A contract with the Data Systems and Analysis Directorate contains a specified level of resources related to a specific set of work in support of three divisions within the Data Systems and Analysis Directorate. The divisions are Institutional Data Systems Division, Ground Data Systems Division, and Mission Planning and Analysis Division. The Statement of work defines at a functional requirements level the type of support to be provided to the three divisions. The contract provides for further technical direction to the contractor through issuance of Job Orders. The Job order is the prime method of further defining the work to be done, allocating a portion of the total resources in the contract to the defined tasks, and further delegating technical responsibility.
Real time airborne data acquisition, archiving and distribution on the NASA/Ames Research Center (ARC) C-130 has been improved over the past three years due to the implementation of the C-130 Automated Digital Data System (CADDS). CADDS is a real time, multitasking, multiprocessing ROM-based system. CADDS acquires data from both avionics and environmental sensors inflight for all C-130 data lines. The system also displays the data on video monitors throughout the aircraft.
NASA has chaired the Consultative Committee for Space Data Systems (CCSDS) for the past four years. During that time, a top-level, end-to-end reference model for space data sytems has been developed that identifies the functions anad services which must be provided by space data systems, and defines the interfaces between major functional elements. A group of definitions for standard protocols has been derived by analyzing these interfaces, and a set of detailed guidelines for space data system standards is in the final stages of negotiation among member CCSDS agencies. Two guidelines that address packet telemetry and channel coding have been approved and are being incorporated into the internal standards of member agencies. Others (packet telecommand, time code, standards data format unit) are in review within CCSDS technical panels and will soon be submitted for approval. These guidelines provide a mechanism for significant cost savings in the implementation of space data systems by allowing reuse of hardware and software for different payloads and for missions, and by enabling the substitution of new technology/higher performance elements at key points in the data system without causing major perturbations in the remainder of the system.
A software methodology for JPL deep space network (DSN) data systems software implementations through transfer and delivery is presented. The DSN Data Systems Software Methodology is compatible with and depends on DSN software methodology and also incorporates the characteristics of real-time program development in a DSN environment. The DSN Data Systems software implementation consists of a series of six distinct phases. An Independent Group is responsible for verification and validation of the DSN Data Systems software during developing phases. The DSN data systems software methodology is applied to all development software provided for or by the DSN data systems section in Mark IV where there is a desire for reliability, maintainability, and usability within budget and schedule constraints.
The Mission Operations and Data Systems Directorate (MO&DSD) has embarked on a new approach for developing and operating Ground Data Systems (GDS) for flight mission support. This approach is driven by the goals of minimizing cost and maximizing customer satisfaction. Achievement of these goals is realized through the use of a standard set of capabilities which can be modified to meet specific user needs. This approach, which is called the Renaissance architecture, stresses the engineering of integrated systems, based upon workstation/local area network (LAN)/fileserver technology and reusable hardware and software components called 'building blocks.' These building blocks are integrated with mission specific capabilities to build the GDS for each individual mission. The building block approach is key to the reduction of development costs and schedules. Also, the Renaissance approach allows the integration of GDS functions that were previously provided via separate multi-mission facilities. With the Renaissance architecture, the GDS can be developed by the MO&DSD or all, or part, of the GDS can be operated by the user at their facility. Flexibility in operation configuration allows both selection of a cost-effective operations approach and the capability for customizing operations to user needs. Thus the focus of the MO&DSD is shifted from operating systems that we have built to building systems and, optionally, operations as separate services. Renaissance is actually a continuous process. Both the building blocks and the system architecture will evolve as user needs and technology change. Providing GDS on a per user basis enables this continuous refinement of the development process and product and allows the MO&DSD to remain a customer-focused organization. This paper will present the activities and results of the MO&DSD initial efforts toward the establishment of the Renaissance approach for the development of GDS, with a particular focus on both the technical and process implications posed by Renaissance to the MO&DSD.
A feasible, top-level data system is defined that could accomplish and support the Astromag Data System functions and interfaces necessary to support the scientific objectives of Astromag. This data system must also be able to function in the environment of the Space Station Freedom Manned Base (SSFMB) and other anticipated NASA elements.
Two rotating data systems for engine component testing which demonstrate the techniques of on-the-shaft microelectronic signal conditioning and rotary transformer power- and data-transfer are described. (1) A digital data system provides 69 channels of 1100 C maximum thermocouple data with less than 0.5 percent error from a turbine test rig rotating at speeds up to 9000 rpm. (2) An analog data system amplifies and transfers 72 channels of dynamic strain data with less than 5 percent error from a compressor rig at speeds above 14,000 rpm.
Automatic radiosonde data processing system providing azimuth and elevation angles, temperature, humidity, etc
The NASA Astrophysics Data System (ADS) is a distributed information system intended to support research in the Great Observatories era, to simplify access to data, and to enable simultaneous analyses of multispectral data sets. Here, the user agent and interface, its functions, and system components are examined, and the system architecture and infrastructure is addressed. The present status of the system and related future activities are examined.
The Self-Defining Data System (SDS) is a system which allows the creation of self-defining hierarchical data structures in a form which allows the data to be moved between different machine architectures. Because the structures are self-defining they can be used for communication between independent modules in a distributed system. Unlike disk-based hierarchical data systems such as Starlink's HDS, SDS works entirely in memory and is very fast. Data structures are created and manipulated as internal dynamic structures in memory managed by SDS itself. A structure may then be exported into a caller supplied memory buffer in a defined external format. This structure can be written as a file or sent as a message to another machine. It remains static in structure until it is reimported into SDS. SDS is written in portable C and has been run on a number of different machine architectures. Structures are portable between machines with SDS looking after conversion of byte order, floating point format, and alignment. A Fortran callable version is also available for some machines.