Engineering Papers⌕ Search

SEARCH · Engineering Papers

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 37 records · Page 2

Microcomputer programming skills

Some differences in skill and techniques required for conversion from programmer to microprogrammer are discussed. The primary things with which the programmer should work are hardware architecture, hardware/software trade off, and interfacing. The biggest differences, however, will stem from the differences in applications than from differences in machine size. The change to real-time programming is the most important of these differences, particularly on dedicated microprocessors. Another primary change is programming with a more computer-naive user in mind, and dealing with his limitations and expectations.

Barth, C. W.↗

Tethered satellite system

The Tethered Satellite System (TSS) will operate from the Space Shuttle as an earth-orbiting facility that will permit tethered deployment of numerous types of payloads to altitudes both above and below that of the Shuttle. The TSS has evolved from initial studies, beginning in the sixties, to a cooperative development program that is currently being carried out by NASA and the National Space Plan of Italy's CNR. This cooperative agreement between NASA and CNR includes system development and science instrumentation for the first mission, and planning for two additional missions. This paper will (1) discuss predevelopment activities, (2) review the development approach and management relationships between NASA and CNR, (3) describe the current hardware/software configuration and functional interfaces, (4) discuss the mission profile and flight operations planning, and (5) overview science experiment status/plans for the first TSS mission.

Laue, Jay H.↗

Space Generic Open Avionics Architecture (SGOAA) standard specification

The purpose of this standard is to provide an umbrella set of requirements for applying the generic architecture interface model to the design of a specific avionics hardware/software system. This standard 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.↗

mREST Interface Specification

mREST is an implementation of the REST architecture specific to the management and sharing of data in a system of logical elements. The purpose of this document is to clearly define the mREST interface protocol. The interface protocol covers all of the interaction between mREST clients and mREST servers. System-level requirements are not specifically addressed. In an mREST system, there are typically some backend interfaces between a Logical System Element (LSE) and the associated hardware/software system. For example, a network camera LSE would have a backend interface to the camera itself. These interfaces are specific to each type of LSE and are not covered in this document. There are also frontend interfaces that may exist in certain mREST manager applications. For example, an electronic procedure execution application may have a specialized interface for configuring the procedures. This interface would be application specific and outside of this document scope. mREST is intended to be a generic protocol which can be used in a wide variety of applications. A few scenarios are discussed to provide additional clarity but, in general, application-specific implementations of mREST are not specifically addressed. In short, this document is intended to provide all of the information necessary for an application developer to create mREST interface agents. This includes both mREST clients (mREST manager applications) and mREST servers (logical system elements, or LSEs).

McCartney, Patrick↗

Alternating Between Software Models and Real Hardware in the System Integration Lab for theIncremental Development of the Space Launch System Program Avionics

The MSFC System Integration Lab (SIL) supports avionics development of NASA’s Space Launch System—a new U.S. heavy-lift launch vehicle for NASA’s next generation of human space exploration beyond low-Earth orbit. The SIL facility allows for the incremental development of system components by either hosting real hardware in the loop and/or software models of those components. Through this functionality test teams are able to evaluate overall system performance as components are designed, built and modified. Early hardware/software integration and testing reduces risks and saves overall cost and schedule throughout a program/project life cycle. By performing early hardware/software integration, potential architecture and interface-related problems can be identified, and thus reduce associated risk as early in the design cycle as possible when problems are the least expensive to resolve while also improving the design and requirements. This presentation will illustrate the power of employing a hardware in the loop simulation system for the development of novel spacecraft avionics.

Space Launch System↗

PPOD Programmable pilot-oriented display

A general-purpose low cost research microprocessor system for general aviation was developed. This system is intended to be the vehicle for individual research efforts in low cost airborne hardware and software as well as advanced microprocessor based navigation systems and techniques. Two such research projects were undertaken, yielding results in the areas of micro hardware/software design, cost and performance, and pilot/computer interface. Low-cost flight software reliability and a time-difference based Loran approach procedure that eliminates the need for propagation corrections and latitude/longitude transformations are also discussed.

Elias, A. L.↗

Integrating Human Factors into Crew Exploration Vehicle Design

With NASA's new Vision for Exploration to send humans beyond Earth orbit, it is critical to consider the human as a system that demands early and continuous user involvement, and an iterative prototype/test/redesign process. Addressing human-system interface issues early on can be very cost effective even cost reducing when performed early in the design and development cycle. To achieve this goal within Crew Exploration Vehicle (CEV) Project Office, human engineering (HE) team is formed. Key tasks are to apply HE requirements and guidelines to hardware/software, and provide HE design, analysis and evaluation of crew interfaces. Initial activities included many practice-orientated evaluations using low-fidelity CEV mock-ups. What follows is a description of such evaluations that focused on a HE requirement regarding Net Habitable Volume (NHV). NHV is defined as the total remaining pressurized volume available to on-orbit crew after accounting for the loss of volume due to deployed hardware and structural inefficiencies which decrease functional volume. The goal of the NHV evaluations was to develop requirements providing sufficient CEV NHV for crewmembers to live and perform tasks in support of mission goals. Efforts included development of a standard NHV calculation method using computer models and physical mockups, and crew/ stakeholder evaluations. Nine stakeholders and ten crewmembers participated in the unsuited evaluations. Six crewmembers also participated in a suited evaluation. The mock-up was outfitted with volumetric representation of sub-systems such as seats, and stowage bags. Thirteen scenarios were developed to represent mission/crew tasks and considered to be primary volume drivers (e.g., suit donning) for the CEV. Unsuited evaluations included a structured walkthrough of these tasks. Suited evaluations included timed donning of the existing launch and entry suit to simulate a contingency scenario followed by doffing/ stowing of the suits. All mockup evaluations were videotaped. Structured questionnaires were used to document user interface issues and volume impacts of layout configuration. Computer model and physical measures of the NHV agreed within 1 percent. This included measurement of the gross habitable volume, subtraction of intrusive volumes, and other non-habitable spaces. Calculation method developed was validated as a standard means of measuring NHV, and was recommended as a verification method for the NHV requirements. Evaluations confirmed that there was adequate volume for unsuited scenarios and suit donning/ doffing activity. Seats, suit design stowage and waste hygiene system noted to be critical volume drivers. The low-fidelity mock-up evaluations along with human modeling analysis generated discussions that will lead to high-level systems requirements and human-centered design decisions. This approach allowed HE requirements and operational concepts to evolve in parallel with engineering system concepts and design requirements. As the CEV design matures, these evaluations will continue and help with design decisions, and assessment, verification and validation of HE requirements.

Whitmore, Mihriban↗

A method of testing attitude control systems during the development phase

A technique, utilized on the Space Telescope Program, and used for testing satellite attitude pointing and control systems during the engineering and development phases is presented. The technique verifies the hardware models used in design phase computer simulations, verifies the interface between the flight hardware and flight software, and uncovers hardware/software switching or mode logic problems. The testing is accomplished in two phases: a dynamic hardware simulator phase using hardware electronic simulators and an electronic vehicle motion simulator; and a second real hardware phase utilizing engineering model gyros and reaction wheels on an airbearing table. Both phases use an engineering model of the flight computer, flight algorithms and software, and a breadboard data management and computer hardware interface for timing simulations. The purpose of each test and the test phases are described, and examples of closed loop test results for both attitude hold and maneuvering models are given.

Besonis, A.↗

Space Generic Open Avionics Architecture (SGOAA) standard specification

This standard establishes the Space Generic Open Avionics Architecture (SGOAA). The SGOAA includes a generic functional model, processing structural model, and an architecture interface model. This standard defines the requirements for applying these models to the development of spacecraft core avionics systems. The purpose of this standard is to provide an umbrella set of requirements for applying the generic architecture models to the design of a specific avionics hardware/software processing system. This standard defines a generic set of system interface points to facilitate identification of critical services and interfaces. It establishes the requirement for applying appropriate low level detailed implementation standards to those interfaces points. The generic core avionics functions and processing structural 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.↗

Orbiter subsystem hardware/software interaction analysis. Volume 8: AFT reaction control system, part 2

The orbiter subsystems and interfacing program elements which interact with the orbiter computer flight software are analyzed. The failure modes identified in the subsystem/element failure mode and effects analysis are examined. Potential interaction with the software is examined through an evaluation of the software requirements. The analysis is restricted to flight software requirements and excludes utility/checkout software. The results of the hardware/software interaction analysis for the forward reaction control system are presented.

Becker, D. D.↗

Integration and use of Microgravity Research Facility: Lessons learned by the crystals by vapor transport experiment and Space Experiments Facility programs

The Crystals by Vapor Transport Experiment (CVTE) and Space Experiments Facility (SEF) are materials processing facilities designed and built for use on the Space Shuttle mid deck. The CVTE was built as a commercial facility owned by the Boeing Company. The SEF was built under contract to the UAH Center for Commercial Development of Space (CCDS). Both facilities include up to three furnaces capable of reaching 850 C minimum, stand-alone electronics and software, and independent cooling control. In addition, the CVTE includes a dedicated stowage locker for cameras, a laptop computer, and other ancillary equipment. Both systems are designed to fly in a Middeck Accommodations Rack (MAR), though the SEF is currently being integrated into a Spacehab rack. The CVTE hardware includes two transparent furnaces capable of achieving temperatures in the 850 to 870 C range. The transparent feature allows scientists/astronauts to directly observe and affect crystal growth both on the ground and in space. Cameras mounted to the rack provide photodocumentation of the crystal growth. The basic design of the furnace allows for modification to accommodate techniques other than vapor crystal growth. Early in the CVTE program, the decision was made to assign a principal scientist to develop the experiment plan, affect the hardware/software design, run the ground and flight research effort, and interface with the scientific community. The principal scientist is responsible to the program manager and is a critical member of the engineering development team. As a result of this decision, the hardware/experiment requirements were established in such a way as to balance the engineering and science demands on the equipment. Program schedules for hardware development, experiment definition and material selection, flight operations development and crew training, both ground support and astronauts, were all planned and carried out with the understanding that the success of the program science was as important as the hardware functionality. How the CVTE payload was designed and what it is capable of, the philosophy of including the scientists in design and operations decisions, and the lessons learned during the integration process are descussed.

Heizer, Barbara L.↗

Integrating Human Factors into Crew Exploration Vehicle (CEV) Design

The purpose of this design process is to apply Human Engineering (HE) requirements and guidelines to hardware/software and to provide HE design, analysis and evaluation of crew interfaces. The topics include: 1) Background/Purpose; 2) HE Activities; 3) CASE STUDY: Net Habitable Volume (NHV) Study; 4) CASE STUDY: Human Modeling Approach; 5) CASE STUDY: Human Modeling Results; 6) CASE STUDY: Human Modeling Conclusions; 7) CASE STUDY: Human-in-the-Loop Evaluation Approach; 8) CASE STUDY: Unsuited Evaluation Results; 9) CASE STUDY: Suited Evaluation Results; 10) CASE STUDY: Human-in-the-Loop Evaluation Conclusions; 11) Near-Term Plan; and 12) In Conclusion

Mihriban Whitmore↗

Intelligent systems technology infrastructure for integrated systems

A system infrastructure must be properly designed and integrated from the conceptual development phase to accommodate evolutionary intelligent technologies. Several technology development activities were identified that may have application to rendezvous and capture systems. Optical correlators in conjunction with fuzzy logic control might be used for the identification, tracking, and capture of either cooperative or non-cooperative targets without the intensive computational requirements associated with vision processing. A hybrid digital/analog system was developed and tested with a robotic arm. An aircraft refueling application demonstration is planned within two years. Initially this demonstration will be ground based with a follow-on air based demonstration. System dependability measurement and modeling techniques are being developed for fault management applications. This involves usage of incremental solution/evaluation techniques and modularized systems to facilitate reuse and to take advantage of natural partitions in system models. Though not yet commercially available and currently subject to accuracy limitations, technology is being developed to perform optical matrix operations to enhance computational speed. Optical terrain recognition using camera image sequencing processed with optical correlators is being developed to determine position and velocity in support of lander guidance. The system is planned for testing in conjunction with Dryden Flight Research Facility. Advanced architecture technology is defining open architecture design constraints, test bed concepts (processors, multiple hardware/software and multi-dimensional user support, knowledge/tool sharing infrastructure), and software engineering interface issues.

Lum, Henry↗

Electronic control/display interface technology

An effort to produce a representative workstation for the Space Station Data Management Test Bed that provides man/machine interface design options for consolidating, automating, and integrating the space station work station, and hardware/software technology demonstrations of space station applications is discussed. The workstation will emphasize the technologies of advanced graphics engines, advanced display/control medias, image management techniques, multifunction controls, and video disk utilizations.

Parrish, R. V.↗

Hardware/Software Expansion of Display Terminal and CPU

IBM PC coupling used to expand capabilities of expensive specialpurpose system. IBM PC was interfaced to Tektronix CP1151 computer through teletype port of Tektronix 4010-1 computer display terminal. Electronic interface built to provide isolation, level shifting, and signal inversion between IBM PC RS-232 port and 4010-1 terminal teletype port. Modifications to 4010-1 terminal made to increase teletype rate from 110 to 9,600 baud. Software for both computers developed to give control of DPO system to IBM PC and provide data/program file exchange between two computers. Coupling demonstrates utilization of low-cost microcomputer hardware and software to expand capabilities of expensive special-purpose computer systems.

Adams, B. R.↗

Neutral buoyancy methodology for studying satellite servicing EVA crewmember interfaces

Current economic constraints indicate the need for incorporating the satellite servicing philosophy of commonality within the design of spacecraft subsytems. This philosophy is essential for conserving resources including hardware/software development and implementation costs, on-orbit and ground-based manpower, crew training/testing time, and documentation. In addition, spacecraft subsystem commonality may be coupled with standardization of operation procedures, and test and verification techniques for spacecraft design. Several spacecraft have adopted this practice, including Hubble Space Telescope, Space Station Freedom, and the Explorer Platform. As these and other programs continue and if effective crew interfaces and procedures are clearly and consistently defined, crew retraining for similar spacecraft subsystems will lessen, and procurement efforts will diminish. A relatively high fidelity zero-gravity simulation using water immersion is available to establish crew interfaces economically. The flexibility and utility of this space simulation medium for planning and assisting on-orbit operations was exemplified by astronaut evaluations of potential EVA electrical connectors. The testing was conducted at a NASA underwater neutral buoyancy training facility.

Barnby, Mary E.↗

An avionics scenario and command model description for Space Generic Open Avionics Architecture (SGOAA)

This paper presents a description of a model for a space vehicle operational scenario and the commands for avionics. This model will be used in developing a dynamic architecture simulation model using the Statemate CASE tool for validation of the Space Generic Open Avionics Architecture (SGOAA). The SGOAA has been proposed as an avionics architecture standard to NASA through its Strategic Avionics Technology Working Group (SATWG) and has been accepted by the Society of Automotive Engineers (SAE) for conversion into an SAE Avionics Standard. This architecture was developed for the Flight Data Systems Division (FDSD) of the NASA Johnson Space Center (JSC) by the Lockheed Engineering and Sciences Company (LESC), Houston, Texas. This SGOAA includes a generic system architecture for the entities in spacecraft avionics, a generic processing external and internal hardware architecture, and a nine class model of interfaces. The SGOAA is both scalable and recursive and can be applied to any hierarchical level of hardware/software processing systems.

Stovall, John R.↗

Definition and fabrication of an airborne scatterometer radar signal processor

A hardware/software system which incorporates a microprocessor design and software for the calculation of normalized radar cross section in real time was developed. Interface is provided to decommutate the NASA ADAS data stream for aircraft parameters used in processing and to provide output in the form of strip chart and pcm compatible data recording.

Source record↗