Search NASA⌕ Search

SEARCH · Search NASA

Results for “Hardware/Software interfaces”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS1995

Multi-modal virtual environment research at Armstrong Laboratory

One mission of the Paul M. Fitts Human Engineering Division of Armstrong Laboratory is to improve the user interface for complex systems through user-centered exploratory development and research activities. In support of this goal, many current projects attempt to advance and exploit user-interface concepts made possible by virtual reality (VR) technologies. Virtual environments may be used as a general purpose interface medium, an alternative display/control method, a data visualization and analysis tool, or a graphically based performance assessment tool. An overview is given of research projects within the division on prototype interface hardware/software development, integrated interface concept development, interface design and evaluation tool development, and user and mission performance evaluation tool development.

Eggleston, Robert G.↗
NASA NTRS1976

General Purpose Computer (GPC) to GPC systems interface description

The General Purpose Computer (GPC) 'subsystem' of the Orbiter Data Processing System was described. Two interface areas are discussed. One is the area of GPC intraconnections and intracommunications involving the hardware/software interface between the Central Processing Unit (CPU) and the Input/Output Processor (IOP). The other is the area of GPC interconnections and intercommunications and involves the hardware/software interface between the five Orbiter GPC's. Based on the detailed GPC interface given, it is felt that the basic CPU to IOP interface and the GPC to GPC interface have the potential for trouble free operation. However, due to the complexity of the interface and the criticality of GPC synchronization to overall avionics performance, the GPC to GPC interface should be carefully evaluated when attempting to resolve test anomalies that may involve GPC timing and synchronization errors.

Breyer, B. C.↗
NASA NTRS1976

An interface between a datametrics 1085A manometer and a Hewlett-Packard 2100S computer

A hardware/software interface designed to mate a Datametrics models 1085A electronic manometer to a Hewlett-Packard (HP) model 2100S computer is described. The software driver operates in the basic control system (BCS) and requires 173 words of memory; the hardware interface uses an HP data source interface (DSI) card which requires one computer input/output channel. Results obtained by incorporating this interface into a data acquisition system indicate that the interface operates successfully.

Hillard, M. E., Jr.↗
NASA NTRS1976

Implementation of an experimental fault-tolerant memory system

The experimental fault-tolerant memory system described in this paper has been designed to enable the modular addition of spares, to validate the theoretical fault-secure and self-testing properties of the translator/corrector, to provide a basis for experiments using the new testing and correction processes for recovery, and to determine the practicality of such systems. The hardware design and implementation are described, together with methods of fault insertion. The hardware/software interface, including a restricted single error correction/double error detection (SEC/DED) code, is specified. Procedures are carefully described which, (1) test for specified physical faults, (2) ensure that single error corrections are not miscorrections due to triple faults, and (3) enable recovery from double errors.

Carter, W. C.↗
NASA NTRS1979

Wind tunnel real-time data acquisition system

The hardware configuration is described for the data acquisition system (DAS) which consists of an analog front end that can process up to 260 channels of data, a multichannel analog-to-digital subsystem that can process up to 50,000 samples of data per second, and a digital computer with standard and nonstandard devices, including graphics capability. Also described are the software configuration of the DAS and complex hardware/software interfaces providing, for example, automatic amplifier gain and offset adjustment for each data channel. Specific DAS applications are summarized, including the real time processing of dynamic deflection data, unsteady pressure measurements, and flutter and buffet data.

Cole, P.↗
NASA NTRS1979

Real-time data acquisition system for the NASA Langley transonic dynamics tunnel

The hardware configuration of the Transonic Dynamics Wind Tunnel Data Acquisition System (DAS) which consists of an analog front end that can process up to 260 channels of data is presented. The DAS also has a multi-channel analog-to-digital subsystem that can process up to 50,000 samples of data per sec, and a digital computer with standard and nonstandard devices, with graphics capability. The software configuration of the DAS and complex hardware/software interfaces are described, which can provide automatic amplifier gain and offset adjustment for each data channel. Finally, a summary of specific DAS applications is given including the real-time processing of dynamic deflection data, unsteady pressure measurements, and flutter and buffet data.

Cole, P. H.↗
NASA NTRS1981

A new method for hardware/software integration of strategic systems - Case study of the Space Shuttle

An advanced system integrated self-test has been developed to provide dynamic checkout of all critical subsystems and hardware/software interfaces of the Space Shuttle during pre-launch ground testing. The system modifies hardware sensor data to represent a real flight scenario. This modified data then drives the flight software. The system was sucessfully utilized for three phases of Space Shuttle testing, and will be expanded for use as a maintenance tool.

Haque, S. I.↗
NASA NTRS1984

Systems engineering - Space Telescope project

At midpoint in the development of the Space Telescope (ST), a review process was conducted which determined that much benefit could be derived from an expanded systems engineering effort. The Systems Engineering Office thus established is responsible for the running of a management information system whose functions encompass design change control and the implementation of a maintenance and refurbishment program. By these means, interface hardware/software incompatibilities between critical ST modules and subsystems have been revealed and corrected.

Wojtalik, F. S.↗
NASA NTRS1985

Effect of system workload on operating system reliability - A study on IBM 3081

This paper presents an analysis of operating system failures on an IBM 3081 running VM/SP. Three broad categories of software failures are found: error handling, program control or logic, and hardware related; it is found that more than 25 percent of software failures occur in the hardware/software interface. Measurements show that results on software reliability cannot be considered representative unless the system workload is taken into account. The overall CPU execution rate, although measured to be close to 100 percent most of the time, is not found to correlate strongly with the occurrence of failures. Possible reasons for the observed workload failure dependency, based on detailed investigations of the failure data, are discussed.

Iyer, R. K.↗
NASA NTRS1993

Case Study: Formal Inspections at the Jet Propulsion Laboratory

The Jet Propulsion Laboratory (JPL) of the California Institute of Technology is a federally funded research and development center operating under contract to the National Aeronautics and Space Administration (NASA). JPL's charter emphasizes the exploration of the solar system including observations of Earth as well as other stellar systems and extra-solar-system bodies. Within JPL, the Software Product Assurance (SPA) Section helps to ensure the operational integrity of the software within the system. SPA evaluates the operational requirements, the acceptability and readiness of all software, hardware/software interfaces, and the integrity of the completed software before its final release into the operational environment.

Kelly, J. C.↗
NASA NTRS1984

NASA's satellite relay tracking and data acquisition program

The Tracking and Data Acquisition System (TDAS) is currently being planned to support NASA missions and the Space Station and will serve as a replacement to the present Tracking and Data Relay Satellite System (TDRSS). Its operational date is currently projected for the late 1990s. Near term objectives involve the definition of a TDAS architecture, the development of functional and performance specifications and implementation of a TDRSS-to-TDAS transition plan. The present paper provides an overview of the baseline TDAS architecture and summarizes key ingredients of system and technology studies in progress. In particular, this paper addresses a summary of projected mission requirements for the TDAS era; a characterization of the space segment constellation; use of lasers, 60 GHz, and multibeam 30/20 GHz technologies; ground architecture and operational interfaces; a distributed hardware/software processing concept for more flexible and reliable interfaces, signal processing and operations. Also included is a status summary of the TDAS program plan for the 1984-1990 time frame. Finally, an overview is presented of NASA's current plans to augment the TDRSS to meet the Space Station IOC requirements in the time period 1993-2000.

Schwartz, J. J.↗
NASA NTRS1993

Space Generic Open Avionics Architecture (SGOAA) reference model technical guide

This report presents a full description of the Space Generic Open Avionics Architecture (SGOAA). The SGOAA consists of a generic system architecture for the entities in spacecraft avionics, a generic processing architecture, and a six class model of interfaces in a hardware/software system. The purpose of the SGOAA is to provide an umbrella set of requirements for applying the generic architecture interface model to the design of specific avionics hardware/software systems. The SGOAA defines a generic set of system interface points to facilitate identification of critical interfaces and establishes the requirements for applying appropriate low level detailed implementation standards to those interface points. The generic core avionics system and processing architecture models provided herein are robustly tailorable to specific system applications and provide a platform upon which the interface model is to be applied.

Wray, Richard B.↗
NASA NTRS1981

AVE-SESAME program for the REEDA System

The REEDA system software was modified and improved to process the AVE-SESAME severe storm data. A random access file system for the AVE storm data was designed, tested, and implemented. The AVE/SESAME software was modified to incorporate the random access file input and to interface with new graphics hardware/software now available on the REEDA system. Software was developed to graphically display the AVE/SESAME data in the convention normally used by severe storm researchers. Software was converted to AVE/SESAME software systems and interfaced with existing graphics hardware/software available on the REEDA System. Software documentation was provided for existing AVE/SESAME programs underlining functional flow charts and interacting questions. All AVE/SESAME data sets in random access format was processed to allow developed software to access the entire AVE/SESAME data base. The existing software was modified to allow for processing of different AVE/SESAME data set types including satellite surface and radar data.

Hickey, J. S.↗
NASA NTRS1984

A simulator application of a 'hands-on throttle and stick' concept to a transport pilot/autopilot interface

This paper presents the initial experiences garnered in applying a multifunction control strategy, based on the U.S. Air Force's 'Hands-On Throttle-and-Stick' concept for fighter aircraft to a transport aircraft simulator. The multifunction control strategy involves the activation of various flight system/subsystem operations (such as guidance and control, communication, and navigation functions) by use of menu displays and throttle and stick switches. The initial application of this multifunction control (MFC) concept was developed around a pilot/autopilot interface, contrasting a conventional, dedicated autopilot interface to an MFC implementation. The simulator characteristics and autopilot functions, as well as the conventional interface and MFC hardware/software, which were utilized in the application, are described herein. Initial pilot reaction and suggested improvements to this particular implementation are discussed. The paper terminates with a glance at plans for improvements and future applications based on the outcome of this initial study.

Busquets, A. M.↗
NASA NTRS1993

GE networked mass storage solutions supporting IEEE network mass storage model

The General Electric Government Communications Systems Department (GE/GCSD) has developed a near real time digital data storage and retrieval system that extends the capabilities currently available in today's marketplace. This system called DuraStore uses commercially available rotary tape drive technology with ANSI/IEEE standards for automated magnetic tape based data storage. It uses a nonproprietary approach to satisfy a wide range of data rates and storage capabilities requirements and is compliant with the IEEE Network Storage Model. Rotary tape drives, standard interfaces, application specific hardware/software, networked automated tape libraries, library administrator, write protection, volume/physical media linkages, and maximum resource utilization are addressed.

Herzog, Donald↗
NASA NTRS1976

TDRSS operations control analysis study

The use of an operational Tracking and Data Relay Satellite System (TDRSS) and the remaining ground stations for the STDN (GSTDN) was investigated. The operational aspects of TDRSS concepts, GSTDN as a 14-site network, and GSTDN as a 7 site-network were compared and operations control concepts for the configurations developed. Man/machine interface, scheduling system, and hardware/software tradeoff analyses were among the factors considered in the analysis.

Source record↗
NASA NTRS1976

Space shuttle engineering and operations support. Avionics system engineering

The shuttle avionics integration laboratory (SAIL) requirements for supporting the Spacelab/orbiter avionics verification process are defined. The principal topics are a Spacelab avionics hardware assessment, test operations center/electronic systems test laboratory (TOC/ESL) data processing requirements definition, SAIL (Building 16) payload accommodations study, and projected funding and test scheduling. Because of the complex nature of the Spacelab/orbiter computer systems, the PCM data link, and the high rate digital data system hardware/software relationships, early avionics interface verification is required. The SAIL is a prime candidate test location to accomplish this early avionics verification.

Broome, P. A.↗