Search NASA⌕ Search

SEARCH · Search NASA

Results for “Avionics Requirements and ARchitecture”

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 73 records · Page 4

X-57 Cockpit Interface Control Document (ICD-CEPT-006)

The Cockpit Interface Control Document defines the hardware interfaces between the X-57 cockpit and subsystems. It provides locational and operational information in support of ground and flight operations with details on controls and displays that include Modes of Operation, Start-Up and Shut- Down Sequence diagrams and captures the current state of the MOD II Avionics Power Architecture. There is also preliminary information of the MOD III and MOD IV configurations. Microsoft PowerPoint was chosen for the document as early development required frequent meetings with multiple customers including aircraft operators (pilots), ground operations, support contractors and power, instrumentation, and human systems integration engineers and PowerPoint enabled presentations that could be quickly modified based on customer and developer interaction. One of the driving requirements for the cockpit design was to keep the left side panel as close the stock Tecnam panel as possible to reduce the failure risk of flight critical indicators. The original annunciator panel in the left side panel was modified to alert the pilot to failures in critical X-57 subsystems and an operator audio alert capability was added for these subsystems. Power-Up switches for the aircraft low voltage 13.8 VDC systems are located at the bottom of the left side panel and center panel, the same location as the stock Tecnam 13.8 VDC switches. The switches for energizing the high voltage system were located in the overhead panel to reduce the risk of inadvertently energizing the high voltage system during the low voltage power-up sequence. The Cruise Motor ARM switches were also located in the overhead panel and correspond to the same location as the stock Tecnam ignition switches. The stock Tecnam throttle levers and prop pitch levers were retained for the X-57. The throttle levers were renamed torque levers since they controlled the commanded torque to the cruise motors. The prop pitch levers provide a commanded RPM signal to an electronic prop pitch controller. X-57 specific displays, located in the right-side panel, are driven by dedicated sensors that monitor right and left side cruise motor RPM, right and left high voltage “Traction Bus” A and B (voltage, current and power) and the Avionics Bus DC converters (A and B) voltage and current. An X-57 Multi-Function Display (MFD) located in the center panel displays CAN Bus parameters. CAN Bus architecture is not certified for flight so these displays could not be used for safety critical information but were designed to be used for test point information only.

Laura Kushner↗

Integrated Avionics System (IAS), Integrating 3-D Technology On A Spacecraft Panel

As spacecraft designs converge toward miniaturization, and with the volumetric and mass challenges placed on avionics, programs will continue to advance the "state of the art" in spacecraft system development with new challenges to reduce power, mass and volume. Traditionally, the trend is to focus on high-density 3-D packaging technologies. Industry has made significant progress in 3-D technologies, and other related internal and external interconnection schemes. Although new technologies have improved packaging densities, a system packaging architecture is required that not only reduces spacecraft volume and mass budgets, but increase integration efficiencies, provide modularity and flexibility to accommodate multiple missions while maintaining a low recurring cost. With these challenges in mind, a novel system packaging approach incorporates solutions that provide broader environmental applications, more flexible system interconnectivity, scalability, and simplified assembly test and integration schemes. The Integrated Avionics System (IAS) provides for a low-mass, modular distributed or centralized packaging architecture which combines ridged-flex technologies, high-density COTS hardware and a new 3-D mechanical packaging approach, Horizontal Mounted Cube (HMC). This paper will describe the fundamental elements of the IAS, HMC hardware design, system integration and environmental test results.

Hunter, Don J.↗

Advancing the practice of systems engineering at JPL

In FY 2004, JPL launched an initiative to improve the way it practices systems engineering. The Lab's senior management formed the Systems Engineering Advancement (SEA) Project in order to "significantly advance the practice and organizational capabilities of systems engineering at JPL on flight projects and ground support tasks." The scope of the SEA Project includes the systems engineering work performed in all three dimensions of a program, project, or task: 1. the full life-cycle, i.e., concept through end of operations 2. the full depth, i.e., Program, Project, System, Subsystem, Element (SE Levels 1 to 5) 3. the full technical scope, e.g., the flight, ground and launch systems, avionics, power, propulsion, telecommunications, thermal, etc. The initial focus of their efforts defined the following basic systems engineering functions at JPL: systems architecture, requirements management, interface definition, technical resource management, system design and analysis, system verification and validation, risk management, technical peer reviews, design process management and systems engineering task management, They also developed a list of highly valued personal behaviors of systems engineers, and are working to inculcate those behaviors into members of their systems engineering community. The SEA Project is developing products, services, and training to support managers and practitioners throughout the entire system lifecycle. As these are developed, each one needs to be systematically deployed. Hence, the SEA Project developed a deployment process that includes four aspects: infrastructure and operations, communication and outreach, education and training, and consulting support. In addition, the SEA Project has taken a proactive approach to organizational change management and customer relationship management - both concepts and approaches not usually invoked in an engineering environment. This paper'3 describes JPL's approach to advancing the practice of systems engineering at the Lab. It describes the general approach used and how they addressed the three key aspects of change: people, process and technology. It highlights a list of highly valued personal behaviors of systems engineers, discusses the various products, services and training that were developed, describes the deployment approach used, and concludes with several lessons learned.

process improvement↗

Integrated Avionics System (IAS)

As spacecraft designs converge toward miniaturization and with the volumetric and mass constraints placed on avionics, programs will continue to advance the 'state of the art' in spacecraft systems development with new challenges to reduce power, mass, and volume. Although new technologies have improved packaging densities, a total system packaging architecture is required that not only reduces spacecraft volume and mass budgets, but increase integration efficiencies, provide modularity and scalability to accommodate multiple missions. With these challenges in mind, a novel packaging approach incorporates solutions that provide broader environmental applications, more flexible system interconnectivity, scalability, and simplified assembly test and integration schemes. This paper will describe the fundamental elements of the Integrated Avionics System (IAS), Horizontally Mounted Cube (HMC) hardware design, system and environmental test results. Additional information is contained in the original extended abstract.

Hunter, D. J.↗

Design implications from AFTI/F-16 flight test

Advanced fighter technologies are evolving into highly complex systems. Flight controls are being integrated with advanced avionics to achieve a total system. The advanced fighter technology integration (AFTI) F-16 aircraft is an example of a highly complex digital flight control system integrated with advanced avionics and cockpit. The architecture of these new systems involves several general issues. The use of dissimilar backup modes if the primary system fails requires the designer to trade off system simplicity and capability. This tradeoff is evident in the AFTI/F-16 aircraft with its limited stability and fly-by-wire digital flight control systems. In case of a generic software failure, the backup or normal mode must provide equivalent envelope protection during the transition to degraded flight control. The complexity of systems like the AFTI/F-16 system defines a second design issue, which can be divided into two segments: the effect on testing, and the pilot's ability to act correctly in the limited time available for cockpit decisions. The large matrix of states possible with the AFTI/F-16 flight control system illustrates the difficulty of both testing the system and choosing real-time pilot actions.

Ishmael, S. D.↗

Ethernet for Aerospace Applications - Ethernet Heads for the Skies

One of the goals of aerospace applications is to reduce the cost and complexity of avionic systems. Ethernet is a highly scalable, flexible, and popular protocol. The aerospace market is large, with a forecasted production of over 50,000 turbine-powered aircraft valued at $1.7 trillion between 2012 and 2022. Boeing estimates demand for commercial aircraft by 2033 to total over 36,000 with a value of over $5 trillion. In 2014 US airlines served over 750 million passengers and this is growing over 2% yearly. Electronic fly-by-wire is now used for all airliners and high performance aircraft. Although Ethernet has been widely used for four decades, its use in aerospace applications is just beginning to become common. Ethernet is the universal solution in commercial networks because of its high bandwidths, lower cost, openness, reliability, maintainability, flexibility, and interoperability. However, when Ethernet was designed applications with time-critical, safety relevant and deterministic requirements were not given much consideration. Many aerospace applications use a variety of communication architectures that add cost and complexity. Some of them are SpaceWire, MIL-STD-1553, Avionics Full Duplex Switched Ethernet (AFDX), and Time-Triggered Ethernet (TTE). Aerospace network designers desire to decrease the number of networks to reduce cost and effort while improving scalability, flexibility, openness, maintainability, and reliability. AFDX and TTE are being considered more for critical aerospace systems because they provide redundancy, failover protection, guaranteed timing, and frame priority and are based on Ethernet IEEE 802.3. This paper explores the use of AFDX and TTE for aerospace applications.

Ethernet↗

Determination of an Optimal Commercial Data Bus Architecture for a Flight Data System

NASA/Marshall Space Flight Center (MSFC) is continually looking for methods to reduce cost and schedule while keeping the quality of work high. MSFC is NASA's lead center for space transportation and microgravity research. When supporting NASA's programs several decisions concerning the avionics system must be made. Usually many trade studies must be conducted to determine the best ways to meet the customer's requirements. When deciding the flight data system, one of the first trade studies normally conducted is the determination of the data bus architecture. The schedule, cost, reliability, and environments are some of the factors that are reviewed in the determination of the data bus architecture. Based on the studies, the data bus architecture could result in a proprietary data bus or a commercial data bus. The cost factor usually removes the proprietary data bus from consideration. The commercial data bus's range from Versa Module Eurocard (VME) to Compact PCI to STD 32 to PC 104. If cost, schedule and size are prime factors, VME is usually not considered. If the prime factors are cost, schedule, and size then Compact PCI, STD 32 and PC104 are the choices for the data bus architecture. MSFC's center director has funded a study from his discretionary fund to determine an optimal low cost commercial data bus architecture. The goal of the study is to functionally and environmentally test Compact PCI, STD 32 and PC 104 data bus architectures. This paper will summarize the results of the data bus architecture study.

Crawford, Kevin↗

Real-Time Simulation of Ares I Launch Vehicle

The Ares Real-Time Environment for Modeling, Integration, and Simulation (ARTEMIS) has been developed for use by the Ares I launch vehicle System Integration Laboratory (SIL) at the Marshall Space Flight Center (MSFC). The primary purpose of the Ares SIL is to test the vehicle avionics hardware and software in a hardware-in-the-loop (HWIL) environment to certify that the integrated system is prepared for flight. ARTEMIS has been designed to be the real-time software backbone to stimulate all required Ares components through high-fidelity simulation. ARTEMIS has been designed to take full advantage of the advances in underlying computational power now available to support HWIL testing. A modular real-time design relying on a fully distributed computing architecture has been achieved. Two fundamental requirements drove ARTEMIS to pursue the use of high-fidelity simulation models in a real-time environment. First, ARTEMIS must be used to test a man-rated integrated avionics hardware and software system, thus requiring a wide variety of nominal and off-nominal simulation capabilities to certify system robustness. The second driving requirement - derived from a nationwide review of current state-of-the-art HWIL facilities - was that preserving digital model fidelity significantly reduced overall vehicle lifecycle cost by reducing testing time for certification runs and increasing flight tempo through an expanded operational envelope. These two driving requirements necessitated the use of high-fidelity models throughout the ARTEMIS simulation. The nature of the Ares mission profile imposed a variety of additional requirements on the ARTEMIS simulation. The Ares I vehicle is composed of multiple elements, including the First Stage Solid Rocket Booster (SRB), the Upper Stage powered by the J- 2X engine, the Orion Crew Exploration Vehicle (CEV) which houses the crew, the Launch Abort System (LAS), and various secondary elements that separate from the vehicle. At launch, the integrated vehicle stack is composed of these stages, and throughout the mission, various elements separate from the integrated stack and tumble back towards the earth. ARTEMIS must be capable of simulating the integrated stack through the flight as well as propagating each individual element after separation. In addition, abort sequences can lead to other unique configurations of the integrated stack as the timing and sequence of the stage separations are altered.

Tobbe, Patrick↗

Rotorcraft digital advanced avionics system (RODAAS) functional description

A functional design of a rotorcraft digital advanced avionics system (RODAAS) to transfer the technology developed for general aviation in the Demonstration Advanced Avionics System (DAAS) program to rotorcraft operation was undertaken. The objective was to develop an integrated avionics system design that enhances rotorcraft single pilot IFR operations without increasing the required pilot training/experience by exploiting advanced technology in computers, busing, displays and integrated systems design. A key element of the avionics system is the functionally distributed architecture that has the potential for high reliability with low weight, power and cost. A functional description of the RODAAS hardware and software functions is presented.

Peterson, E. M.↗

Cyber Safety and Security for Reduced Crew Operations (RCO)

NASA and the Aviation Industry is looking into reduced crew operations (RCO) that would cut today's required two-person flight crews down to a single pilot with support from ground-based crews. Shared responsibility across air and ground personnel will require highly reliable and secure data communication and supporting automation, which will be safety-critical for passenger and cargo aircraft. This paper looks at the different types and degrees of authority delegation given from the air to the ground and the ramifications of each, including the safety and security hazards introduced, the mitigation mechanisms for these hazards, and other demands on an RCO system architecture which would be highly invasive into (almost) all safety-critical avionics. The adjacent fields of unmanned aerial systems and autonomous ground vehicles are viewed to find problems that RCO may face and related aviation accident scenarios are described. The paper explores possible data communication architectures to meet stringent performance and information security (INFOSEC) requirements of RCO. Subsequently, potential challenges for RCO data communication authentication, encryption and non-repudiation are identified.

Communications↗

Cyber Safety and Security for Reduced Crew Operations (RCO)

NASA and the Aviation Industry is looking into reduced crew operations (RCO) that would cut today's required two-person flight crews down to a single pilot with support from ground-based crews. Shared responsibility across air and ground personnel will require highly reliable and secure data communication and supporting automation, which will be safety-critical for passenger and cargo aircraft. This paper looks at the different types and degrees of authority delegation given from the air to the ground and the ramifications of each, including the safety and security hazards introduced, the mitigation mechanisms for these hazards, and other demands on an RCO system architecture which would be highly invasive into (almost) all safety-critical avionics. The adjacent fields of unmanned aerial systems and autonomous ground vehicles are viewed to find problems that RCO may face and related aviation accident scenarios are described. The paper explores possible data communication architectures to meet stringent performance and information security (INFOSEC) requirements of RCO. Subsequently, potential challenges for RCO data communication authentication, encryption and non-repudiation are identified. The approach includes a comprehensive safety-hazard analysis of the RCO system to determine top level INFOSEC requirements for RCO and proposes an option for effective RCO implementation. This paper concludes with questioning the economic viability of RCO in light of the expense of overcoming the operational safety and security hazards it would introduce.

Aircraft Communication↗

X-57 Mod II Avionics Power Analysis

The X-57 Mod II Avionics Power Analysis was developed to provide the design requirements for the X-57 Avionics Power System. In the Mod II configuration, the two stock Tecnam P2006T Rotax engines are replaced with two electric motors. A high voltage traction battery (460 VDC nominal) supplies power for the motors. The Mod II avionics power design uses the stock Tecnam avionics power architecture as a baseline. The stock Tecnam power system utilizes three 12 VDC power sources, a battery and two alternators, to provided redundant avionics power. This redundancy was preserved in the X-57 avionics power architecture. A block diagram of the X-57 avionics system can be found in the “Mod II Architecture” worksheet of this documents. Since the X-57 electric motors do not have alternators or generators, two 13.8V DC Converters were added to replace the stock Tecnam alternators. Input power to these DC Converters is provide by the high voltage traction battery. The Tecnam stock lead acid battery was replaced with a Lithium Iron Phosphate (LiFePO4) battery. The Mod II Avionics Power Analysis provided the power requirements for the two 13.8V DC converters and the Lithium Iron Phosphate battery. Power requirement estimates for each subsystem used in this analysis were provided by manufacturer specifications, measured in the laboratory or provided by the subsystem design engineer. Typical power requirements and maximum power requirements were provided for each subsystem. The Mod II Avionics Power Systems consists of seven 13.8 VDC buses, two 28 VDC Buses and two 23 VDC buses. The avionics power requirements for Mod III configuration are the same as Mod II. The Mod III configuration replaces the stock Tecnam wing with a carbon fiber wing that is optimized for cruise conditions. The motors are located on the wingtips. The Mod IV Avionics Power Analysis is a separate analysis and is document number ANLYS-CEPT-032.

Keith Harris↗

Cargo launch vehicles to low earth orbit

There are two primary space transportation capabilities required to support both base programs and expanded mission requirements: earth-to-orbit (ETO) transportation systems and space transfer vehicle systems. Existing and new ETO vehicles required to support mission requirements, and planned robotic missions, along with currently planned ETO vehicles are provided. Lunar outposts, Mars' outposts, base and expanded model, ETO vehicles, advanced avionics technologies, expert systems, network architecture and operations systems, and technology transfer are discussed.

Austin, Robert E.↗

The Space Station Data Management System - Avionics that integrate

The Space Station Data Management System (DMS) comprises the networked computers, mass storage, workstations, and instrumentation interfaces required to support onboard systems and payload operations. This paper gives an overview of the current DMS architecture and discusses its role as onboard integrator in four of its major functional areas: (1) data communication; (2) data processing; (3) data administration, storage and retrieval; and (4) data presentation at the human-computer interface.

Whitelaw, Virginia↗

Safety-Critical Partitioned Software Architecture: A Partitioned Software Architecture for Robotic

The flight software on virtually every mission currently managed by JPL has several major flaws that make it vulnerable to potentially fatal software defects. Many of these problems can be addressed by recently developed partitioned operating systems (OS). JPL has avoided adopting a partitioned operating system on its flight missions, primarily because doing so would require significant changes in flight software design, and the risks associated with changes of that magnitude cannot be accepted by an active flight project. The choice of a partitioned OS can have a dramatic effect on the overall system and software architecture, allowing for realization of benefits far beyond the concerns typically associated with the choice of OS. Specifically, we believe that a partitioned operating system, when coupled with an appropriate architecture, can provide a strong infrastructure for developing systems for which reusability, modifiability, testability, and reliability are essential qualities. By adopting a partitioned OS, projects can gain benefits throughout the entire development lifecycle, from requirements and design, all the way to implementation, testing, and operations.

(Avionics Application Standard Software Interface ↗

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↗

Advanced Software Techniques for Data Management Systems. Volume 2: Space Shuttle Flight Executive System: Functional Design

A functional design of software executive system for the space shuttle avionics computer is presented. Three primary functions of the executive are emphasized in the design: task management, I/O management, and configuration management. The executive system organization is based on the applications software and configuration requirements established during the Phase B definition of the Space Shuttle program. Although the primary features of the executive system architecture were derived from Phase B requirements, it was specified for implementation with the IBM 4 Pi EP aerospace computer and is expected to be incorporated into a breadboard data management computer system at NASA Manned Spacecraft Center's Information system division. The executive system was structured for internal operation on the IBM 4 Pi EP system with its external configuration and applications software assumed to the characteristic of the centralized quad-redundant avionics systems defined in Phase B.

Pepe, J. T.↗

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