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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 91 records · Page 5

All sources NASA NTRS DOE OSTI

NASA NTRS1991

Requirements analysis notebook for the flight data systems definition in the Real-Time Systems Engineering Laboratory (RSEL)

A hybrid requirements analysis methodology was developed, based on the practices actually used in developing a Space Generic Open Avionics Architecture. During the development of this avionics architecture, a method of analysis able to effectively define the requirements for this space avionics architecture was developed. In this methodology, external interfaces and relationships are defined, a static analysis resulting in a static avionics model was developed, operating concepts for simulating the requirements were put together, and a dynamic analysis of the execution needs for the dynamic model operation was planned. The systems engineering approach was used to perform a top down modified structured analysis of a generic space avionics system and to convert actual program results into generic requirements. CASE tools were used to model the analyzed system and automatically generate specifications describing the model's requirements. Lessons learned in the use of CASE tools, the architecture, and the design of the Space Generic Avionics model were established, and a methodology notebook was prepared for NASA. The weaknesses of standard real-time methodologies for practicing systems engineering, such as Structured Analysis and Object Oriented Analysis, were identified.

Wray, Richard B.↗

NASA NTRSDate not supplied

MUSTANG: A Workhorse for NASA Spaceflight Avionics

The Modular Unified Space Technology Avionics for Next Generation (MUSTANG) is a small integrated Avionics system including Command and Data Handling (C&DH), Power System Electronics (PSE), Attitude Control System Interfaces (ACS), and Propulsion Electronics. The MUSTANG Avionics Architecture is built upon many years of knowledge capture and lessons learned at the Goddard Space Flight Center. With a motivation towards modularity and keeping board redesign costs to a minimum, MUSTANG offers flexibility in features with a backplane-less design and allows the user to choose the options (cards) needed for their system. It incorporates a distributed power system that provides secondary power to all its subcomponents reducing the number of primary services needed for an Avionics. MUSTANG can be integrated into one system or divided into several smaller components. MUSTANG supports redundancy and cross-strap ability for a more robust and reliable Avionics system. A variation of MUSTANG exists for Instrument Electronics called iMUSTANG and allows the user to select functionality applicable to the instrument electronics. MUSTANG is not meant to replace Avionics for all spacecraft. There are limitations due to its relatively compact size, but the MUSTANG design has proven broadly applicable on many spacecraft and instrument bus avionics architectures.

MUSTANG↗

NASA NTRS1985

Integrated flight/propulsion control - Adaptive engine control system mode

The adaptive engine control system mode (ADECS) which is developed and tested on an F-15 aircraft with PW1128 engines, using the NASA sponsored highly integrated digital electronic control program, is examined. The operation of the ADECS mode, as well as the basic control logic, the avionic architecture, and the airframe/engine interface are described. By increasing engine pressure ratio (EPR) additional thrust is obtained at intermediate power and above. To modulate the amount of EPR uptrim and to prevent engine stall, information from the flight control system is used. The performance benefits, anticipated from control integration are shown for a range of flight conditions and power settings. It is found that at higher altitudes, the ADECS mode can increase thrust as much as 12 percent, which is used for improved acceleration, improved turn rate, or sustained turn angle.

Yonke, W. A.↗

NASA NTRS2019

Medical Data Architecture (MDA) Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.In fiscal year 2018, the MDA project developed Test Bed 2, the second iteration in a series of prototypes with functionality focused on data security through role-based access control and encryption, integration with One Portal exercise software and ingestion of an ultrasound Digital Imaging and Communications in Medicine (DICOM) file and image display. Test Bed 2 advances the medical data system architecture framework by providing these functionalities in a scalable system that maintained a layered, modular design. The architecture framework uses a data services approach with role-based access to data in a customized medical record system suitable for space exploration. These functionalities were demonstrated as part of the Next Space Technologies for Exploration Partnerships (NextSTEP) ground test demonstrated at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Interfacing to a Core Flight Software (CFS) system, the MDA system, using Consultative Committee for Space Data Systems (CCSDS) protocol, transferred an exercise file from the simulated flight MDA system to a mirrored MDA system on the ground through the CFS system. The selection of data sources and demonstrations enabled the team to address stakeholder concerns throughout the development process. In the next iteration, the MDA team will work with stakeholders to identify additional relevant functionalities to further advance system data models, standards and principles that will inform the medical system requirements development.

medical data architecture↗

NASA NTRSDate not supplied

Eleven Countries, an Integrated Spacecraft: the Story of International Collaboration that Built the Orion Spacecraft and Powered the Success of the Artemis I Mission

The quest to return humans to the Moon in the next step towards humanity's exploration of space is more alive than ever. After a great deal of achievements, failures, and lessons learned, the Artemis I mission set o to the Moon on November 16, 2022, with the goal of testing a new rocket, the Space Launch System, and a new spacecraft, Orion: designed, assembled, and tested across two continents, and 11 countries. Behind this mission, decades of experience with the International Space Station, Autonomous Transfer Vehicle operations, and many other program collaborations built the know-how on how to succeed together in the toughest environment | deep space. The Artemis I mission proved to be an incredible success, meeting 161 total mission objectives, including 21 developed during the flight based on outperforming spacecraft. It was also a case-study in international collaboration, given that ESA, NASA, and industry partners Airbus and Lockheed Martin for the first time had to design, build, test, and fly a fully integrated human-rated spacecraft, with most critical functions dependent and interconnected across U.S. and European systems. The U.S.-built Orion Crew Module and Crew Module Adapter and European-built European Service Module (ESM) shared critical interfaces and commodities, from propulsion, avionics, active/passive thermal, electrical power generation, storage and distribution to the software that managed it all. In this paper, we will describe relevant aspects of the integrated spacecraft design, providing context for the challenges that the team faced in all phases required to get Orion ready to fly, and provide a direct account of how the joint team formed, trained, and supported the operations of the successful Artemis I mission. We will also explore the evolution of the partnerships, given that these allow a multi-national e ort to sustain the program production, share costs, leverage a broader base of engineering expertise, and build more diverse capabilities over the long haul to support the Artemis goals and objectives. Lastly, we will cover critical lessons learned and how the Orion Program has implemented these in preparation of the next Artemis missions to repeat the success of Artemis I. The purpose of this paper is to document knowledge we gained and lessons we learned through the development of an integrated Orion spacecraft, since it is imperative we build on this now, at the dawn of the Artemis Program, an international endeavor to push human space exploration.

Deep Space Exploration↗

NASA NTRS2016

Deploying a Route Optimization EFB Application for Commercial Airline Operational Trials

The Traffic Aware Planner (TAP), developed for NASA Langley Research Center to support the Traffic Aware Strategic Aircrew Requests (TASAR) project, is a flight-efficiency software application developed for an Electronic Flight Bag (EFB). Tested in two flight trials and planned for operational testing by two commercial airlines, TAP is a real-time trajectory optimization application that leverages connectivity with onboard avionics and broadband Internet sources to compute and recommend route modifications to flight crews to improve fuel and time performance. The application utilizes a wide range of data, including Automatic Dependent Surveillance Broadcast (ADS-B) traffic, Flight Management System (FMS) guidance and intent, on-board sensors, published winds and weather, and Special Use Airspace (SUA) schedules. This paper discusses the challenges of developing and deploying TAP to various EFB platforms, our solutions to some of these challenges, and lessons learned, to assist commercial software developers and hardware manufacturers in their efforts to implement and extend TAP functionality in their environments. EFB applications (such as TAP) typically access avionics data via an ARINC 834 Simple Text Avionics Protocol (STAP) server hosted by an Aircraft Interface Device (AID) or other installed hardware. While the protocol is standardized, the data sources, content, and transmission rates can vary from aircraft to aircraft. Additionally, the method of communicating with the AID may vary depending on EFB hardware and/or the availability of onboard networking services, such as Ethernet, WIFI, Bluetooth, or other mechanisms. EFBs with portable and installed components can be implemented using a variety of operating systems, and cockpits are increasingly incorporating tablet-based technologies, further expanding the number of platforms the application may need to support. Supporting multiple EFB platforms, AIDs, avionics datasets, and user interfaces presents a challenge for software developers and the management of their code baselines. Maintaining multiple baselines to support all deployment targets can be extremely cumbersome and expensive. Certification also needs to be considered when developing the application. Regardless of whether the software is itself destined to be certified, data requirements in support of the application and user interface elements may introduce certification requirements for EFB manufacturers and the airlines. The example of TAP, the challenges faced, solutions implemented, and lessons learned will give EFB application and hardware developers insight into future potential requirements in deploying TAP or similar flight-deck EFB applications.

Roscoe, David A.↗

NASA NTRS1994

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.↗

NASA NTRS1990

Advanced software integration: The case for ITV facilities

The array of technologies and methodologies involved in the development and integration of avionics software has moved almost as rapidly as computer technology itself. Future avionics systems involve major advances and risks in the following areas: (1) Complexity; (2) Connectivity; (3) Security; (4) Duration; and (5) Software engineering. From an architectural standpoint, the systems will be much more distributed, involve session-based user interfaces, and have the layered architectures typified in the layers of abstraction concepts popular in networking. Typified in the NASA Space Station Freedom will be the highly distributed nature of software development itself. Systems composed of independent components developed in parallel must be bound by rigid standards and interfaces, the clean requirements and specifications. Avionics software provides a challenge in that it can not be flight tested until the first time it literally flies. It is the binding of requirements for such an integration environment into the advances and risks of future avionics systems that form the basis of the presented concept and the basic Integration, Test, and Verification concept within the development and integration life cycle of Space Station Mission and Avionics systems.

Garman, John R.↗

NASA NTRS1993

Digital avionics systems - Principles and practices (2nd revised and enlarged edition)

The state of the art in digital avionics systems is surveyed. The general topics addressed include: establishing avionics system requirements; avionics systems essentials in data bases, crew interfaces, and power; fault tolerance, maintainability, and reliability; architectures; packaging and fitting the system into the aircraft; hardware assessment and validation; software design, assessment, and validation; determining the costs of avionics.

Spitzer, Cary R.↗

NASA NTRS2011

NASA Tech Briefs, December 2011

Topics covered include: 1) SNE Industrial Fieldbus Interface; 2) Composite Thermal Switch; 3) XMOS XC-2 Development Board for Mechanical Control and Data Collection; 4) Receiver Gain Modulation Circuit; 5) NEXUS Scalable and Distributed Next-Generation Avionics Bus for Space Missions; 6) Digital Interface Board to Control Phase and Amplitude of Four Channels; 7) CoNNeCT Baseband Processor Module; 8) Cryogenic 160-GHz MMIC Heterodyne Receiver Module; 9) Ka-Band, Multi-Gigabit-Per-Second Transceiver; 10) All-Solid-State 2.45-to-2.78-THz Source; 11) Onboard Interferometric SAR Processor for the Ka-Band Radar Interferometer (KaRIn); 12) Space Environments Testbed; 13) High-Performance 3D Articulated Robot Display; 14) Athena; 15) In Situ Surface Characterization; 16) Ndarts; 17) Cryo-Etched Black Silicon for Use as Optical Black; 18) Advanced CO2 Removal and Reduction System; 19) Correcting Thermal Deformations in an Active Composite Reflector; 20) Umbilical Deployment Device; 21) Space Mirror Alignment System; 22) Thermionic Power Cell To Harness Heat Energies for Geothermal Applications; 23) Graph Theory Roots of Spatial Operators for Kinematics and Dynamics; 24) Spacesuit Soft Upper Torso Sizing Systems; 25) Radiation Protection Using Single-Wall Carbon Nanotube Derivatives; 26) PMA-PhyloChip DNA Microarray to Elucidate Viable Microbial Community Structure; 27) Lidar Luminance Quantizer; 28) Distributed Capacitive Sensor for Sample Mass Measurement; 29) Base Flow Model Validation; 30) Minimum Landing Error Powered-Descent Guidance for Planetary Missions; 31) Framework for Integrating Science Data Processing Algorithms Into Process Control Systems; 32) Time Synchronization and Distribution Mechanisms for Space Networks; 33) Local Estimators for Spacecraft Formation Flying; 34) Software-Defined Radio for Space-to-Space Communications; 35) Reflective Occultation Mask for Evaluation of Occulter Designs for Planet Finding; and 36) Molecular Adsorber Coating

Source record↗

NASA NTRS2017

Implementation of Real-Time Hardware in the Loop Simulation for WAVE Instrument Avionics

The Regolith and Environment Science and Oxygen and Lunar Volatile Extraction (RESOLVE) payload will lead the Resource Prospector rover to hydrogen-rich locations on the moon supporting NASA's in-situ resource utilization (ISRU) mission. The Water Analysis and Volatile Extraction (WAVE) system will be responsible for heating up regolith samples and analyzing their volatiles in a vaporized state. Given the space environment, testing flight hardware and software using the scientific instruments can be costly and time consuming, which can hold back progress involving the instruments. A hardware-in-the-loop (HITL) simulation will test the Avionics Data Acquisition as well as the Instrument Interface Unit, through simulating sensors and actuators involved in supporting the WAVE instruments. HITL is a platform for testing and developing WAVE's avionics and software, where the simulation plant will imitate the LAVA and OVEN instruments, thus allowing for an accessible, efficient, and replicable testing environment.

Al Qaraghuli, Ali↗

NASA NTRS1984

Man-machine interface requirements - advanced technology

Research issues and areas are identified where increased understanding of the human operator and the interaction between the operator and the avionics could lead to improvements in the performance of current and proposed helicopters. Both current and advanced helicopter systems and avionics are considered. Areas critical to man-machine interface requirements include: (1) artificial intelligence; (2) visual displays; (3) voice technology; (4) cockpit integration; and (5) pilot work loads and performance.

Remington, R. W.↗

NASA NTRS2009

Modification of the International Space Station USOS to Support Installation and Activation of the Node 3 Element

The International Space Station (ISS) program is nearing an assembly complete configuration with the addition of the final resource node module in early 2010. The Node 3 module will provide critical functionality in support of permanent long duration crews aboard ISS. The new module will permanently house the regenerative Environment Control and Life Support Systems (ECLSS) and will also provide important habitability functions such as waste management and exercise facilities. The ISS program has selected the Port side of the Node 1 "Unity" module as the permanent location for Node 3 which will necessitate architecture changes to provide the required interfaces. The USOS ECLSS fluid and ventilation systems, Internal Thermal Control Systems, and Avionics Systems require significant modifications in order to support Node 3 interfaces at the Node 1 Port location since it was not initially designed for that configuration. This paper outlines the design, development, certification, and implementation of these changes in support of ISS assembly complete.

Link, Dwight E., Jr.↗

NASA NTRS1987

Orbital fluid servicing and resupply operations

The capability to reservice spacecraft and satellites with expendable fluids will provide significant increases in the usability, operational efficiency and cost effectiveness of in-space systems. Initial resupply will be accomplished from the Orbiter cargo bay starting with monopropellant servicing which will eventually be extended to servicing of bipropellants and pressurants. Other fluids, such as freon, ammonia, methanol, superfluid helium, and liquid/gaseous nitrogen may also need to be resupplied once a space station becomes a reality. These fluids/gases are required for subsystem working fluid replacement and payload/experiment fluid replenishment. A logistics module operating on a 90 day schedule is planned for space station servicing. Resupplying hundreds of thousands of pounds of cryogenic propellants and reactants for users such as the Orbital Transfer Vehicle (OTV) also represents future logistics challenges. Implementation of on-orbit fluid transfer requires solving many problems including fluid management in the low-g environment, system docking and interface mating, configuration of user friendly avionics to monitor and control the entire servicing operation, and minimized maintenance and enhanced reliability. Candidate fluid transfer methods and possible gas transfer methods are discussed, and preliminary storable monopropellant and bipropellant tanker designs are summarized.

Eberhardt, R. N.↗

NASA NTRS1992

Hitchhiker: Customer Accommodations and Requirements Specifications (CARS)

In 1984, NASA Headquarters established projects at the Goddard Space Flight Center (GSFC) and the Marshall Space Flight Center (MSFC) to develop quick-reaction carrier systems for low-cost 'flight of opportunity' or secondary payloads on the Space Transportation System (STS). One of these projects is the Hitchhiker (HH) Program. GSFC has developed a family of carrier equipment known as the Shuttle Payload of Opportunity Carrier (SPOC) system for mounting small payloads such as HH to the side of the Orbiter payload bay. The side-mounted HHs are referred to as Hitchhiker-G (HH-G). MSFC developed a cross-bay 'bridge-type' carrier structure called the Hitchhiker-M (HH-M). In 1987, responsibility for the HH-M carrier was transferred to and is now managed by the HH Project Office at the GSFC. The HH-M carrier now uses the same interchangeable SPOC avionics unit and the same electrical interfaces and services developed for HH-G. National Aeronautics and Space Administration (NASA) has created this document to acquaint potential HH system customers with the facilities NASA provides and the requirements which customers must satisfy to use these facilities. This publication defines interface items required for integrating customer equipment with the HH carrier system. Those items such as mounting equipment and electrical inputs and outputs; configuration, environmental, command, telemetry, and operational constraints are described as well as weight, power, and communications. The purpose of this publication is to help the customer understand essential integration documentation requirements and to prepare a Customer Payload Requirements (CPR) document.

Source record↗

NASA NTRS2014

Force Limiting Vibration Tests Evaluated from both Ground Acoustic Tests and FEM Simulations of a Flight Like Vehicle System Assembly

Marshall Space Flight Center has conducted a series of ground acoustic tests with the dual goals of informing analytical judgment, and validating analytical methods when estimating vibroacoustic responses of launch vehicle subsystems. The process of repeatedly correlating finite element-simulated responses with test-measured responses has assisted in the development of best practices for modeling and post-processing. In recent work, force transducers were integrated to measure interface forces at the base of avionics box equipment. Other force data was indirectly measured using strain gauges. The combination of these direct and indirect force measurements has been used to support and illustrate the advantages of implementing the Force Limiting approach for equipment qualification tests. The comparison of force response from integrated system level tests to measurements at the same locations during component level vibration tests provides an excellent illustration. A second comparison of the measured response cases from the system level acoustic tests to finite element simulations has also produced some principles for assessing the suitability of Finite Element Models (FEMs) for making vibroacoustics estimates. The results indicate that when FEM models are employed to guide force limiting choices, they should include sufficient detail to represent the apparent mass of the system in the frequency range of interest.

Smith, Andrew↗

NASA NTRS1983

Flight evaluation results from the general-aviation advanced avionics system program

A demonstration advanced avionics system (DAAS) for general-aviation aircraft was tested at NASA Ames Research Center to provide information required for the design of reliable, low-cost, advanced avionics systems which would make general-aviation operations safer and more practicable. Guest pilots flew a DAAS-equipped NASA Cessna 402-B aircraft to evaluate the usefulness of data busing, distributed microprocessors, and shared electronic displays, and to provide data on the DAAS pilot/system interface for the design of future integrated avionics systems. Evaluation results indicate that the DAAS hardware and functional capability meet the program objective. Most pilots felt that the DAAS representative of the way avionics systems would evolve and felt the added capability would improve the safety and practicability of general-aviation operations. Flight-evaluation results compiled from questionnaires are presented, the results of the debriefings are summarized. General conclusions of the flight evaluation are included.

Callas, G. P.↗

NASA NTRS1983

Flight evaluation results from the general-aviation advanced avionics system program

Callas, G. P.↗