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 19 records

Integrated design checkout of shuttle payload avionics interfaces

Orbiter/payload avionics integration testing in the shuttle program are discussed. Payloads show extensive orbiter interfaces. The three testing modes used to verify orbiter/payload avionics interfaces are described. These modes consist of orbiter testing using generic payload simulators, payload testing utilizing the actual payload and a high fidelity orbiter simulator, and interface testing with the actual orbiter and payload. Several special avionics techniques, such as the split flight computer technique were developed for this testing. Experience from the first six shuttle cargoes is reviewed and problems found in testing that would have hampered mission success are emphasized.

Muratore, J. F.

Customer Avionics Interface Development and Analysis (CAIDA): Software Developer for Avionics Systems

The Customer Avionics Interface Development and Analysis (CAIDA) supports the testing of the Launch Control System (LCS), NASA's command and control system for the Space Launch System (SLS), Orion Multi-Purpose Crew Vehicle (MPCV), and ground support equipment. The objective of the semester-long internship was to support day-to-day operations of CAIDA and help prepare for verification and validation of CAIDA software.

Mitchell, Sherry L.

Customer Avionics Interface Development and Analysis Development Activity Tracking System

The Customer Avionics Interface Development and Analysis (CAIDA) Development Activity (DA)Tracking System is a Microsoft Access Database that tracks, organizes, and analyzes data about DAs from the work management tool. The CAIDA DA Tracking System takes data imported from the work management system. Once in the system, the data is filtered to generate each DA’s Asset. From there, many different queries are run on the data and their results are imported into forms to create graphs to get and display a wide range of metrics. These graphs are automatically updated with each new data import and over time. They can be easily exported for use in presentations, documents, etc. Additionally, the system is highly customizable and can be added upon to include more data members, generate new graphs, and much more.

Tara Conti

Customer Avionics Interface Development and Analysis (CAIDA) Lab DEWESoft Display Creation

The Customer Avionics Interface Development and Analysis (CAIDA) Lab supports the testing of the Launch Control System (LCS), NASA's command and control system for the Space Launch System (SLS), Orion Multi-Purpose Crew Vehicle (MPCV), and ground support equipment. The objectives of the year-long internship were to support day-to-day operations of the CAIDA Lab, create prelaunch and tracking displays for Orion's Exploration Flight Test 1 (EFT-1), and create a program to automate the creation of displays for SLS and MPCV to be used by CAIDA and the Record and Playback Subsystem (RPS).

DEWESoft

Space shuttle engineering and operations support. Orbiter to spacelab electrical power interface. Avionics system engineering

The results are presented of an investigation of the factors which affect the determination of Spacelab (S/L) minimum interface main dc voltage and available power from the orbiter. The dedicated fuel cell mode of powering the S/L is examined along with the minimum S/L interface voltage and available power using the predicted fuel cell power plant performance curves. The values obtained are slightly lower than current estimates and represent a more marginal operating condition than previously estimated.

Emmons, T. E.

Spacelab payload accommodation handbook. Appendix A: Avionics interface definition

The Spacelab side of the electrical interface between Spacelab subsystem equipment and experiments is presented. The electrical hardware which interfaces with the experiments is defined and the signal/load characteristics are stated. Major subsystems considered include: electrical power and distribution; command and data management subsystem; orbiter avionics via dedicated connectors of Spacelab; and electrical ground support equipment.

Source record

Tug payload interfaces

Some conclusions reached during the IUS/Tug payload requirements compatibility study are presented. This study is concerned with all prospective Tug-payload interfaces, including detailed analysis of low-earth orbit, geosynchronous, and interplanetary missions. Tug payload requirements are discussed and summarized as to operational requirements, structural/mechanical interface, avionics interfaces, fluids interface, and environment. The shuttle impacts created by Tug/payload interfaces are examined and presented in tabular form. Major conclusions are that all payloads in the mission model can be suitably and inexpensively accommodated by the Tug and the Shuttle if standardized integration equipment is employed, that multiple payloads pose no significant integration challenge, and that a relatively small inventory of integration equipment is required to support all prospective payloads.

Runge, F.

Europa Clipper Payload Verification and Validation: Avionics-Instrument Interface Test Campaign

NASA's Europa Clipper mission will investigate Jupiter's icy moon Europa using a payload suite consisting of nine instruments to address a range of scientific objectives concerning Europa's habitability. As the project proceeds past its Critical Design Review, confidence is being built in the system's ability to achieve mission objectives through the implementation of a rigorous payload verification and validation (V&V) program. As part of this payload V&V program, instrument box-level testing was performed by the payload team to verify select instrument-avionics interface requirements. This testing was performed at JPL using the avionics testbed's Bulk Data Storage Emulator (BDSEM) with visiting instrument Test Models. This paper summarizes the Data Link test campaign involving roughly four days of functional testing per instrument, including planning, testing methods, types of issues found, and the requirement closure process. Detail is also provided on the development, deployment, and validation of a standardized analysis tool used in data reviews. This testing verified requirements related to commanding rates, loss of link, packet format, clock counters, loopback test capability, and SpaceWire jitter and skew margins. Additional risk reduction testing of basic commanding, counter behavior, science data collection and transfer, and interface swapping was also performed. Because the BDSEM venue was not originally designed to be a run for record venue, the process of characterizing venue fidelity and establishing suitability for requirement closure using data collected in this venue will also be addressed.In order to close requirements, an extensible tool was developed to post-process instrument command and telemetry data from their original binary to a human-readable format and give visibility to errors detected within the data, such as packets with Cyclic Redundancy Check errors. This tool, called payload-packet-parser, is a Python 3.9 command line tool built using a variety of open-source Python libraries. Payload-packet-parser was designed to support parsing command and telemetry packets for all Europa Clipper instruments and additional analysis tools were developed for verification of specific information interface requirements. This test campaign, including post-processing using a single parsing and verification toolset, allowed for early interface testing, alleviating testing burdens on instrument teams and buying down risk on the instrument-avionics interface by finding hardware and software issues and idiosyncrasies prior to integration with system test venues. Over twenty issues were discovered across the payload, resulting in software updates and instrument rework well in advance of any system impacts. This paper concludes with an assessment of benefits and costs of this type of testing and lessons learned.

Montanez, Leticia

Real-time microcomputer simulation for space Shuttle/Centaur avionics

The design of a simulator system for emulating the characteristics of Shuttle/Centaur avionic support equipment for launching the Solar Polar Mission and the Galileo probe are discussed. The simulators are being constructed on a modular basis for the Centaur control avionics, the Centaur Airborne Support Equipment avionics, the tanking skid ground support equipment, development mechanisms, the tanking skid ground support equipment, deployment mechanisms, the tanking onboard fluid functions, the star scanner guidance update avionics, the Orbiter command interface avionics, and the Orbiter power system. Each simulator portrays the actual working conditions, including signal delay times and harnessing. Block diagrams are provided of the interfaces and a flow diagram is presented of the software.

Szatkowski, G. P.

Interface Supports Lightweight Subsystem Routing for Flight Applications

A wireless avionics interface exploits the constrained nature of data networks in flight systems to use a lightweight routing method. This simplified routing means that a processor is not required, and the logic can be implemented as an intellectual property (IP) core in a field-programmable gate array (FPGA). The FPGA can be shared with the flight subsystem application. In addition, the router is aware of redundant subsystems, and can be configured to provide hot standby support as part of the interface. This simplifies implementation of flight applications requiring hot stand - by support. When a valid inbound packet is received from the network, the destination node address is inspected to determine whether the packet is to be processed by this node. Each node has routing tables for the next neighbor node to guide the packet to the destination node. If it is to be processed, the final packet destination is inspected to determine whether the packet is to be forwarded to another node, or routed locally. If the packet is local, it is sent to an Applications Data Interface (ADI), which is attached to a local flight application. Under this scheme, an interface can support many applications in a subsystem supporting a high level of subsystem integration. If the packet is to be forwarded to another node, it is sent to the outbound packet router. The outbound packet router receives packets from an ADI or a packet to be forwarded. It then uses a lookup table to determine the next destination for the packet. Upon detecting a remote subsystem failure, the routing table can be updated to autonomously bypass the failed subsystem.

Lux, James P.

Interface Supports Multiple Broadcast Transceivers for Flight Applications

A wireless avionics interface provides a mechanism for managing multiple broadcast transceivers. This interface isolates the control logic required to support multiple transceivers so that the flight application does not have to manage wireless transceivers. All of the logic to select transceivers, detect transmitter and receiver faults, and take autonomous recovery action is contained in the interface, which is not restricted to using wireless transceivers. Wired, wireless, and mixed transceiver technologies are supported. This design s use of broadcast data technology provides inherent cross strapping of data links. This greatly simplifies the design of redundant flight subsystems. The interface fully exploits the broadcast data link to determine the health of other transceivers used to detect and isolate faults for fault recovery. The interface uses simplified control logic, which can be implemented as an intellectual-property (IP) core in a field-programmable gate array (FPGA). The interface arbitrates the reception of inbound data traffic appearing on multiple receivers. It arbitrates the transmission of outbound traffic. This system also monitors broadcast data traffic to determine the health of transmitters in the network, and then uses this health information to make autonomous decisions for routing traffic through transceivers. Multiple selection strategies are supported, like having an active transceiver with the secondary transceiver powered off except to send periodic health status reports. Transceivers can operate in round-robin for load-sharing and graceful degradation.

Block, Gary L.

Orbital Spacecraft Consumables Resupply System (OSCRS): Monopropellant application to space station and OMV automatic refueling impacts of an ELV launch, volume 4

The use of orbital spacecraft consumables resupply system (OSCRS) at the Space Station is investigated, its use with the orbital maneuvering vehicle, and launch of the OSCRS on an expendable launch vehicles. A system requirements evaluation was performed initially to identify any unique requirements that would impact the design of OSCRS when used at the Space Station. Space Station documents were reviewed to establish requirements and to identify interfaces between the OSCRS, Shuttle, and Space Station, especially the Servicing Facility. The interfaces between OSCRS and the Shuttle consists of an avionics interface for command and control and a structural interface for launch support and for grappling with the Shuttle Remote Manipulator System. For use of the OSCRS at the Space Station, three configurations were evaluated using the results of the interface definition to increase the efficiency of OSCRS and to decrease the launch weight by Station-basing specific OSCRS subsystems. A modular OSCRS was developed in which the major subsystems were Station-based where possible. The configuration of an OSCRS was defined for transport of water to the Space Station.

Source record

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.

Launch Control Network Engineer

The Spaceport Command and Control System (SCCS) is being built at the Kennedy Space Center in order to successfully launch NASA’s revolutionary vehicle that allows humans to explore further into space than ever before. During my internship, I worked with the Network, Firewall, and Hardware teams that are all contributing to the huge SCCS network project effort. I learned the SCCS network design and the several concepts that are running in the background. I also updated and designed documentation for physical networks that are part of SCCS. This includes being able to assist and build physical installations as well as configurations. I worked with the network design for vehicle telemetry interfaces to the Launch Control System (LCS); this allows the interface to interact with other systems at other NASA locations. This network design includes the Space Launch System (SLS), Interim Cryogenic Propulsion Stage (ICPS), and the Orion Multipurpose Crew Vehicle (MPCV). I worked on the network design and implementation in the Customer Avionics Interface Development and Analysis (CAIDA) lab.

Medeiros, Samantha

Avionics electromagnetic interference immunity and environment

Aircraft electromagnetic spectrum and radio frequency (RF) field strengths are charted, profiling the higher levels of electromagnetic voltages encountered by the commercial aircraft wiring. Selected military, urban, and rural electromagnetic field levels are plotted and provide a comparison of radiation amplitudes. Low frequency magnetic fields and electric fields from 400 H(Z) power systems are charted versus frequency and wire separation to indicate induced voltages on adjacent or neighboring circuits. Induced EMI levels and attenuation characteristics of electric, magnetic, RF fields, and transients are plotted and graphed for common types of wire circuits. The significance of wire circuit returns and shielding is emphasized to highlight the techniques that help block the paths of electromagnetic interference and maintain avionic interface signal quality.

Clarke, C. A.

The NASA Spacecraft Transponding Modem

A new deep space transponder is being developed by the Jet Propulsion Laboratory for NASA. The Spacecraft Transponding Modem (STM) implements the standard transponder functions and the channel service functions that have previously resided in spacecraft Command/Data Subsystems. The STM uses custom ASICs, MMICs, and MCMs to reduce the active device parts count to 70, mass to I kg, and volume to 524 cc. The first STMs will be flown on missions launching in the 2003 time frame. The STM tracks an X-band uplink signal and provides both X-band and Ka-band downlinks, either coherent or non-coherent with the uplink. A NASA standard Command Detector Unit is integrated into the STM, along with a codeblock processor and a hardware command decoder. The decoded command codeblocks are output to the spacecraft command/data subsystem. Virtual Channel 0 (VC-0) (hardware) commands are processed and output as critical controller (CRC) commands. Downlink telemetry is received from the spacecraft data subsystem as telemetry frames. The STM provides the following downlink coding options: the standard CCSDS (7-1/2) convolutional coding, ReedSolomon coding with interleave depths one and five, (15-1/6) convolutional coding, and Turbo coding with rates 1/3 and 1/6. The downlink symbol rates can be linearly ramped to match the G/T curve of the receiving station, providing up to a 1 dB increase in data return. Data rates range from 5 bits per second (bps) to 24 Mbps, with three modulation modes provided: modulated subcarrier (3 different frequencies provided), biphase-L modulated direct on carrier, and Offset QPSK. Also, the capability to generate one of four non-harmonically related telemetry beacon tones is provided, to allow for a simple spacecraft status monitoring scheme for cruise phases of missions. Three ranging modes are provided: standard turn around ranging, regenerative pseudo-noise (PN) ranging, and Differential One-way Ranging (DOR) tones. The regenerative ranging provides the capability of increasing the ground received ranging SNR by up to 30 dB. Two different avionics interfaces to the command/data subsystem's data bus are provided: a MIL STD 1553B bus or an industry standard PCI interface. Digital interfaces provide the capability to control antenna selection (e.g., switching between high gain and low gain antennas) and antenna pointing (for future steered Ka-band antennas).

Berner, Jeff B.