Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “data systems standards”

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 343 records · Page 19
All sourcesNASA NTRSDOE OSTI
NASA NTRS1990

Experience with abstract notation one

The development of computer science has produced a vast number of machine architectures, programming languages, and compiler technologies. The cross product of these three characteristics defines the spectrum of previous and present data representation methodologies. With regard to computer networks, the uniqueness of these methodologies presents an obstacle when disparate host environments are to be interconnected. Interoperability within a heterogeneous network relies upon the establishment of data representation commonality. The International Standards Organization (ISO) is currently developing the abstract syntax notation one standard (ASN.1) and the basic encoding rules standard (BER) that collectively address this problem. When used within the presentation layer of the open systems interconnection reference model, these two standards provide the data representation commonality required to facilitate interoperability. The details of a compiler that was built to automate the use of ASN.1 and BER are described. From this experience, insights into both standards are given and potential problems relating to this development effort are discussed.

Harvey, James D.↗
NASA NTRS2003

Standardization activity for the spacecraft onboard interfaces

The Consultative Committee for Space Data Systems (CCSDS) is an international organization of national space agencies that is organized to promote theinterchange of space related information. CCSDS is branching out to provide new standards to enhanced reuse of spacecraft equipment and software onboard of a spacecraft. This effort is know as Spacecraft Onboard Interface (SOIF). SOIF expects that these standards will be well used within the space community, and that they will be based on the well-known Internet protocols. This paper will provide a description of the SOIF work by reviewing this work with three orthogonal views. The Services View describes the data communications services that are provided to the users. The Interoperability view provides a description to users on how to use SOIF to interchange between different spacecraft data busses. And finally, the Protocol view, describes the protocols and services that are to be implemented in order to provide the users with the advantages of the SOIF architecture. This paper will give the reader an excellent introduction to the work of the international SOIF team.

Spacecraft interfaces standard interfaces CCSDS↗
NASA NTRS1993

Anthropometric data from launch and entry suited test subjects for the design of a recumbent seating system

Returning space crews to Earth in a recumbent position requires the design of a new seating system. Current anthropometric data are based on measurements taken while the subjects were unsuited and sitting. To be most accurate, it is necessary to design by measurements of subjects in the launch and entry suit in a recumbent position. Since the design of the recumbent seating system must meet the requirements of both 5th percentile Japanese female and 95th percentile American male crew members, a delta is reported rather than absolute measurements of the test subjects. This delta is the difference in the measurements taken with the subjects unsuited and sitting and those taken with the subjects suited and recumbent. This delta, representative of the change due to the suit, can be added to the existing Man-Systems Integration Standards (NASA-STD-3000) anthropometric data to project the measurements for 5th percentile Japanese female and 95th percentile American male crew members. A delta accounting for the spinal elongation caused by prolonged exposures to microgravity is added as well. Both unpressurized and pressurized suit conditions are considered. Background information, the test protocol and procedure, analysis of the data, and recommendations are reported.

Stoycos, Lara E.↗
NASA NTRS2013

The GLAS Standard Data Products Specification-Level 1, Version 9

The Geoscience Laser Altimeter System (GLAS) is the primary instrument for the ICESat (Ice, Cloud and Land Elevation Satellite) laser altimetry mission. ICESat was the benchmark Earth Observing System (EOS) mission for measuring ice sheet mass balance, cloud and aerosol heights, as well as land topography and vegetation characteristics. From 2003 to 2009, the ICESat mission provided multi-year elevation data needed to determine ice sheet mass balance as well as cloud property information, especially for stratospheric clouds common over polar areas. It also provided topography and vegetation data around the globe, in addition to the polar-specific coverage over the Greenland and Antarctic ice sheets.This document defines the Level-1 GLAS standard data products. This document addresses the data flow, interfaces, record and data formats associated with the GLAS Level 1 standard data products. GLAS Level 1 standard data products are composed of Level 1A and Level 1B data products. The term standard data products refers to those EOS instrument data that are routinely generated for public distribution. The National Snow and Ice Data Center (NSDIC) distribute these products. Each data product has a unique Product Identification code assigned by the Senior Project Scientist. GLAS Level 1A and Level 1B Data Products are composed from those Level 0 data that have been reformatted or transformed to corrected and calibrated data in physical units at the full instrument rate and resolution.

Lee, Jeffrey E.↗
NASA NTRS1993

Implementing the space shuttle data processing system with the space generic open avionics architecture

This paper presents an overview of the application of the Space Generic Open Avionics Architecture (SGOAA) to the Space Shuttle Data Processing System (DPS) architecture design. This application has been performed to validate the SGOAA, and its potential use in flight critical systems. The paper summarizes key elements of the Space Shuttle avionics architecture, data processing system requirements and software architecture as currently implemented. It then summarizes the SGOAA architecture and describes a tailoring of the SGOAA to the Space Shuttle. The SGOAA consists of a generic system architecture for the entities in spacecraft avionics, a generic processing external and internal hardware architecture, a six class model of interfaces and functional subsystem architectures for data services and operations control capabilities. It has been proposed as an avionics architecture standard with the National Aeronautics and Space Administration (NASA), through its Strategic Avionics Technology Working Group, and is being considered by the Society of Aeronautic Engineers (SAE) as an SAE Avionics Standard. This architecture was developed for the Flight Data Systems Division of JSC by the Lockheed Engineering and Sciences Company, Houston, Texas.

Wray, Richard B.↗
NASA NTRSDate not supplied

The Use of Atmospheric Composition Variable Standard Names in Airborne and Field Data Products

The number of variables measured during airborne field campaigns has increased more than tenfold over the last thirty years. With this increase in measurements, the complexity for distributed active archive centers (DAACs) to distribute the data and for data users to search for and find measurements of interest has also increased. Part of this complexity arises from the unique variable names in suborbital atmospheric composition field studies. With limited guidelines related to variable naming, variable names and structures can vary significantly, even for the same type of variable. It is common for instrument scientists to use their intended measurable quantity as the data variable name. This can make it difficult for users to locate and interact with a particular variable across multiple data sets. One effective solution to this problem, identified by the Earth Science Data System (ESDS) ICARTT Refresh Working Group [1], was to introduce variable standard names that can be used as tags for each data variable. This allows similar measurements (e.g., dew point) to be categorized and located across field campaigns, regardless of what variable name the instrument scientist has used. From this the atmospheric composition variable standard names were developed with the goal to use Findable, Accessible, Interoperable, and Reusable (FAIR) principles [2] and provide context for all users, while remaining connected to those in the subject area. These standard names have been successfully implemented in FIREX-AQ, CAMP 2EX, ACTIVATE, and DCOTSS field campaigns.

metadata↗
NASA NTRS1982

LANDSAT-D data format control book. Volume 6, appendix A: Partially processed thematic mapper High Density Tape (HDT-AT)

One of the outputs of the data management system being developed to provide a variety of standard image products from the thematic mapper and the multispectral band scanners on LANDSAT 4, is the partially processed TM data (radiometric corrections applied and geometric correction matrices for two projections appended) which is recorded on a 28-track high density tape. Specifications are presented for the format of the recorded data as well as for the time code and the major and minor frames of the tape. Major frame types, formats, and field definitions are included.

Jai, A.↗
NASA NTRS2011

Asynchronous Message Service Reference Implementation

This software provides a library of middleware functions with a simple application programming interface, enabling implementation of distributed applications in conformance with the CCSDS AMS (Consultative Committee for Space Data Systems Asynchronous Message Service) specification. The AMS service, and its protocols, implement an architectural concept under which the modules of mission systems may be designed as if they were to operate in isolation, each one producing and consuming mission information without explicit awareness of which other modules are currently operating. Communication relationships among such modules are self-configuring; this tends to minimize complexity in the development and operations of modular data systems. A system built on this model is a society of generally autonomous, inter-operating modules that may fluctuate freely over time in response to changing mission objectives, modules functional upgrades, and recovery from individual module failure. The purpose of AMS, then, is to reduce mission cost and risk by providing standard, reusable infrastructure for the exchange of information among data system modules in a manner that is simple to use, highly automated, flexible, robust, scalable, and efficient. The implementation is designed to spawn multiple threads of AMS functionality under the control of an AMS application program. These threads enable all members of an AMS-based, distributed application to discover one another in real time, subscribe to messages on specific topics, and to publish messages on specific topics. The query/reply (client/server) communication model is also supported. Message exchange is optionally subject to encryption (to support confidentiality) and authorization. Fault tolerance measures in the discovery protocol minimize the likelihood of overall application failure due to any single operational error anywhere in the system. The multi-threaded design simplifies processing while enabling application nodes to operate at high speeds; linked lists protected by mutex semaphores and condition variables are used for efficient, inter-thread communication. Applications may use a variety of transport protocols underlying AMS itself, including TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and message queues.

Burleigh, Scott C.↗
NASA NTRS1984

Future interactive data systems

The information and control requirements of the investigator-users of future free-flying, platform-based, or Space Station-based scientific experiments are assessed, and the implications of these requirements for the design of the information systems are discussed. The principal requirements include near-real-time interaction with the payload, distributed or remote payload command and control, rapid access to quick-look data, flexibility of payload command sequences, on-demand uplink-downlink availability, system transparency, and modular design to facilitate replacement of system components. Current developments in systems architecture such as increased use of onboard microprocessors to select and preprocess data and transmit autonomous streams directly to the user, standardization of interfaces, and the NASA Tracking and Data Relay Satellite System are characterized, and block diagrams of present and future systems are provided.

Bracken, P. A.↗
NASA NTRS1989

Materials properties numerical database system established and operational at CINDAS/Purdue University

A computerized comprehensive numerical database system on the mechanical, thermophysical, electronic, electrical, magnetic, optical, and other properties of various types of technologically important materials such as metals, alloys, composites, dielectrics, polymers, and ceramics has been established and operational at the Center for Information and Numerical Data Analysis and Synthesis (CINDAS) of Purdue University. This is an on-line, interactive, menu-driven, user-friendly database system. Users can easily search, retrieve, and manipulate the data from the database system without learning special query language, special commands, standardized names of materials, properties, variables, etc. It enables both the direct mode of search/retrieval of data for specified materials, properties, independent variables, etc., and the inverted mode of search/retrieval of candidate materials that meet a set of specified requirements (which is the computer-aided materials selection). It enables also tabular and graphical displays and on-line data manipulations such as units conversion, variables transformation, statistical analysis, etc., of the retrieved data. The development, content, accessibility, etc., of the database system are presented and discussed.

Ho, C. Y.↗
NASA NTRS1992

X ray observations of late-type stars using the ROSAT all-sky survey

The ROSAT mission made the first x ray survey of the entire sky using an imaging detector. Although ROSAT is a joint NASA/German project and involves direct American participation during its second phase of pointed observations, the all-sky survey remains the sole property of the German investigators. NASA grant represented the first use of ROSAT data analysis funds to support direct American participation in the ROSAT all-sky survey. The project involved a collaborative agreement between the Joint Institute for Laboratory Astrophysics (JILA) and the Max-Planck-Institut fur Extraterrestrische Physik (MPE) where JILA supplied MPE with a post-doctoral research associate with experience in the field of stellar (coronal) x ray emission to work within their ROSAT group. In return, members of the cool star research group at JILA were given the opportunity to collaborate on projects involving ROSAT all-sky survey data. Both sides have benefitted (and still benefit) from this arrangement since MPE suffers from a shortage of researchers who are interested in x ray emission from 'normal' stars and white dwarfs. MPE has also drawn upon experience in optical identification of x ray sources from the Einstein Extended Medium Sensitivity Survey in planning their own identification strategies for the ROSAT all-sky survey. The JILA cool stars group has benefitted since access to all-sky survey data has expanded the scope of their already extensive research programs involving multiwavelength observations of late-type stars. ROSAT was successfully launched on 1 June 1990 and conducted the bulk of the survey from 30 July 1990 to 25 January 1991. Data gaps in the survey have subsequently been made up. At the time of this writing (February 1992), the survey data have been processed once with the Standard Analysis Software System (SASS). A second processing will soon begin with improvements made to the SASS to correct errors and bugs found while carrying out scientific projects with data from the first processing. We outline the major research activities of Dr. Fleming over the past year (detailed accounts of his activities during the first two years of this grant can be found in the first-year and second-year status reports on this grant). Regarding the three specific projects which were proposed in the original proposal, two of them (White Dwarfs and Late M Dwarfs) are near completion. The results are described in two conference proceedings which are appended.

Linsky, Jeffrey L.↗
NASA NTRS2014

Scalable Asset Discovery, Vulnerability Scanning, and Penetration Testing for Remote Sites and Wireless Spectrums Utilizing an Embedded Linux Plug - PwniPlug and the Raspberry Pi B+ as a Sample Pen Test

All devices attached to the NASA KSC network are subject to security vulnerability scanning and/or penetration testing. In today's changing environment, vulnerable and/or unprotected systems can easily be overlooked. Systems that are not properly managed can become a potential threat to the operational integrity of our systems and networks. This includes all NASA (internal and external) information systems within NASA KSC Internet Protocol (IP) address space, and NASA KSC facilities. The Office of the Chief Information Officer (OCIO) recommends that all NASA Centers and information systems be subject to penetration testing on a regular interval in accordance with the guidelines identified by the National Institute of Standards and Technology (NIST). (ITS-HBK-2810.04-02A) Protecting information and equipment at NASA is an area of increasing concern. In addition to the CPU's on the network; Supervisory, Control and Data Acquisition (SCADA) systems are especially vulnerable because these systems have lacked standards, use embedded controllers with little computational power and informal software, are connected to physical processes, have few operators, and are increasingly also being connected to corporate networks. The scope of work is comprised of several individual components which together build upon previous work by Drew Branch, NASA KSC Intern. The Pwn Plug is the selected COTS (Commercial-Off-The-Shelf) device chosen to test simplification of mandatory IT Security tasks. The device will be utilized to provide services to NASA KSC and enable an assessment of infrastructure soundness and regulatory compliance in an efficient, economical, and business responsive manner. The Pwn Plug is designed as a pen testing appliance which provides a hardware platform that can support commercial penetration testing efforts at significantly reduced costs. The expected outcomes are: 1) External Penetration Testing, 2) Social Engineering, 3) Procedural Documentation, 4) Recommended Remediation Action Plan, 5) System Retest & Remediation Attestation and 6) Final Reports, out briefing and Presentation. Due to physical and material constraints beyond intern and mentor control, the project was redefined as a working pen-test scenario. Limitations of lab availability and tools dictated an academic exercise. This report was developed within the scenario guidelines suggested by the project mentor. The guidelines were to be creative in developing a Pen Test program for a client.

Penetration Testing↗
NASA NTRS1980

Spacelab's interface to payload experiments

The Spacelab Payload Standard Modular Electronics (SPSME) program has been designed to provide a standardized set of space-qualified low-power electronic modules from which an experimenter may economically implement a command and data management system. SPSME is based on the Computer Automated Measurement and Control (CAMAC) interface standards. To the system of CAMAC, SPSME adds Spacelab interface modules, a flight qualified system crate, and an efficient light-weight power supply to produce a system compatible with the Spacelab environments, the Spacelab Command and Data Management System interface, and any experiment.

Golemon, W. F.↗
NASA NTRS2006

Applying Registry Services to Spaceflight Technologies to Aid in the Assignment of Assigned Numbers to Disparate Systems and their Technologies to Further Enable Interoperability

To date very little effort has been made to provide interoperability between various space agency projects. To effectively get to the Moon and beyond systems must interoperate. To provide interoperability, standardization and registries of various technologies will be required. These registries will be created as they relate to space flight. With the new NASA Moon/Mars initiative, a requirement to standardize and control the naming conventions of very disparate systems and technologies is emerging. The need to provide numbering to the many processes, schemas, vehicles, robots, space suits and technologies (e.g. versions), to name a few, in the highly complex Constellation initiative is imperative. The number of corporations, developer personnel, system interfaces, people interfaces will require standardization and registries on a scale not currently envisioned. It would only take one exception (stove piped system development) to weaken, if not, destroy interoperability. To start, a standardized registry process must be defined that allows many differing engineers, organizations and operators the ability to easily access disparate registry information across numerous technological and scientific disciplines. Once registries are standardized the need to provide registry support in terms of setup and operations, resolution of conflicts between registries and other issues will need to be addressed. Registries should not be confused with repositories. No end user data is "stored" in a registry nor is it a configuration control system. Once a registry standard is created and approved, the technologies that should be registered must be identified and prioritized. In this paper, we will identify and define a registry process that is compatible with the Constellation initiative and other non related space activities and organizations. We will then identify and define the various technologies that should use a registry to provide interoperability. The first set of technologies will be those that are currently in need of expansion namely the assignment of satellite designations and the process which controls assignments. Second, we will analyze the technologies currently standardized under the Consultative Committee for Space Data Systems (CCSDS) banner. Third, we will analyze the current CCSDS working group and Birds of a Feather (BoF) activities to ascertain registry requirements. Lastly, we will identify technologies that are either currently under the auspices of another standards body or technologies that are currently not standardized. For activities one through three, we will provide the analysis by either discipline or technology with rationale, identification and brief description of requirements and precedence. For activity four, we will provide a list of current standards bodies e.g. IETF and a list of potential candidates.

Bradford, Robert N.↗
NASA NTRS1971

Data sampling system for monitor and control station

System design is based on development of standardized, interchangeable modules that minimize power dissipation, interconnecting cables and size. Maximum flexibility is achieved by using building block approach where all data modules are identical and are connected at any remote location and addressed in random fashion from central unit.

Source record↗
NASA NTRS1991

Calibration of NASA/JPL DC-8 SAR data

The paper describes a number of improvements in calibration of NASA/JPL DC-8 SAR (synthetic aperture radar) data, intended to make calibrated data from the system available to the majority of the investigators. The improvements include a move to a better site for calibration of the system at the start of each campaign season, the release of software to allow users to calibrate their data, the supply of trihedral corner reflectors and instructions on how to deploy them, and the setting up of an archive of calibrated data. Analysis of the calibration performance of the DC-8 SAR over a number of sites during 1990 suggests that the system is sufficiently stable to allow calibration of the standard data products without the presence of calibration devices within the scene. The limiting factor on DC-8 SAR data calibration would now appear to be the knowledge of the altitude of the aircraft, which determines the relationship between the measured slant range coordinates and the antenna pattern in elevation.

Freeman, A.↗
NASA NTRS1992

An open, parallel I/O computer as the platform for high-performance, high-capacity mass storage systems

APTEC Computer Systems is a Portland, Oregon based manufacturer of I/O computers. APTEC's work in the context of high density storage media is on programs requiring real-time data capture with low latency processing and storage requirements. An example of APTEC's work in this area is the Loral/Space Telescope-Data Archival and Distribution System. This is an existing Loral AeroSys designed system, which utilizes an APTEC I/O computer. The key attributes of a system architecture that is suitable for this environment are as follows: (1) data acquisition alternatives; (2) a wide range of supported mass storage devices; (3) data processing options; (4) data availability through standard network connections; and (5) an overall system architecture (hardware and software designed for high bandwidth and low latency). APTEC's approach is outlined in this document.

Abineri, Adrian↗
NASA NTRS2018

A Standard Reference Model for Data Archives

An implementable Data Archive Architecture is being developed for trusted digital repositories based on the Reference Model for an Open Archival Information System (OAIS) – ISO 14721. A set of interoperable protocols and interface specifications are planned that will offer capabilities for accessing, merging, and re-using data, both within and across the operational boundaries of trustworthy digital repositories. The model will also provide support for the fundamental scientific need to verify the reproducibility of results. This standards development task is being performed by the Data Archive Interoperability (DAI) working group within the Consultative Committee for Space Data Systems (CCSDS). The architecture integrates concepts from the OAIS Reference Model, the ISO/IEC 11179 Metadata Registry (MDR) standard, the CCSDS Reference Architecture for Space Information Management (RASIM), the proposed draft recommended practice document, Information Preparation to Enable Long Term Use (IPELTU), and three decades of digital repository development for science research.

Ambacher, Bruce↗