Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “avionics 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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS1984

The pilot interface with cockpit automation and advanced avionics systems

A flight test program was conducted with a sophisticated, integrated avionics system to study pilot workload and the pilot interface with high levels of avionics capability. The study indicates that advanced systems can provide improved information to the pilot and additional functional capability. The study also indicates that additional research is needed to develop the knowledge base required to design pilot interfaces with such systems. The combination of the pilot interface and the high level of system capability used in this study led to pilot blunders associated with navigation data management, autopilot management, and maintaining awareness of system status. A functional relationship is suggested between level of avionics system sophistication and the required state-of-the-art in pilot/avionics interface design. Suggested guidelines for the design of the pilot/avionics interface for advanced avionics systems are given.

Hinton, D. A.↗
NASA NTRS1997

Open-Loop HIRF Experiments Performed on a Fault Tolerant Flight Control Computer

During the third quarter of 1996, the Closed-Loop Systems Laboratory was established at the NASA Langley Research Center (LaRC) to study the effects of High Intensity Radiated Fields on complex avionic systems and control system components. This new facility provided a link and expanded upon the existing capabilities of the High Intensity Radiated Fields Laboratory at LaRC that were constructed and certified during 1995-96. The scope of the Closed-Loop Systems Laboratory is to place highly integrated avionics instrumentation into a high intensity radiated field environment, interface the avionics to a real-time flight simulation that incorporates aircraft dynamics, engines, sensors, actuators and atmospheric turbulence, and collect, analyze, and model aircraft performance. This paper describes the layout and functionality of the Closed-Loop Systems Laboratory, and the open-loop calibration experiments that led up to the commencement of closed-loop real-time flight experiments.

Koppen, Daniel M.↗
NASA NTRS1999

Design Description of the X-33 Avionics Architecture

In this paper, we provide a design description of the X-33 avionics architecture. The X-33 is an autonomous Single Stage to Orbit (SSTO) launch vehicle currently being developed by Lockheed Martin for NASA as a technology demonstrator for the VentureStar Reusable Launch Vehicle (RLV). The X-33 avionics provides autonomous control of die vehicle throughout takeoff, ascent, descent, approach, landing, rollout, and vehicle safing. During flight the avionics provides communication to the range through uplinked commands and downlinked telemetry. During pre-launch and post-safing activities, the avionics provides interfaces to ground support consoles that perform vehicle flight preparations and maintenance. The X-33 Avionics is a hybrid of centralized and distributed processing elements connected by three dual redundant Mil-Std 1553 data buses. These data buses are controlled by a central processing suite located in the avionics bay and composed of triplex redundant Vehicle Mission Computers (VMCs). The VMCs integrate mission management, guidance, navigation, flight control, subsystem control and redundancy management functions. The vehicle sensors, effectors and subsystems are interfaced directly to the centralized VMCs as remote terminals or through dual redundant Data Interface Units (DIUs). The DIUs are located forward and aft of the avionics bay and provide signal conditioning, health monitoring, low level subsystem control and data interface functions. Each VMC is connected to all three redundant 1553 data buses for monitoring and provides a complete identical data set to the processing algorithms. This enables bus faults to be detected and reconfigured through a voted bus control configuration. Data is also shared between VMCs though a cross channel data link that is implemented in hardware and controlled by AlliedSignal's Fault Tolerant Executive (FTE). The FTE synchronizes processors within the VMC and synchronizes redundant VMCs to each other. The FTE provides an output-voting plane to detect, isolate and contain faults due to internal hardware or software faults and reconfigures the VMCs to accommodate these faults. Critical data in the 1553 messages are scheduled and synchronized to specific processing frames in order to minimize data latency. In order to achieve an open architecture, military and commercial off-the-shelf equipment is incorporated using common processors, standard VME backplanes and chassis, the VxWorks operating system, and MartixX for automatic code generation. The use of off-the-shelf tools and equipment helps reduce development time and enables software reuse. The open architecture allows for technology insertion, while the distributed modular elements allow for expansion to increased redundancy levels to meet the higher reliability goals of future RLVs.

Reichenfeld, Curtis J.↗
NASA NTRS1979

Shuttle payload S-band communications study

The work to identify, evaluate, and make recommendations concerning the functions and interfaces of those orbiter avionic subsystems which are dedicated to, or play some part in, handling communication signals (telemetry and command) to/from payloads (spacecraft) that will be carried into orbit by the shuttle is reported. Some principal directions of the research are: (1) analysis of the ability of the various avionic equipment to interface with and appropriately process payload signals; (2) development of criteria which will foster equipment compatibility with diverse types of payloads and signals; (3) study of operational procedures, especially those affecting signal acquisition; (4) trade-off analysis for end-to-end data link performance optimization; (5) identification of possible hardware design weakness which might degrade signal processing performance.

Springett, J. C.↗
NASA NTRS1989

Preliminary design document: Ground based testbed for avionics systems

The design and interface requirements for an avionics Ground Based Test bed (GBT) to support Heavy Lift Cargo Vehicles (HLCV) is presented. It also contains data on the vehicle subsystem configurations that are to be supported during their early, pre-PDR developmental phases. Several emerging technologies are also identified for support. A Preliminary Specification Tree is also presented.

Source record↗
NASA NTRS2008

Ares I Crew Launch Vehicle Upper Stage Avionics and Software Overview

This viewgraph presentation gives an overall description of the avionics and software functions of the Ares I Upper Stage Crew Launch Vehicle. The contents include: 1) IUA Team - Development Approach Roadmap; 2) Ares I US Avionics and Software Development Approach; 3) NDT Responsibilities; 4) Ares I Upper Stage Avionics Locations; 5) Ares I Overall Avionics & Software Functions; 6) Block Diagram Version of Avionics Architecture; 7) Instrument Unit Avionics Preliminary Design; and 8) Upper Stage Avionics External Interfaces.

Nola, Charles L.↗
NASA NTRS1995

A Multi-Mission Space Avionics Architecture

As the budget for the space industry is dwindling, a reusable avionics architecture applicable across multiple missions is urgently needed to reduce the development and production costs of flight projects. This paper presents a multi-mission avionics architecture which employs interface standards extensively, sot hat avionics systems can be built rapidly by assembling subsystems and instruments in a plug-and-play manner. The key feature of this architecture is a "backbone" standard parallel bus which can accommodate various standard interfaces through a repertoire of I/O modules. Hence, specific ;mission requirements can be met by selecting and integrating the appropriate subsystems and instruments into the system. This architecture can also adopt different "backbone" buses, implement redundant processors, and support distributed processing. An example of the architecture using the MOPS6000 from the Southwest Research Institute is also described. Experiments will be done in the Flight System Testbed (FST) of the Jet Propulsion Laboratory to benchmark the MOPS6000 and to demonstrate its multi-mission capability.

Avionics↗
NASA NTRS2017

Hardware Interface Description for the Integrated Power, Avionics, and Software (iPAS) Space Telecommunications Radio Ssystem (STRS) Radio

The Space Telecommunications Radio System (STRS) provides a common, consistent framework for software defined radios (SDRs) to abstract the application software from the radio platform hardware. The STRS standard aims to reduce the cost and risk of using complex, configurable and reprogrammable radio systems across NASA missions. To promote the use of the STRS architecture for future NASA advanced exploration missions, NASA Glenn Research Center (GRC) developed an STRS-compliant SDR on a radio platform used by the Advance Exploration System program at the Johnson Space Center (JSC) in their Integrated Power, Avionics, and Software (iPAS) laboratory. The iPAS STRS Radio was implemented on the Reconfigurable, Intelligently-Adaptive Communication System (RIACS) platform, currently being used for radio development at JSC. The platform consists of a Xilinx ML605 Virtex-6 FPGA board, an Analog Devices FMCOMMS1-EBZ RF transceiver board, and an Embedded PC (Axiomtek eBox 620-110-FL) running the Ubuntu 12.4 operating system. Figure 1 shows the RIACS platform hardware. The result of this development is a very low cost STRS compliant platform that can be used for waveform developments for multiple applications.The purpose of this document is to describe how to develop a new waveform using the RIACS platform and the Very High Speed Integrated Circuits (VHSIC) Hardware Description Language (VHDL) FPGA wrapper code and the STRS implementation on the Axiomtek processor.

Flight Computer↗
NASA NTRS1975

Tug and payload-to-Orbiter interface requirements

This paper presents results of a study to identify, evaluate, and develop Tug plus payload-to-Orbiter accommodation requirements. Interface areas include structural, mechanical, fluids, environmental, avionics, and safety. Each interface area was investigated to determine the best physical and operational method of accomplishing the required functions with an overriding goal of establishing sample and flexible interface requirements suitable for Tug, Tug payloads, and other cargo. The recommended system for supporting the Tug and its payload from the Orbiter employs a cylindrical load-carrying structure called a deployment adapter that has a rotational capability for Tug deployment. The design and operation of the deployment adapter and other peripheral interface equipment such as crew compartment monitor and control panels and cargo bay fluid and electrical interface panels are discussed.

Bock, E. H.↗
NASA NTRS1994

Lean spacecraft avionics trade study

Spacecraft design is generally an exercise in design trade-offs: fuel vs. weight, power vs. solar cell area, radiation exposure vs. shield weight, etc. Proper analysis of these trades is critical in the development of lightweight, efficient, 'lean' satellites. The modification of the launch plans for the Magnetosphere Imager (MI) to a Taurus launcher from the much more powerful Delta has forced a reduction in spacecraft weight availability into the mission orbit from 1300 kg to less than 500 kg. With weight now a driving factor it is imperative that the satellite design be extremely efficient and lean. The accuracy of engineering trades now takes on an added importance. An understanding of spacecraft subsystem interactions is critical in the development of a good spacecraft design, yet it is a challenge to define these interactions while the design is immature. This is currently an issue in the development of the preliminary design of the MI. The interaction and interfaces between this spacecraft and the instruments it carries are currently unclear since the mission instruments are still under development. It is imperative, however, to define these interfaces so that avionics requirements ideally suited to the mission's needs can be determined.

Main, John A.↗
NASA NTRS1999

Pyroshock Environments Characterized for Spacecraft Missions

Pyrotechnic shock, or pyroshock, is the transient response of a structure to loading induced by the ignition of pyrotechnic (explosive or propellant activated) devices. These devices are typically used to separate structural systems (e.g., separate a spacecraft from a launch vehicle) and deploy appendages (e.g., solar panels). Pyroshocks are characterized by high peak acceleration, high-frequency content, and short duration. Because of their high acceleration and high-frequency, pyroshocks can cause spaceflight hardware to fail. Verifying by test that spaceflight hardware can withstand the anticipated shock environment is considered essential to mission success. The Earth Observing System (EOS) AM-1 spacecraft for NASA's Mission to Planet Earth is scheduled to be launched on an Atlas IIAS vehicle in 1999, and the NASA Lewis Research Center is the launch vehicle integrator for this NASA Goddard Space Flight Center spacecraft. The EOS spacecraft was subjected to numerous ground shock tests to verify that its scientific instruments and avionics components will withstand the shock-induced vibration produced when the spacecraft separates from the launch vehicle. Shock test data from these tests represent the third largest available pyroshock database in the United States. Future spacecraft missions will directly benefit from the knowledge gained from these tests. The payload separation system used for EOS is a new system that operates by firing six separation nuts. This system was tested to verify its functional operation and to characterize the resulting shock levels. The launch vehicle contractor (Lockheed Martin Astronautics) and spacecraft contractor (Lockheed Martin Missiles & Space) completed 16 separation test firings. This resulted in an unusually large amount of pyroshock data. Typically, only one or two pyroshock test firings are performed for a spacecraft mission. Because of the size of this separation system shock database, engineers were able to perform unique statistical analyses to characterize the distribution of the test data. For example, it was proven that the shock data follow a lognormal distribution, a concept often assumed but rarely proven. The test-to-test repeatability of the shock source level was analyzed, and the effects of various test configurations and separation nut production lots were examined and quantified. Engineers investigated the change in shock level as the shock traveled from the spacecraft separation interface to the avionics components of the upper stage and analyzed the effects of the structural fidelity (simulator versus real) of the components and their weight on vibrational response. In addition, the shock attenuation with distance and across joints was quantified and compared with concepts originally generated in 1970, and the effects of separation nut preload and firing sequences effects were examined. Because of this EOS shock testing and the analyses performed at NASA Lewis, a significant amount of new information on pyroshock and its characteristics is now available to the aerospace industry. We hope that this information will help future spacecraft test planners to perform better and cheaper spacecraft separation shock tests and to better understand their test data.

Hughes, William O.↗
NASA NTRS2012

Modular, Autonomous Command and Data Handling Software with Built-In Simulation and Test

The spacecraft system that plays the greatest role throughout the program lifecycle is the Command and Data Handling System (C&DH), along with the associated algorithms and software. The C&DH takes on this role as cost driver because it is the brains of the spacecraft and is the element of the system that is primarily responsible for the integration and interoperability of all spacecraft subsystems. During design and development, many activities associated with mission design, system engineering, and subsystem development result in products that are directly supported by the C&DH, such as interfaces, algorithms, flight software (FSW), and parameter sets. A modular system architecture has been developed that provides a means for rapid spacecraft assembly, test, and integration. This modular C&DH software architecture, which can be targeted and adapted to a wide variety of spacecraft architectures, payloads, and mission requirements, eliminates the current practice of rewriting the spacecraft software and test environment for every mission. This software allows missionspecific software and algorithms to be rapidly integrated and tested, significantly decreasing time involved in the software development cycle. Additionally, the FSW includes an Onboard Dynamic Simulation System (ODySSy) that allows the C&DH software to support rapid integration and test. With this solution, the C&DH software capabilities will encompass all phases of the spacecraft lifecycle. ODySSy is an on-board simulation capability built directly into the FSW that provides dynamic built-in test capabilities as soon as the FSW image is loaded onto the processor. It includes a six-degrees- of-freedom, high-fidelity simulation that allows complete closed-loop and hardware-in-the-loop testing of a spacecraft in a ground processing environment without any additional external stimuli. ODySSy can intercept and modify sensor inputs using mathematical sensor models, and can intercept and respond to actuator commands. ODySSy integration is unique in that it allows testing of actual mission sequences on the flight vehicle while the spacecraft is in various stages of assembly, test, and launch operations all without any external support equipment or simulators. The ODySSy component of the FSW significantly decreases the time required for integration and test by providing an automated, standardized, and modular approach to integrated avionics and component interface and functional verification. ODySSy further provides the capability for on-orbit support in the form of autonomous mission planning and fault protection.

Cuseo, John↗
NASA NTRS1973

Trends in transport aircraft avionics

A survey of avionics onboard present commercial transport aircraft was conducted to identify trends in avionics systems characteristics and to determine the impact of technology advances on equipment weight, cost, reliability, and maintainability. Transport aircraft avionics systems are described under the headings of communication, navigation, flight control, and instrumentation. The equipment included in each section is described functionally. However, since more detailed descriptions of the equipment can be found in other sources, the description is limited and emphasis is put on configuration requirements. Since airborne avionics systems must interface with ground facilities, certain ground facilities are described as they relate to the airborne systems, with special emphasis on air traffic control and all-weather landing capability.

Berkstresser, B. K.↗
NASA NTRS1984

General Aviation Technology Conference, Hampton, VA, July 10-12, 1984, Technical Papers

The present conference on general aviation aircraft design considers the performance tradeoffs involved in two- and three-control surface aerodynamic configurations, wing design criteria for increased resistance to spins, the performance levels obtained by flight and wind tunnel tests of an 'electroimpulse' deicing system, and the chracteristics of lightning strikes experienced by the NASA F-106B research aircraft. Also considered are the application of speech recognition and synthesis systems to general aviation cockpits, control and display requirements for single-pilot Instrument Flight Rules, pilot interfacing with advanced avionics and automated cockpit systems, the feasibility of sidestick controllers for general aviation aircraft, the acoustic prediction methods incorporated by the NASA Generalized Advanced Propeller Analysis System, and the adhesively bonded structure of the Citation II business jet aircraft.

Source record↗
NASA NTRS1980

STS-2: SAIL non-avionics subsystems math model requirements

Simulation of the STS-2 Shuttle nonavionics subsystems in the shuttle avionics integration laboratory (SAIL) is necessary for verification of the integrated shuttle avionics system. The math model (simulation) requirements for each of the nonavionics subsystems that interfaces with the Shuttle avionics system is documented and a single source document for controlling approved changes (by the SAIL change control panel) to the math models is provided.

Bennett, W. P.↗
NASA NTRS1995

The role of standards in lower-cost digital spacecraft avionics

The use of standard interfaces could result in large savings for the aerospace industry. This paper discusses the philosophy, applicability, and implications of using interface standards in spacecraft applications. It is argued that, while there are some negatives associated with their use, standards should be liberally applied to all aspects of spacecraft avionics because they ultimately reduce end-to-end system costs.

Caldwell, Douglas W.↗