Why Do Airplanes Crash?An Open Source Air Data Inertial Reference Unit Investigation

***

2012 PSU/Galois Capstone ProjectChris Andrews, Trang Nguyen, Mark Craig, Kayla Seliner

Presentation OutlineAir Data Inertial Reference Unit

• Our Project: building an open source ADIRU.• Overview: what is an ADIRU?.• Motivation: why are they important?.• Fault Tolerance: types of faults.• Approach: voting methods.• Design: hardware and software architecture.• Results.• Conclusion.

2

• The ADIRU is a fault tolerant system that collects and processes sensor values.• Accelerometers• Gyroscopes• Altimeters • Airspeed

• Functions as the sole source of sensor data aboard the aircraft.

• Autopilot and unstable flight regimes depend upon valid and uninterrupted sensor data for safe flight.

Air Data Inertial Reference Units (ADIRU)

3

Benefits of ADIRU Systems• Redundant sensors make the system less

vulnerable to single sensor failure.• Modularization and fault containment.• Deferred maintenance.

4

GEC-Marconi FIN3060 Commercial AircraftInertial Reference Unit

http://www.foxcrawl.com/2011/05/30/video-final-moments-of-flight-447-3-5-minutes-of-terror-air-france-passenger-jet-crashed-into-atlantic-after-losing-3000-meters-per-minute/

How ADIRU Systems Fail

• Failure of ADIRU may be intermittent and cause cockpit instrumentation to send contradictory warnings (stall and high speed).

• ADIRU is the root of all sensor data for flight avionics. Failure in the ADIRU can instantly propagate throughout flight control system.

• Failures of the ADIRU system effect both autopilot and manual flight modes.

5

Triple Modular Redundant System• Votes on outputs of three redundant sensors.• System can tolerate single sensor fault.• Relatively simple to implement and diagnose.

Byzantine Fault Tolerant System

• At least 4 different voters each with a sensor.

• Tolerates fault in sensor or in voter.• F faults require 3F+1 voters with

sensors.• Requires complex voting algorithm.• Can survive class of faults not dealt with

by TMR.

6

TMR vs. ADIRU

7

TMRTMR

ADIRU

Motivation

• System complexity.

• Closed source, proprietary system.

• (needs picture)

8

ADIRU failures are a critical eventwith serious consequences if theaircraft is not in a visual flight mode.

[1]"Final Moments of Flight 447". foxcrawl.com Web. 02 June 2012. <http://www.foxcrawl.com/2011/05/30/video-final-moments-of-flight-447...>.

Air France Flight 447On May 31st, 2009, Air France Flight 447 flying from Rio de Janeiro to Paris crashed into the Atlanticocean killing all passengers.

• Airspeed sensors ice over, sending faulty airspeed data to ADIRU.

• Flight crew unable to stabilize level flight without working sensors. 10

"Final Moments of Flight 447". foxcrawl.com Web. 02 June 2012. <http://www.foxcrawl.com/2011/05/30/video-final-moments-of-flight-447...>.

Qantas Flight 72An Airbus A330 flying on October 7th, 2008 fromSingapore to Perth suffered a malfunction in the ADIRU causing two rapid descents that threw passengers and crew about the cabin.

11"Qantas Terror Blamed On Computer". stuff.co.nz 02 June 2012. <http://www.stuff.co.nz/travel/australia/6163633/Qantas-terror-blamed-on-comput>.

Multiple Sources of Failure

• Human Causes• Deferred Maintenance

• Environmental Causes• Software Bugs

12

Types of Faults

• Fail Silent: system fails to send data. This fault is masked by a redundant system

• Byzantine: system sends arbitrary data including different data to different controllers.

This fault cannot be masked by simple redundancy.

13

Project Requirements

• Must exhibit Byzantine fault tolerance.• Must include ability to insert faults.• Must be expandable.• Must follow open source guidelines.• Should include

• Gyroscope• Accelerometer• Altimeter• GPS

14

Design Approach

15

I2C Bus

Gyroscope

Accelerometer

Magnetometer

ArduIMU

Gyroscope

Accelerometer

Magnetometer

ArduIMU

Gyroscope

Accelerometer

Magnetometer

ArduIMU

Gyroscope

Accelerometer

Magnetometer

ArduIMU

• Build a redundant network using Arduino development boards.

• Use I2C protocol.

Reasons For Choosing Arduino

• Open source hardware and software.• Large community of developers.• Libraries included.• Lowest hardware entry cost.• Quickest start time.

16

Arduino ArduIMU+V3

• Atmega328 µP• 3D Accelerometer• 3D Gyroscope• 3D Magnetometer

17"arduIMU+V3". diydrones.com 02 June 2012. <https://store.diydrones.com/ArduIMU_V3_p/kt-arduimu-30.htm>

18

Bus Implementation

• There are many bus protocols to choose from including CANbus, SPI, and I2C.

• These requirements must be met• Must implement multi-master.• Must be expandable.• Should be industry standard.

I2C Protocol

19

uC1 uC2 uC3 uC4

SCL

SDA

I2C: Two Wire Communication

• Libraries included within Arduino.• No extra hardware required.• Expandable.• Supports multi-master.

ADIRU “Black Box”

• I2C and Power Bus• Environmental Enclosure• Separate board for power supply

20

Fault Tolerant Implementation

• Implementing Byzantine fault tolerance because it can tolerate special case of faults.

• Must satisfy two conditions • What are two conditions?

• Must have 3N+1 modules to handle N faults.• Our system has 4 modules.

• We can handle 1 Byzantine fault.

21

Main Algorithm

22

Read Sensors

Module[N] is general

Module[N] sends sensor data to

lieutenants

Lieutenants send “general” sensor data

to all other lieutenants

Each lieutenant performs an

averaging vote

Log Data

Loop until all modules have been general

Wait for timer interrupt

1

2 3 4

4 3 2 4 3 2

3

4 1 2

2 1 4 2 1 4

2

3 4 1

1 4 3 1 4 3

4

1 2 3

3 2 1 3 2 1

Results With 0 Faults Introduced1

2 3 4

4 3 2 4 3 2

[X, Y, Z] = [1, 1, 1]

[1, 1, 1] [1, 1, 1] [1, 1, 1]

[1, 1, 1] [1, 1, 1] [1, 1, 1] [1, 1, 1] [1, 1, 1] [1, 1, 1]

[1, 1, 1] [1, 1, 1]

[1, 1, 1] [1, 1, 1]

[1, 1, 1] [1, 1, 1]

[1, 1, 1] [1, 1, 1] [1, 1, 1]

[1, 1, 1] [1, 1, 1] [1, 1, 1]

[1, 1, 1] [1, 1, 1] [1, 1, 1]

2 3 4

[1, 1, 1] [1, 1, 1] [1, 1, 1]

[1, 1, 1] [1, 1, 1] [1, 1, 1]

[1, 1, 1] [1, 1, 1] [1, 1, 1]} [1, 1, 1] } [1, 1, 1] } [1, 1, 1]

23

Results With 1 Fault Introduced

24

1

2 3 4

4 3 2 4 3 2

Sensor = [1]

[1] [1] [0]

[1] [1] [1] [1]

[1] [1]

[1] [1]

[1] [1]

[1] [1] [0]

[1] [1]

[1] [1]

2 3 4

[1] [1] [0]} [1] } [1] } [1]

Link Error between Module 1 and

Module 4

[0] [0]

[0][0]

[1] [1][0]

[1] [1][0]

Results With 2 Faults Introduced

25

1

2 3 4

4 3 2 4 3 2

Sensor = [1]

[1] [0]

[1] [1]

[1] [1]

[1] [1]

2 3 4

} } }

Link Error between Module 1 and Module 4 as well as Module 1 and Module 2

[0] [0]

[0][0]

[0]

[0] [0]

[0]

[0] [0]

[0] [0][0]

[1][0]

[0]

[1][0]

[0]

[0]

[1][0]

[1]

[0][0][0] [0] [0]

System Output With 0 Faults

26

System Output With 1 Fault

27

System Output With 2 Faults

Clock Synchronization Method• One module is dedicated to synchronizing the

clocks of all other modules.• Clock synchronization is within 8ms.• Timing of clock synchronization cycles is set so that

each device is synchronized to the master every few data cycles.• This helps to ensure a tight synchronization as

well as lessen the interference of data processing.

28

Clock Synchronization

• Sensor reads are interrupt driven.• Must synchronize clocks for all modules to compare

sensors at time T.

29

Master Slave

T1

T2

T3

T4

T5

T6

New Clock Value = Old Clock Value - Offset

Master Slave

Request Slave Clock Value

Send Clock Value

Calculate DelayDelay = (T4 – T2)/2

Send Back Slave Clock Value to

Calculate Delay

Send Clock Value

Calculate OffsetOffset = T6 – Master Clock Value -

Delay

Clock Synchronization Output

• The output displays • Original slave clock value• Current master clock value• Clock value offset• New clock value

• The offset is “0” because a delay of “1” was calculated.

30

31

Demo!

Budget

32

Price to implement Byzantine fault-tolerance is under $500.

Further Work

• Integrate GPS, magnetometer, altimeter and other sensors into the system.

• Implement kalman filters in the SW to smooth out sensor noise.

• Gather real data with flight testing.• Add fault tolerance to clock synchronization.• Add external data logging.• Signal processing of sensor data.• External fault insertion.

33

Lessons Learned

• Interrupt routines on microcontrollers.• Debugging methods.• Code development: algorithm>python>C.• How to organize a large project involving hardware and software.• Documentation and project organization.

34

Acknowledgements***

We would like to thank our sponsors: Dr. Lee Pike and Galois Inc.

We also acknowledge the help of our advisor:Dr. Christof Teuscher Portland State University

35

Conclusion

• Our system exhibits Byzantine fault tolerance.• Models an open source ADIRU.• System includes fault insertion.• System is modular and expandable.• Sensor data polled from accelerometers and

gyroscopes.

36