1. Why Do Airplanes Crash? An Open Source Air Data Inertial Reference Unit Investigation *** 2012 PSU/Galois Capstone Project Chris Andrews, Trang Nguyen, Mark Craig, Kayla Seliner

2. Presentation Outline Air 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. Demonstration Conclusion. 2

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

4. Benefits of ADIRU Systems Redundant sensors make the system less vulnerable to single sensor failure. Modular design. Fault containment. Deferred maintenance. Improved safety margins. 4

5. 5 Northrup Grumman LTN-101 [1] GEC-Marconi FIN3060 [2] [1] "bug_cause_aussie_a330_plunge". theregister.co.uk 04 June 2012. http://www.theregister.co.uk/2011/12/20/bug_cause_aussie_a330_plunge/ [2] "Chapter 19 Inertial Reference System". oatmedia.com Web. 02 June 2012..

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

7. Failures affecting sensors Mechanical Icing Blocked air tubes Electronic High Energy Particle Electro Magnetic Interference Software Bugs Human error Most system failures have multiple causes 7

8. Motivation ADIRU failures cause fatal air crashes. Closed source, proprietary system. 8 "Airbus A320 Experience." The Flying Engineer. Web. 03 June 2012.

9. ADIRU failures are a critical event with serious consequences if the aircraft is not in a visual flight mode. [1] "Final Moments of Flight 447". foxcrawl.com Web. 02 June 2012..

10. Air France Flight 447 On May 31st, 2009, Air France Flight 447 flying from Rio de Janeiro to Paris crashed into the Atlantic ocean killing all passengers. Airspeed sensors ice over, sending faulty airspeed data to ADIRU causing a stall. Pilots unable to recover from stall without verifiable airspeed. 10 "Final Moments of Flight 447". foxcrawl.com Web. 02 June 2012..

11. Qantas Flight 72 An Airbus A330 flying on October 7th, 2008 from Singapore 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..

12. Types of Faults Fail Silent: system fails to send data. Persistent and Transient Faults: System sends arbitrary data. Noise. Symmetric : sender broadcasts same (bad) data to all recipients. 12 Fail SilentFail SymmetricFail Asymmetric

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 13

14. 14 Build a redundant network using Arduino development boards. Use I2C protocol.

15. Reasons For Choosing Arduino Open source hardware and software. Large community of developers. Libraries included. Lowest hardware entry cost. Quickest start time. 15

16. Arduino ArduIMU+V3 Atmega328 µP 3D Accelerometer 3D Gyroscope 3D Magnetometer GPS port 1.5” x 1.0” Large development community 16 "arduIMU+V3". diydrones.com 02 June 2012.

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

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

19. ADIRU “Black Box” 19 I2C and Power Bus. Environmental Enclosure. Separate board for power supply. ArduIMU boards have same orientation.

20. Implementing Byzantine Fault Tolerance because it can tolerate special case of faults. Must satisfy two conditions Validity If sender is non-faulty, all recipients receive correct value. Agreement All recipients agree on final value. Must have 3N+1 modules to handle N faults. Our system has 4 modules. We can handle 1 Byzantine fault. 20

21. 21

22. 22

23. 23

24. 24

25. 25

26. 26

27. Sensor reads are interrupt driven. Must synchronize clocks for all modules to compare sensors at time T. 27

28. 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 seconds. This helps to ensure a tight synchronization as well as lessen the interference of data processing. 28 [1] Zhao, Y., Wang, Y., Huang, J., & Shi, X. (2008). A Stable Clock Synchronization Based on Clock Drift Rate. IFIP Internation Conference on Network and Parallel Computing, (pp. 205-209). Beijing, China.

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

30. For simplicity all output is logged in onboard EEPROM on each individual module. Downside is separate application is required to extract data from EEPROM. 30

31. 31 Demo!

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

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

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

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

36. 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. Wiki/Code Repo: https://sites.google.com/a/pdx.edu/adiru/ 36

37. 37

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

39. Triple Modular Redundant and Triple Modular Redundant Byzantine Networks. 39