Engineering PapersSearch

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 127 records · Page 7

Extravehicular Activity (EVA) Power, Avionics, and Software (PAS) 101

EVA systems consist of a spacesuit or garment, a PLSS, a PAS system, and spacesuit interface hardware. The PAS system is responsible for providing power for the suit, communication of several types of data between the suit and other mission assets, avionics hardware to perform numerous data display and processing functions, and information systems that provide crewmembers data to perform their tasks with more autonomy and efficiency. Irimies discussed how technology development efforts have advanced the state-of-the-art in these areas and shared technology development challenges.

Irimies, David

Electronics for Mars Exploration Rover and beyond

Mars exploration seeks to understand the potential for life elsewhere in the universe; characterize the present and past climate and climate processes; understand geological processes affecting Mars' interior, crust, and surface; and, develop the knowledge and technology necessary for eventual human exploration. The design of a Mars Exploration rover is discussed, in particular it electronic components. The avionics development activities for the subsystem and hardware functionality are outlined. The functions and interfaces of the Rover Electronics Module, Cruise Electronics Module, and Lander Electronics Module are highlighted.

avionics

A Library of Rad Hard Mixed-Voltage/Mixed-Signal Building Blocks for Integration of Avionics Systems for Deep Space

To build the sensor intensive system-on-a-chip for the next generation spacecrafts for deep space, Center for Integration of Space Microsystems at JPL (CISM) takes advantage of the lower power rating and inherent radiation resistance of Silicon on Insulator technology (SOI). We are developing a suite of mixed-voltage and mixed-signal building blocks in Honeywell's SOI process that can enable the rapid integration of the next generation avionics systems with lower power rating, higher reliability, longer life, and enhanced radiation tolerance for spacecrafts such as the Europa Orbiter and Europa Lander. The mixed-voltage building blocks are predominantly for design of adaptive power management systems. Their design centers around an LDMOS structure that is being developed by Honeywell, Boeing Corp, and the University of Idaho. The mixed-signal building blocks are designed to meet the low power, extreme radiation requirement of deep space applications. These building blocks are predominantly used to interface analog sensors to the digital CPU of the next generation avionics system on a chip. Additional information is contained in the original extended abstract.

Mojarradi, M. M.

Avionics Architectures for Exploration: Ongoing Efforts in Human Spaceflight

The field of Avionics is advancing far more rapidly in terrestrial applications than in spaceflight applications. Spaceflight Avionics are not keeping pace with expectations set by terrestrial experience, nor are they keeping pace with the need for increasingly complex automation and crew interfaces as we move beyond Low Earth Orbit. NASA must take advantage of the strides being made by both space-related and terrestrial industries to drive our development and sustaining costs down. This paper describes ongoing efforts by the Avionics Architectures for Exploration (AAE) project chartered by NASA's Advanced Exploration Systems (AES) Program to evaluate new avionic architectures and technologies, provide objective comparisons of them, and mature selected technologies for flight and for use by other AES projects. The AAE project team includes members from most NASA centers, and from industry. It is our intent to develop a common core avionic system that has standard capabilities and interfaces, and contains the basic elements and functionality needed for any spacecraft. This common core will be scalable and tailored to specific missions. It will incorporate hardware and software from multiple vendors, and be upgradeable in order to infuse incremental capabilities and new technologies. It will maximize the use of reconfigurable open source software (e.g., Goddard Space Flight Center's (GSFC's) Core Flight Software (CFS)). Our long-term focus is on improving functionality, reliability, and autonomy, while reducing size, weight, and power. Where possible, we will leverage terrestrial commercial capabilities to drive down development and sustaining costs. We will select promising technologies for evaluation, compare them in an objective manner, and mature them to be available for future programs. The remainder of this paper describes our approach, technical areas of emphasis, integrated test experience and results as of mid-2014, and future plans. As a part of the AES Program, we are encouraged to set aggressive goals and fall short if necessary, rather than to set our sights too low. We are also asked to emphasize providing our personnel with hands-on experience in development, integration, and testing. That we have embraced both of these philosophies will be evident in the descriptions below.

Goforth, Montgomery B.

Considerations for the retrofit of data link

Human factors issues related to the retrofit of data link in commercial transport aircraft are discussed. Topics that must be considered for data link implementation include, the loss of the party line, (i.e., the availability to all aircraft of information transmitted on a common voice frequency), and the scheduling of information to the flight crew. This paper focuses primarily on the human factors issues related to retrofit of Mode S. Retrofits is a difficult task because panel space accessible to flight crew members is limited. As with all cockpit equipment, data link implementation will have to comply with Federal Aviation Regulation 25.1523, which requires the manufacturer to address the conspicuity and ease of use of the data link device, and to assess the impact on crew workload. Operational sequence diagrams are provided to illustrate a methodology that can be used to decompose the flight crew body channel utilization of candidate avionics configurations in order to optimize the pilot-vehicle interface.

Corwin, William H.

Reference Avionics Architecture for Lunar Surface Systems

Developing and delivering infrastructure capable of supporting long-term manned operations to the lunar surface has been a primary objective of the Constellation Program in the Exploration Systems Mission Directorate. Several concepts have been developed related to development and deployment lunar exploration vehicles and assets that provide critical functionality such as transportation, habitation, and communication, to name a few. Together, these systems perform complex safety-critical functions, largely dependent on avionics for control and behavior of system functions. These functions are implemented using interchangeable, modular avionics designed for lunar transit and lunar surface deployment. Systems are optimized towards reuse and commonality of form and interface and can be configured via software or component integration for special purpose applications. There are two core concepts in the reference avionics architecture described in this report. The first concept uses distributed, smart systems to manage complexity, simplify integration, and facilitate commonality. The second core concept is to employ extensive commonality between elements and subsystems. These two concepts are used in the context of developing reference designs for many lunar surface exploration vehicles and elements. These concepts are repeated constantly as architectural patterns in a conceptual architectural framework. This report describes the use of these architectural patterns in a reference avionics architecture for Lunar surface systems elements.

Somervill, Kevin M.

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control

An Investigation of Interval Management Displays

NASA's first Air Traffic Management (ATM) Technology Demonstration (ATD-1) was created to transition the most mature ATM technologies from the laboratory to the National Airspace System. One selected technology is Interval Management (IM), which uses onboard aircraft automation to compute speeds that help the flight crew achieve and maintain precise spacing behind a preceding aircraft. Since ATD-1 focuses on a near-term environment, the ATD-1 flight demonstration prototype requires radio voice communication to issue an IM clearance. Retrofit IM displays will enable pilots to both enter information into the IM avionics and monitor IM operation. These displays could consist of an interface to enter data from an IM clearance and also an auxiliary display that presents critical information in the primary field-of-view. A human-in-the-loop experiment was conducted to examine usability and acceptability of retrofit IM displays, which flight crews found acceptable. Results also indicate the need for salient alerting when new speeds are generated and the desire to have a primary field of view display available that can display text and graphic trend indicators.

Swieringa, Kurt A.

Avionics System Architecture Tool

Avionics System Architecture Tool (ASAT) is a computer program intended for use during the avionics-system-architecture- design phase of the process of designing a spacecraft for a specific mission. ASAT enables simulation of the dynamics of the command-and-data-handling functions of the spacecraft avionics in the scenarios in which the spacecraft is expected to operate. ASAT is built upon I-Logix Statemate MAGNUM, providing a complement of dynamic system modeling tools, including a graphical user interface (GUI), modeling checking capabilities, and a simulation engine. ASAT augments this with a library of predefined avionics components and additional software to support building and analyzing avionics hardware architectures using these components.

Chau, Savio

Radio-hosted Flight / Ground Interface for Operations Standardization

The interface between a spacecraft and its ground operations segment includes the flow of commands, configuration, and sequencing elements to the spacecraft, and the flow of telemetry and data products from the spacecraft. Creating and implementing a complete definition of this interface simplifies and standardizes mission operations, allowing easy sharing of operations personnel across missions. Early spacecraft featured a simple flight / ground interface (FGI) using hardware command decoding in the radio, driven by technological limitations of the time. Modern spacecraft use command and data handling (CDH) avionics on which flight software executes, which in turn controls and configures the mission, executes subsystem and instrument instructions, and implements critical fault protection actions. Deep space missions feature advanced operations software for running sequenced activities over a period of weeks, which allows them to function with only infrequent ground contact. This approach comes at the cost of increased complexity in the FGI, requiring expensive modifications to heritage flight software and ground systems. By hosting the interface in the radio instead of the CDH avionics, modern missions can approximate the FGI design simplicity of early spacecraft, with significant advantages for vendor competition, lowered costs, standardization of operations, and reduction of implementation risk.

Lock, Patricia D.

Wearable Technology

Wearable technology projects, to be useful, in the future, must be seamlessly integrated with the Flight Deck of the Future (F.F). The lab contains mockups of space vehicle cockpits, habitat living quarters, and workstations equipped with novel user interfaces. The Flight Deck of the Future is one element of the Integrated Power, Avionics, and Software (IPAS) facility, which, to a large extent, manages the F.F network and data systems. To date, integration with the Flight Deck of the Future has been limited by a lack of tools and understanding of the Flight Deck of the Future data handling systems. To remedy this problem it will be necessary to learn how data is managed in the Flight Deck of the Future and to develop tools or interfaces that enable easy integration of WEAR Lab and EV3 products into the Flight Deck of the Future mockups. This capability is critical to future prototype integration, evaluation, and demonstration. This will provide the ability for WEAR Lab products, EV3 human interface prototypes, and technologies from other JSC organizations to be evaluated and tested while in the Flight Deck of the Future. All WEAR Lab products must be integrated with the interface that will connect them to the Flight Deck of the Future. The WEAR Lab products will primarily be programmed in Arduino. Arduino will be used for the development of wearable controls and a tactile communication garment. Arduino will also be used in creating wearable methane detection and warning system.

Watson, Amanda

Wireless Avionics Packet to Support Fault Tolerance for Flight Applications

In this protocol and packet format, data traffic is monitored by all network interfaces to determine the health of transmitter and subsystems. When failures are detected, the network inter face applies its recover y policies to provide continued service despite the presence of faults. The protocol, packet format, and inter face are independent of the data link technology used. The current demonstration system supports both commercial off-the-shelf wireless connections and wired Ethernet connections. Other technologies such as 1553 or serial data links can be used for the network backbone. The Wireless Avionics packet is divided into three parts: a header, a data payload, and a checksum. The header has the following components: magic number, version, quality of service, time to live, sending transceiver, function code, payload length, source Application Data Interface (ADI) address, destination ADI address, sending node address, target node address, and a sequence number. The magic number is used to identify WAV packets, and allows the packet format to be updated in the future. The quality of service field allows routing decisions to be made based on this value and can be used to route critical management data over a dedicated channel. The time to live value is used to discard misrouted packets while the source transceiver is updated at each hop. This information is used to monitor the health of each transceiver in the network. To identify the packet type, the function code is used. Besides having a regular data packet, the system supports diagnostic packets for fault detection and isolation. The payload length specifies the number of data bytes in the payload, and this supports variable-length packets in the network. The source ADI is the address of the originating interface. This can be used by the destination application to identify the originating source of the packet where the address consists of a subnet, subsystem class within the subnet, a subsystem unit, and the local ADI number. The destination ADI is used to route the packet to its ultimate destination. At each hop, the sending interface uses the destination address to determine the next node for the data. The sending node is the node address of the interface that is broadcasting the packet. This field is used to determine the health of the subsystem that is sending the packet. In the case of a packet that traverses several intermediate nodes, it may be the node address of the intermediate node. The target node is the node address of the next hop for the packet. It may be an intermediate node, or the final destination for the packet. The sequence number is used to identify duplicate packets. Because each interface has multiple transceivers, the same packet will appear at both receivers. The sequence number allows the interface to correlate the reception and forward a single, unique packet for additional processing. The subnet field allows data traffic to be partitioned into segregated local networks to support large networks while keeping each subnet at a manageable size. This also keeps the routing table small enough so routing can be done by a simple table lookup in an FPGA device. The subsystem class identifies members of a set of redundant subsystems, and, in a hot standby configuration, all members of the subsystem class will receive the data packets. Only the active subsystem will generate data traffic. Specific units in a class of redundant units can be identified and, if the hot standby configuration is not used, packets will be directed to a specific subsystem unit.

Block, Gary L.

NEXUS Scalable and Distributed Next-Generation Avionics Bus for Space Missions

A paper discusses NEXUS, a common, next-generation avionics interconnect that is transparently compatible with wired, fiber-optic, and RF physical layers; provides a flexible, scalable, packet switched topology; is fault-tolerant with sub-microsecond detection/recovery latency; has scalable bandwidth from 1 Kbps to 10 Gbps; has guaranteed real-time determinism with sub-microsecond latency/jitter; has built-in testability; features low power consumption (< 100 mW per Gbps); is lightweight with about a 5,000-logic-gate footprint; and is implemented in a small Bus Interface Unit (BIU) with reconfigurable back-end providing interface to legacy subsystems. NEXUS enhances a commercial interconnect standard, Serial RapidIO, to meet avionics interconnect requirements without breaking the standard. This unified interconnect technology can be used to meet performance, power, size, and reliability requirements of all ranges of equipment, sensors, and actuators at chip-to-chip, board-to-board, or box-to-box boundary. Early results from in-house modeling activity of Serial RapidIO using VisualSim indicate that the use of a switched, high-performance avionics network will provide a quantum leap in spacecraft onboard science and autonomy capability for science and exploration missions.

He, Yutao

Reliability and the design process at Honeywell Avionics Division

The division's philosophy for designed-in reliability and a comparison of reliability programs for space, manned military aircraft, and commercial aircraft, are presented. Topics include: the reliability interface with design and production; the concept phase through final proposal; the design, development, test and evaluation phase; the production phase; and the commonality among space, military, and commercial avionics.

Bezat, A.

FPGA for Power Control of MSL Avionics

A PLGT FPGA (Field Programmable Gate Array) is included in the LCC (Load Control Card), GID (Guidance Interface & Drivers), TMC (Telemetry Multiplexer Card), and PFC (Pyro Firing Card) boards of the Mars Science Laboratory (MSL) spacecraft. (PLGT stands for PFC, LCC, GID, and TMC.) It provides the interface between the backside bus and the power drivers on these boards. The LCC drives power switches to switch power loads, and also relays. The GID drives the thrusters and latch valves, as well as having the star-tracker and Sun-sensor interface. The PFC drives pyros, and the TMC receives digital and analog telemetry. The FPGA is implemented both in Xilinx (Spartan 3- 400) and in Actel (RTSX72SU, ASX72S). The Xilinx Spartan 3 part is used for the breadboard, the Actel ASX part is used for the EM (Engineer Module), and the pin-compatible, radiation-hardened RTSX part is used for final EM and flight. The MSL spacecraft uses a FC (Flight Computer) to control power loads, relays, thrusters, latch valves, Sun-sensor, and star-tracker, and to read telemetry such as temperature. Commands are sent over a 1553 bus to the MREU (Multi-Mission System Architecture Platform Remote Engineering Unit). The MREU resends over a remote serial command bus c-bus to the LCC, GID TMC, and PFC. The MREU also sends out telemetry addresses via a remote serial telemetry address bus to the LCC, GID, TMC, and PFC, and the status is returned over the remote serial telemetry data bus.

Wang, Duo

Inlet design technology development - Supersonic cruise research

An inlet technology development program for future supersonic cruise aircraft is in progress. Areas being emphasized are inlet aerodynamic and control system design requirements for efficient and reliable operation. Off-design conditions, such as angle of incidence, starting, and noise abatement are major considerations. Flow analysis procedures are being developed to predict the internal inviscid and viscous flows in axisymmtric supersonic inlets for these operating conditions. Also under development are control systems that will have significant interfaces with the engine control system, the flight control system, and the airframe avionics system. The analytical methods are being supported and validated with representative experiments.

Syberg, J.

Advanced cockpit technology for future civil transport aircraft

A review is presented of advanced cockpit technology for future civil transport aircraft, covering the present state-of-the-art and major technologies, including flat-panel displays, graphics and pictorial displays. Pilot aiding/automation/human-centered design and imaging sensor/flight systems technology (for low-visibility operations) are also presented. NASA Langley Research Center's recent results in pictorial displays and on future developments in large-screen display technologies are discussed. Major characteristics foreseen for the future high-speed civil transport include fault-tolerant digital avionics and controls/displays with extensive human-centered automation, and unusually clean, uncluttered interface with natural crew interaction via touch, voice/tactile means.

Hatfield, Jack J.