Document
Software Defined Wireless Avionics for
Flight Test
Matt Waldersen AST, Flight Systems Design Neil A. Armstrong Flight Research Center
Why Do We Need Wireless
Avionics
• Cables are heavy – On the Airbus A380 - 800 – ~100,000 individual wires – ~300 miles total length – ~12,500 pounds total weight • Difficult to integrate into an aircraft – Adding new cable harness to an aircraft is time consuming – High personnel and procurement costs
Barriers to Wireless Avionics
(1 of 3)
• Current avionics systems don’t support wireless
technology
– High cost and risk in replacing pre - existing avionics systems • Pre - existing wired systems aren’t going to magically disappear
• Regulatory compliance complexities
– Vary by governing agency and territory – Regulations evolve over time • FAA Advisory Circular AC 91.21 - 1 “Use of Portable Electronic Devices Aboard Aircraft” has evolved five times since 2000
Barriers to Wireless Avionics
(2 of 3)
• Obsolescence risk – “Why would I design a flight system that can’t incorporate new or alternative wireless technology several years from now ?”
Barriers to Wireless Avionics
(3 of 3)
• No “one size fits all” solution to wireless avionics • Each wireless transmission methods has it’s own pro’s and con’s – 802.11 is great for high bandwidth transmission but is power intensive – Bluetooth is low power, but is also low bandwidth • An optimal wireless avionics system needs to be heterogeneous
Goals and Objectives
• Design a wireless avionics interface that lessons the challenge of integrating new wireless systems • Design a wireless avionics interface that can rapidly incorporate dissimilar wireless technology – Choose right wireless technology for the right application – Reduce obsolescence risk • Design a wireless avionics interface that’s implementation agnostic – Doesn’t need to vary from aircraft to aircraft • Design a wireless avionics interface that provides a layer of abstraction – Eliminate need to modify preexisting avionics system to interface with new wireless systems
Overview of Current Work
• Currently designing a wireless flight system that leverages software defined radio (SDR) technology • Benefits of SDR technology – Rapidly incorporate new wireless capability entirely through software modification • Developing software defined radio access point that allows wireless system developers to integrate their experiments without modification to pre - existing avionics architecture or hardware • Only the interface to avionics is being developed – Intent is to facilitate the technology of others
What Is Software Defined Radio?
• Software Defined Radio (SDR ) is a wireless device where RF communication is interpreted in software rather than dedicated hardware • Can be modified to operate on wide suite of frequencies • Reprogrammable to accommodate a wide variety of current and future protocols – Ideal for testing and developing new sensor technology – Field upgradable to remain at the forefront of RF communication protocols Software Defined Radio Usage Scenario Scenario Without SDR 1. Start with hypothetical wireless flight sensor WiFi WiFi system that communicates via WiFi 2. A new - cutting edge wireless sensor WiFi BT technology comes out that uses BlueTooth 3. Modify pre - existing Wi - Fi system to incorporate Wi - Fi and BlueTooth WiFi WiFi – Increase hardware complexity – Significant non - recurring engineering costs – Requires engineering resources for BT BT both hardware and software development Software Defined Radio Usage Scenario Scenario With SDR 1. Start with hypothetical wireless flight WiFi sensor system that communicates via WiFi WiFi and utilizes SDR technology WiFi BT BT 2. A new - cutting edge wireless sensor technology comes out that uses BlueTooth BT 3. BlueTooth communication protocols are uploaded to the SDR, and the new sensor WiFi BT nodes are easily integrated into the vehicle – No Hardware Modification – Negligible Non - Recurrent Engineering WiFi Cost
Architecture Overview
• Utilizes a SDR access point as a “broker” in a “publish subscribe” architecture • Avionics systems request (or subscribe) to specific pieces of information provided by the SDR access point • Wireless devices transmit (or publish) data that is acquired by the SDR access point
Architecture Advantages (1 of 2)
Eliminate Need Using a Software Defined Radio for New (SDR) as a single “universal access Hardware point” for wireless devices SDR’s can be reprogrammed Rapid through software modifications.
Wireless New wireless capability is added at Configurability “the speed of software” Access point serves as a courier of Implementation information between wireless Agnostic devices and a vehicle network Abstraction Wireless devices and vehicle Layer Between systems are only concerned with Vehicle & communicating with SDR Sensor
Architecture Advantages (2 of 2)
• SDR access point utilizes traffic shaping to improve network efficiency • No direct connection between internal avionics systems and external wireless devices • The only way a hacker would be able to communicate with an avionics system would be if that avionics system “subscribed” to it • Can adapt to evolving regulatory requirements – Can operation can be modified to comply with varying spectrum compliance requirements • Over time and by region of operation • Modular architecture – Potential market for wireless hardware and SDR gateway software modules
Architecture Challenges
• How do we certify a software defined radio – Do we use hardware filters to eliminate possibility to out of band transmissions?
• Comes at the cost of reduced flexibility – Do we apply the same software assurance practices used to certify other avionics systems?
• Comes at the cost of increased design complexity • System scalability hasn’t been pushed to it’s limits – Lab testing wasn’t able to find a limit to the number of wireless devices that can be used at one time, but I’m sure it’s there somewhere • System adoption requires buy in from both avionics developers and wireless system developers – Won’t benefit aircraft designers if wireless developers only provide a custom interface solution – Wireless develops can’t put their product in the field if no one is using this interface
Current Status
• Successfully demonstrated the ability to communicate with two COTS transceivers that operate on dissimilar protocols and frequencies.
– TRL 3 • Patent has been filed on software architecture • Currently pursuing corporate partners to license the technology
Path Forward & Closing Concepts
• In order for this concept to work, we need partners – We need people willing to test their wireless systems using this concept – We need end users to utilize this concept, so wireless developers have a path to industry infusion • We need partners willing to commercialize this technology – Licensing is currently available through NASA’s technology transfer portal – Go to: https:// technology.nasa.gov/patent/DRC - TOPS - 42