Drone Avionics Architecture Challenges and a Solution Approach

Lui Shalrs@illinois.edu

July 9, 2016

Copyright 2016 Board of Trustees of the University of Illinois. All Rights Reserved.

Acknowledgement

• The overview here describes a large team effort of UIUC, U Kansas, U South Carolina, Rockwell Collins and Lockheed Martin. There are may sponsors of this team effort. My work on drone avionics has been sponsored by ONR.

– L1 Adaptive Control: Naira Hovakimyan and Xiaofeng Wang

– Situation Awareness: Alex Kirlik, Naira Hovakimyan and Lui Sha

– L1 Simplex Architecture: Xiaofeng Wang, Naira Hovakimyan and Lui Sha

– Physically Asynchronous Logically Synchronous (PALS) architecture: Lui Sha, Abdullah Al-Nayeem and Steve Miller

– Single Core Equivalent Real Time Multicore Computing: Lui Sha, Macro Caccamo, Heechul Yun, Renato Mancuso, Jung-Eun Kim, Greg Arundale, Richard Bradford and Jonathan Preston.

– SecureCore Architecture: Man-Ki Yoon and Lui Sha.

– Drone Avionics Design, Development, Testing and Demonstrations: Bo Liu, Man-Ki Yoon, Naira Hovakimyan and Lui Sha

Safe Operation Challenges

• To safely operate drones in controlled national air space has three big challenges.

– Joint Manned Aircraft and UAS air traffic management

– Pilot-autonomy interaction

– Drone Avionics Architecture (Today’s talk)

• Easier certification without scarifying safety

• Robust against severe weather and mechanical problems

• Resilient against cyber-attacks

• Easy to program and lower V&V complexity

Safety Challenge

• From the perspective of drone navigation and control, the most critical challenge for drone safety is to prevent drones from failing to operate as intended. This requires

– Technology to maintain control and stay within assigned space/path, resilient to the presence of

• Severe weather and/or Mechanical problems,

• Cyber-attacks

• Software bugs

– Situation awareness technology to guide the safe interactions between the pilots and the drones.

– Lower cost V&V and Certification without scarifying safety

Software Safety Using Simplicity to Control Complexity - 1

• Challenge: How can we ensure safety if the avionics software becomes increasingly complex?

• Insight: Software complexity is driven by the pursuit of higher performance and useful features, not by the controllability and stability requirement.

• Simplex architecture[1] separates the stability control (simple) and high performance control (complex)

Software Safety Using Simplicity to Control Complexity

• Challenge: How can we ensure safety if the avionics software becomes increasingly complex?

• Run-Time Assurance– A simple and reliable safety controller to establishes the

stability envelope.– Vehicle normally controlled by complex high performance

controller.– Safety control takes over if

• Vehicle state approaches the boundary of stability envelope;

• About to leave the designated flight space/corridor;• Performance worse than the safety controller; • Software faults, e.g., crash, hang or outputs out of

ranges.– Complex controllers can be replaced during runtime.

• Simplex architecture’s stability envelope is conservative and has been extended with RT reachability analysis[2].

• [1] Lui Sha, “Using Simplicity to control complexity”, IEEE Software 2001• [2] Stanley Bak at al. Real-Time Reachability for Verified Simplex Design, RTSS 2014

Software Safety with Lower Cost Certification

• Challenge: How can we ensure safety if the drone software certification process that is weaker than DO178C, especially software becomes increasingly complex?

• The hybrid certification process: – A simple and reliable safety controller and

decision logic verified by using the DO178C equivalent process

– A Low cost auto like development process for normal drone operation

– The safety controller will take over and land the drone, should the drone losses stability or flying outside of designated space

• Limitation: Mechanical problems and cyber attacks

• “One key to achieving dependability at reasonable cost is a serious and sustained commitment to simplicity, including simplicity of critical functions and simplicity in system interactions. This commitment is often the mark of true expertise.

• There is no alternative to simplicity. Advances in technology or development methods will not make simplicity redundant; on the contrary, they will give it greater leverage.”

• Software for Dependable Systems: Sufficient Evidence?

Committee on Certifiably Dependable Software, National Academy of Science.

CPS Fault Tolerance

• In CPS systems, we need to consider not only software faults but physical system faults and their interactions.

– The classic Simplex architecture would fail when there are mechanical problems that changes the plant model

– The plant model change invalidates the stability envelope. Lyapunovfunction is a function of plant model and controller. With mechanical problem, the envelope may become too optimistic.

• CPS Fault Tolerance must cover the physical faults, the cyber faults and their interactions

Robust Control Challenge• Packages weighing five pounds or less encompass

86% of Amazon's deliveries. There will be many light-weight drones. They are sensitive to:

– Severe weather,

– Varying payload

– Mechanical problems

• We need robust adaptive flight control system to handle a wide range of uncertainties.

• For example, in NASA’s AirSTAR trials, controllers were design for max 4 degree angle of attack and 80 KEAS airspeed. when the pilots attempted to go to 5 degree angle of attack, all other controllers lost their robustness, while L1 performs well till 28 degrees angle of attack.

Robust Controlwith L1 Simplex Architecture

• Challenge: Mechanically, drone will not be as reliable as manned aircraft. How can we reliably handle mechanical problems?

• We replace the classic safety controller in Simplex architecture with L1 Adaptive controller

• L1 adaptive control is robust against a large class of uncertainties. Xiaofeng Wang led the integration of Simplex architecture and L1 Adaptive controller, leading to L1Simplex architecture.

• https://onedrive.live.com/redir?resid=EC81AC6A667CA7A0!89865&authkey=!AO2l-ZhrLhPa4ZI&ithint=file,pdf

L1Simplex Architecture

Security Challenges

• Consumer drones are very vulnerable, e.g.,

– SkyJack runs on grounded or onboard drone computers. It scans for MAC addresses used by wifi-based drone communication. It can de-authenticate the legitimate operators and hijack the drone.

– Maldrone is a software virus that can compromise any drone based on ARM Linux system, e.g. it can open a backdoor in the popular Parrot AR Drones software, infect onboard software and take over the control.

• Commercial drones are also vulnerable to sophisticated hacking, similar to incidents in industrial control system hacking. It was discovered that the ActelProASIC chip used in early Boeing 787 design had a backdoor that could allow a hacker, via Internet connection or as a passenger, to use entertainment system in the aircraft to take over the avionics and control the aircraft.

• Military drones are not immune either. Iranians captured a US surveillance drone:

– Jam satellite communication links

– Spoof GPS signal when drone tried to land to a “safe” location.

Secure L1 Simplex ArchitectureSecureCore architecture partitions cores into Trusted Cores and Application Cores. Trusted Cores are invisible to Application Cores but have one way visibility and controllability over Application Cores.

Man-Ki Yoon, Sibin Mohan, Jaesik Choi, Jung-Eun Kim, Lui Sha, “SecureCore: A Multicore-based Intrusion Detection Architecture for Real-Time Embedded Systems,” in Proceedings of the 19th IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS 2013), pp. 21-31, Apr. 201SecureCore was a winner of 2013 Qualcomm Innovation Fellowship Award

Initial Demo

V&V Cost Challenge• Much of the technological innovations needed to meet the challenges will be

realized in software. Verifiable software is at the heart of meeting safety, robustness, security and situation awareness requirements.

• As noted by National Academy of Sciences Committee on Software for Dependable Systems, “One key to achieving dependability at reasonable cost is a serious and sustained commitment to simplicity, including simplicity of critical functions and simplicity in system interactions. This commitment is often the mark of true expertise.”

• To transform the avionics software V&V, we are integrating

– Physically Asynchronous Logically Synchronous (PALS) architecture

– Single Core Equivalent Multicore Architecture

• that will allow engineers to program, to verify and to validate networked multicore control system as if it were a simple single core computer, greatly reducing its V&V complexity.

Physically Asynchronous Logically Synchronous Architecture

2009 David Lubkowski Memorial Award for the Advancement of Digital Avionics, American Institute of Aeronautics and Astronautics.

Lowering model checking time of a dual redundant flight control system design from 35 hours to less than 30 seconds, demonstrated at Advanced Technology Center, Rockwell Collins Inc.

Physical Asynchrony: A Source of Complexity

• Asynchronous interaction in networked systems– Source of many race conditions and non-reproducible bugs.

15

Physical Asynchrony: A Source of Complexity

• Asynchronous interaction in networked systems– Source of many race conditions and non-reproducible bugs.

15

Control 3

Control 2

Control 1

Sensor Period 9

sensorR

Period 10

Delivered at Period 9

Delivered at Period 10

Delivered at Period 10

clock skew

PALS Idea

16

Control 2

Control 1

Sensor Period j Period j+1

Control3

SynchronousLockstep Execution

PALS Execution(Logically

Synchronous)

PALS Idea

16

PALS Clock Period >= max. end-to-end delay + max clock skewMax clock skew

Control 2

Control 1

SensorPALS Clock Period j PALS Clock Period j+1

Control 3

SynchronousLockstep Execution

PALS Execution(Logically

Synchronous)

PALS Idea

16

PALS Clock Period >= max. end-to-end delay + max clock skewMax clock skew

Control 2

Control 1

SensorPALS Clock Period j PALS Clock Period j+1

Control 3

Used in PALSClock Period j+1

SynchronousLockstep Execution

PALS Execution(Logically

Synchronous)

17

Dual Redundant FGS Study

With PALSWithout PALS

~35 hours verification time ~30 seconds verification time

Best of Conference, David Lubkowski Award for the Advancement of Digital Avionics: Steven P. Miller, Darren D. Cofer, Lui Sha, Jose Meseguer, Abdullah Al-Nayeem, Implementing Logical Synchrony in Integrated Modular Avionics, Digital Avionics Systems Conference, DASC '09. IEEE/AIAA

18

PALS Properties• Engineering Properties

– Real-time Virtual Synchrony. Distributed applications can use synchronous design and run with PALS period P.

– Optimal performance: It is impossible to guarantee consistent views and actions faster than PALS

– Efficiency: It is impossible to have less communication overhead.– IMA Compatibility: It can be implemented in the context of Integrated

Modular Avionics[1]

• Logical Properties– Any finite state machine’s state transitions are the same under a synchronous

system or under an asynchronous system regulated by PALS [2][3]– Any temporal logic formula that holds under a synchronous system also holds

under an asynchronous system regulated by PALS, and vice versa[4].

• [1] Steven P. Miller, Darren D. Cofer, Lui Sha, Jose Meseguer, Abdullah Al-Nayeem, Implementing Logical Synchrony in Integrated Modular Avionics, Digital Avionics Systems Conference, 2009. DASC '09. IEEE/AIAA 28th Date: 23-29 Oct. 2009

• [2] Abdullah Al-Nayeem, Mu Sun, Xiaokang Qiu, Lui Sha, Steven P. Miller, Darren D. Cofer: A Formal Architecture Pattern for Real-Time Distributed Systems. IEEE Real-Time Systems Symposium 2009

• [3] Sha, Lui; Al-Nayeem, Abdullah; Sun, Mu; Meseguer, Jose; Olveczky, Peter C.PALS: Physically Asynchronous Logically Synchronous Systems http://www.ideals.illinois.edu/handle/2142/11897

• [4] José Meseguer, Peter Csaba Ölveczky: Formalization and Correctness of the PALS Architectural Pattern for Distributed Real-Time Systems. ICFEM 2010: 303-320

Single Core Equivalent Real Time Multicore Computing

The Risks of Multicore Integration

• Original hardware allows each software application to own all the

processor resources (memory, cache, I/O bandwidth)

• Re-integration on a single multicore processor means that

applications must compete for these same resourcesOriginal Distributed System New Multicore System

Software from each node is

re-integrated on a single core

Applications moving from

platforms where they “own” the

entire node to one where they

must compete for cache, memory

bus, I/O resources

Node

1

Node

2

Node

3

Node

4

netw

ork

cache

main memory

Core1 Core2

Core3 Core4

Source: Russell Kegley and Dennis Perlman

Single Core Equivalence

Original Multicore System SCE Multicore System

Applications “own” each node again with partitioned global resources.

Node 1

Node 2

Node 3

Node 4

on

ch

ip n

etw

ork

cache

main memory

Core1 Core2

Core3 Core4

http://rtsl-edge.cs.illinois.edu/SCE/ A short version will be published in IEEE ComputerMulticore Avionics Certification requirements

Allows the reuse of design, development, analysis and certification process designed for single core chips

The Difference

• Successful re-integration on the multicore platform requires that the

applications execute with similar performance as before

• For example, LM Space Systems tests indicated that competing with only

one other core can mean a 2X increase in execution time (blue bars)

• Worst case can be a 6X increase in application execution time (blue bars)

Critical Software can be Slowed

by up to 6X if Uncontrolled

Source: Lockheed Space Systems HWIL Test bed

• Integrating with CE&T-

sponsored UIUC SCE

technology can control

increases in execution

time (red)

• This could make the

difference between a

successful integration and

failure

System Development and Demonstration

• Planned Demonstrations: Visitors can perform attacks on communication links, on sensor signals, and infect on-board and ground control software through deliberately opened backdoors, or inherently vulnerable protocols e.g.the civilian GPS protocol to test cyber-attack resiliency. The performance metric will be attack coverage: a list of types of cyber-attacks our system can or cannot successfully defend against. Demonstrations include: – Communication attacks: i) Communication packet redirection; ii) radio

control hijacking. – Sensor signal attacks: i) signal jamming; ii) GPS spoofing.– Onboard software attacks: i) attacks on navigation and control software; ii)

trying to penetrate the logically invisible trusted-cores.– Ground control station attacks: i) attacks on communication and command

software; ii) trying to penetrate the logically invisible trusted-cores.– Simulated severe weather conditions and mechanical failure models to

test if robust adaptive control technology can keep UAS stable and safe from the violation of flight space and path requirements, in spite of cyber-attacks.

Summary

• We have given a high level overview on our progress in commercial drone architecture with following properties:

– Easier certification without scarifying safety

– Robust against severe weather and mechanical problems

– Resilient against cyber-attacks

– Easy to program and lower V&V complexity

– System integration, tests and demonstration plan

– Collaboration and transition