Integrated information management
Explore the source record for details and available documents.
onboard data management↗
SEARCH · Search NASA
Results for “onboard data management”
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.
Data management for the Skylab program
Skylab program data management systems, discussing onboard data collection, transmission and ground facilities
Disher, J. H.↗
A guide to onboard checkout. Volume 5: Data management
The baseline data management subsystem for a space station is discussed. The subsystem consists of equipment necessary to transfer, store, and process data to and from users and subsystems. It acquires and conditions a wide variety of input data from experiments, vehicle subsystems sensors, uplinked ground communications, and astronaut-activated controls. Computer techniques for failure analysis, reliability, and maintenance checkout onboard the space station are considered.
Source record↗
Supervisory System for On-board Checkout and Data Management System /OCDMS/, SATURN/APOLLO Application Program
Computer program requirements for onboard checkout and data management system of Saturn/Apollo application program
SATURN LAUNCH VEHICLE↗
Modular space station detailed preliminary design. Volume 1: Sections 1 through 4.4
Detailed configuration and subsystems preliminary design data are presented for the modular space station concept. Each module comprising the initial space station is described in terms of its external and internal configuration, its functional responsibilities to the initial cluster, and its orbital build up sequence. Descriptions of the subsequent build up to the growth space station are also presented. Analytical and design techniques, tradeoff considerations, and depth of design detail are discussed for each subsystem. The subsystems include the following: structural/mechanical; crew habitability and protection; experiment support; electrical power; environmental control/life support; guidance, navigation, and control; propulsion; communications; data management; and onboard checkout subsystems. The interfaces between the station and other major elements of the program are summarized. The rational for a zero-gravity station, in lieu of one with artificial-gravity capability, is also summarized.
Source record↗
EDOS Evolution to Support NASA Future Earth Sciences Missions
This paper presents a ground system architecture to service future NASA decadal missions and in particular, the high rate science data downlinks, by evolving EDOS current infrastructure and upgrading high rate network lines. The paper will also cover EDOS participation to date in formulation and operations concepts for the respective missions to understand the particular mission needs and derived requirements such as data volumes, downlink rates, data encoding, and data latencies. Future decadal requirements such as onboard data recorder management and file protocols drive the need to emulate these requirements within the ground system. The EDOS open system modular architecture is scalable to accommodate additional missions using the current sites antennas and future sites as well and meet the data security requirements and fulfill mission's objectives
Cordier, Guy R.↗
Science and Applications Space Platform (SASP) End-to-End Data System Study
The capability of present technology and the Tracking and Data Relay Satellite System (TDRSS) to accommodate Science and Applications Space Platforms (SASP) payload user's requirements, maximum service to the user through optimization of the SASP Onboard Command and Data Management System, and the ability and availability of new technology to accommodate the evolution of SASP payloads were assessed. Key technology items identified to accommodate payloads on a SASP were onboard storage devices, multiplexers, and onboard data processors. The primary driver is the limited access to TDRSS for single access channels due to sharing with all the low Earth orbit spacecraft plus shuttle. Advantages of onboard data processing include long term storage of processed data until TRDSS is accessible, thus reducing the loss of data, eliminating large data processing tasks at the ground stations, and providing a more timely access to the data.
Crawford, P. R.↗
Built-In-Checkout /BIC/
Proposed checkout system for interface of onboard and ground data management in manned space flight programs
Source record↗
Study on Spacelab software development and integration concepts
A study was conducted to define the complexity and magnitude of the Spacelab software challenge. The study was based on current Spacelab program concepts, anticipated flight schedules, and ground operation plans. The study was primarily directed toward identifying and solving problems related to the experiment flight application and tests and checkout software executing in the Spacelab onboard command and data management subsystem (CDMS) computers and electrical ground support equipment (EGSE). The study provides a conceptual base from which it is possible to proceed into the development phase of the Software Test and Integration Laboratory (STIL) and establishes guidelines for the definition of standards which will ensure that the total Spacelab software is understood prior to entering development.
Source record↗
Formalizing structured file services for the data storage and retrieval subsystem of the data management system for Spacestation Freedom
A brief example of the use of formal methods techniques in the specification of a software system is presented. The report is part of a larger effort targeted at defining a formal methods pilot project for NASA. One possible application domain that may be used to demonstrate the effective use of formal methods techniques within the NASA environment is presented. It is not intended to provide a tutorial on either formal methods techniques or the application being addressed. It should, however, provide an indication that the application being considered is suitable for a formal methods by showing how such a task may be started. The particular system being addressed is the Structured File Services (SFS), which is a part of the Data Storage and Retrieval Subsystem (DSAR), which in turn is part of the Data Management System (DMS) onboard Spacestation Freedom. This is a software system that is currently under development for NASA. An informal mathematical development is presented. Section 3 contains the same development using Penelope (23), an Ada specification and verification system. The complete text of the English version Software Requirements Specification (SRS) is reproduced in Appendix A.
Jamsek, Damir A.↗
Management of the Space Station Freedom onboard local area network
An operational approach is proposed to managing the Data Management System Local Area Network (LAN) on Space Station Freedom. An overview of the onboard LAN elements is presented first, followed by a proposal of the operational guidelines by which management of the onboard network may be effected. To implement the guidelines, a recommendation is then presented on a set of network management parameters which should be made available in the onboard Network Operating System Computer Software Configuration Item and Fiber Distributed Data Interface firmware. Finally, some implications for the implementation of the various network management elements are discussed.
Miller, Frank W.↗
Telemetry handling on the Space Station data management system
This paper examines the impact of telemetry handling on the design of the onboard networks that are part of the Space Station Data Management System (DMS). An architectural approach to satisfying the DMS requirement for support of the high throughput needed for telemetry transport and for servicing distributed computer systems is discussed. Several of the functionality vs. performance tradeoffs that must be made in developing an optimized mechanism for handling telemetry data in the DMS are considered.
Whitelaw, Virginia A.↗
The space station - An overview of the design process
The design factors being considered in the NASA space-station development program are summarized. The currently envisioned mission requirements are listed, and the system architecture is defined as a core station, mission-dedicated elements, and supporting equipment such as an orbit maneuvering vehicle. System design factors discussed include orbit selection, contamination control, autonomy, system safety, technology implementation, long life, reliability and maintainability, and cost; subsystem design factors include structural considerations, electrical power, environmental control and life support, data management, communications and tracking, onboard propulsion, habitability, and crew support. Configurational design is seen as driven by a number of factors, primarily the need to fit all components into the Shuttle payload bay for assembly in LEO by the Shuttle crew.
Covington, C.↗
The TAVERNS emulator: An Ada simulation of the space station data communications network and software development environment
The Space Station DMS (Data Management System) is the onboard component of the Space Station Information System (SSIS) that includes the computers, networks and software that support the various core and payload subsystems of the Space Station. TAVERNS (Test And Validation Environment for Remote Networked Systems) is a distributed approach for development and validation of application software for Space Station. The TAVERNS concept assumes that the different subsystems will be developed by different contractors who may be geographically separated. The TAVERNS Emulator is an Ada simulation of a TAVERNS on the ASD VAX. The software services described in the DMS Test Bed User's Manual are being emulated on the VAX together with simulations of some of the core subsystems and a simulation of the DCN. The TAVERNS Emulator will be accessible remotely from any VAX that can communicate with the ASD VAX.
Howes, Norman R.↗
SSFP approach to software reuse
This talk began by presenting the Space Station Freedom Program (SSFP) definitions of software commonality and software reuse. Software commonality is the use of identical, interchangeable, functionally compatible, or similar software items to satisfy different sets of functionally similar requirements. The Software Support Environment (SSE) and the Data Management System (DMS) of onboard computing facilities are examples of SSFP common software. Software reuse is the use of identical, compatible, or similar software items in either modified or unmodified form to satisfy development activities at any point in the software life cycle; in other words, taking an existing item and applying it to another development activity. Software commonality has been mandated in several critical areas (such as the SSE and DMS) and a policy directive is under review. A software reuse study group was established in May 1988 to gather background information (see Level 2 Software Reuse Study that follows by Scott Herman). The SSFP Program Definition and Requirements Document contains requirements for SSE support in the area of software reuse. The SSE is a collection of tools and rules, and provides the common environment to be used for the life cycle management of all SSFP operational software.
Snyder, Peg↗
Low Latency DESDynI Data Products for Disaster Response, Resource Management and Other Applications
We are developing onboard processor technology targeted at the L-band SAR instrument onboard the planned DESDynI mission to enable formation of SAR images onboard opening possibilities for near-real-time data products to augment full data streams. Several image processing and/or interpretation techniques are being explored as possible direct-broadcast products for use by agencies in need of low-latency data, responsible for disaster mitigation and assessment, resource management, agricultural development, shipping, etc. Data collected through UAVSAR (L-band) serves as surrogate to the future DESDynI instrument. We have explored surface water extent as a tool for flooding response, and disturbance images on polarimetric backscatter of repeat pass imagery potentially useful for structural collapse (earthquake), mud/land/debris-slides etc. We have also explored building vegetation and snow/ice classifiers, via support vector machines utilizing quad-pol backscatter, cross-pol phase, and a number of derivatives (radar vegetation index, dielectric estimates, etc.). We share our qualitative and quantitative results thus far.
applications↗
Performance issues in management of the Space Station Information System
The onboard segment of the Space Station Information System (SSIS), called the Data Management System (DMS), will consist of a Fiber Distributed Data Interface (FDDI) token-ring network. The performance of the DMS in scenarios involving two kinds of network management is analyzed. In the first scenario, how the transmission of routine management messages impacts performance of the DMS is examined. In the second scenario, techniques for ensuring low latency of real-time control messages in an emergency are examined.
Johnson, Marjory J.↗
DC-magnetic field vector measurement
A magnetometer experiment was designed to determine the local magnetic field by measuring the total of the Earth's magnetic field and that of an unknown spacecraft. The measured field vector components are available to all onboard experiments via the Spacelab command and data management system. The experiment consists of two parts, an electronic box and the magnetic field sensor. The sensor includes three independent measuring flux-gate magnetometers, each measuring one component. The physical background is the nonlinearity of the B-H curve of a ferrite material. Two coils wound around a ferrite rod are necessary. One of them, a tank coil, pumps the ferrite rod at approximately 20 kilohertz. As a consequence of the nonlinearity, many harmonics can be produced. The second coil (i.e., the detection coil) resonates to the first harmonic. If an unknown dc or low-frequency magnetic field exists, the amplitude of the first harmonic is a measure for the unknown magnetic field. The voltages detected by the sensors are to be digitized and transferred to the command and data management system.
Schmidt, R.↗