Thesis 73733 PDF

Development of an Aircraft Health Monitoring Program for
Predictive Maintenance
Nuno Alberto Fonte Silva e Lima
Thesis to obtain the Master of Science Degree in
Aerospace Engineering
Supervisors: Prof. Pedro da Graça Tavares Álvares Serrão

Eng. André Martins Abrantes Leite
Examination Committee
Chairperson: Prof. José Fernando Alves da Silva
Supervisor: Prof. Pedro da Graça Tavares Álvares Serrão
Member of the Committee: Prof. Sérgio David Parreirinha Carvalho
December 2017
ii
Acknowledgments
First and foremost, I would like to thank Professor Pedro Serrão for all the guidance, counselling and for
giving me the opportunity to develop this work at Portugália Airlines. I would also like to give a special
thanks to Professora Conceição Amado for the availability, sympathy and shared knowledge.
I would like to extend my thanks to everyone I met at Portugália Airlines, for making my work there a
pleasant moment and for all the help and contributions, either directly or indirectly, to this dissertation. A
word of appreciation to my supervisors at Portugália, Eng. André Leite and Eng. Francisco Freitas, who
have provided me with everything I needed, and for the constructive advice and support.
My deepest thanks to my family, especially my parents and sister, for the advice and time spent
reviewing this work, and for the unconditional support throughout this journey, being my main source of
motivation and mental fortitude.
To my friends, for all the support and the good times that we have been sharing.
Last, but not least, to Inês Pedro for all the support, patience and encouragement.
iii
iv
Resumo
O crescimento acelerado da indústria da aviação gerou um mercado altamente competitivo, onde

se torna cada vez mais difı́cil para as companhias aéreas manterem-se rentáveis num segmento
com baixas margens de lucro. O aumento da segurança na aviação é o produto de programas de
manutenção consistentemente mais exigentes que implicam custos mais elevados para as companhias.
Para se manterem competitivas, estas têm procurado minimizar custos, mantendo as suas operações
a funcionar de forma tão eficiente quanto possı́vel. Os desenvolvimentos tecnológicos na indústria
significaram um aumento na disponibilidade de dados de voo, o que levou as companhias aéreas a
estudar mais detalhadamente o comportamento dos sistemas dos seus aviões. Os dados de voo são
recolhidos pelos sistemas da aeronave, depois descodificados e distribuı́dos para os departamentos
de engenharia, manutenção e segurança para serem interpretados e analisados. A aplicação desen-
volvida no âmbito desta dissertação baseia-se exclusivamente em dados de voo da frota Embraer ERJ-
190/195 da Portugália Airlines, a fim de realizar uma análise de tendências para monitorizar a saúde e
degradação de alguns dos sistemas mais crı́ticos no contexto de manutenção. O processo de deteção
e identificação de comportamento degradado foi realizado através de duas metodologias distintas. Uma
baseada nos limites operacionais dos sistemas, cuja violação repetida é geralmente uma indicação de
desempenho anormal do sistema. A segunda metodologia, de natureza comparativa, utilizou técnicas
de data mining para identificar padrões de dados anómalos comparando os dados dos sistemas dentro
da frota. Esta aplicação interativa foi criada com o intuito de auxiliar o departamento de manutenção na
previsão de falhas inesperadas de componentes/sistemas que comprometeriam a navegabilidade da
aeronave.
Palavras-chave: Dados de voo, Análise de Tendências, Monitorização da Saúde da Aeron-

ave, Manutenção Preditiva
v
vi
Abstract
The continuous growth in the aviation industry leads to a highly competitive scene where airline com-
panies struggle to remain profitable in a low profit margin market. The increase in aviation safety is the
product of consistently more demanding maintenance programs that imply higher costs. In order to re-
main competitive, airlines are minimizing overall costs by keeping their operations running as efficiently
as possible. The technological developments in the industry meant an increase in flight data availability
which prompted airlines to study the behaviour of its fleet more closely. Flight data is collected by the air-
craft’s systems, then decoded and distributed to the engineering, maintenance and safety departments
to be interpreted and analysed. The application developed within the scope of this dissertation makes
use of data collected from the Embraer ERJ-190/195 fleet of Portugália Airlines, in order to conduct a
trending analysis to monitor the health and degradation of some of the most critical systems in the con-
text of maintenance. The process of detection and identification of degraded behaviour was performed
by two distinct methodologies. One was based on operational thresholds, whose repeated violation is
usually an indication of abnormal system performance. The second methodology, of comparative na-
ture, made use of data mining techniques to identify anomalous data patterns by comparing the systems’
data within the fleet. This interactive web-application was created to aid the maintenance department in
predicting unexpected component/system failures that would jeopardize the aircraft’s airworthiness.
Keywords: Flight Data, Trend Analysis, Aircraft Health Monitoring, Predictive Maintenance,
Data Mining, Clustering.
vii
viii
Contents
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Background 7
2.1 Embraer E190 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 General Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Data Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Recording System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Analysis Ground Station Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Flight Phase Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Data Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Data-Mining Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Data Mining Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 Cluster Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3 Agglomerative Hierarchical Clustering . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Aircraft Health Monitoring Program 27

3.1 Data Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Application Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Monitored Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 Altitude Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2 Auxiliary Power Unit Exhaust Gas Temperature . . . . . . . . . . . . . . . . . . . . 34
ix
3.3.3 Engine Bleed System Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.4 Engine Bleed System Pressure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.5 Center/Forward Electronics Bay Air Flow . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.6 Engine Light-Off Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.7 Engine Vibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.8 Hydraulic System Pressure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.9 Hydraulic System Quantity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.10 Nose Wheel Steering System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.11 Total Air Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.1 Selection Menu: Aircraft & System . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.2 Aircraft Status Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.3 Application Settings Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.4 Time Series Plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.5 System Trend Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4 Results and Case Studies 65

4.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2 Aircraft Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.1 Case I - Engine Bleed System (Aircraft Delta) . . . . . . . . . . . . . . . . . . . . . 67
4.3.2 Case II - Engine Bleed System (Aircraft Lambda) . . . . . . . . . . . . . . . . . . . 70
4.3.3 Case III - Engine Bleed System (Aircraft Kappa) . . . . . . . . . . . . . . . . . . . 73
4.3.4 Case IV - APU EGT (Aircraft Zeta) . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5 Conclusion 79
5.1 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Bibliography 81
A Exported Parameters 85
B Aircraft System Description Section 89

B.1 Integrated Pitot/Static/AOA Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.2 Auxiliary Power Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.3 Engine Pneumatic Bleed System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.4 Avionics Compartment Ventilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
B.5 Ignition System - Igniters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
B.6 Engine Vibration Monitoring System - Accelerometers . . . . . . . . . . . . . . . . . . . . 93
B.7 Hydraulic System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
x
B.8 Nose Landing Gear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
B.9 Total Air Temperature Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
xi
xii
List of Tables
2.1 Embraer E190-100 General Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 ARINC-429 Word Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Status/Sign Matrix - Sign and Status Coding. . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Binary Coded Decimal Word Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Flight Phase numerical mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Example of the contents of an exported CSV file - viewed in R Studio. . . . . . . . . . . . 17
2.7 Cluster Analysis - Data matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Cluster Analysis - Dissimilarity matrix example. . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 File name specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Engine 1 Fuel Flow Start - Flight Data Snapshot. . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Engine 1 Fuel Flow Start - System File Example. . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Altitude split manufacturer thresholds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Altitude Split Monitoring - Snapshot Parameters. . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Temperature limits according to APU operation. . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7 APU EGT Monitoring - Snapshot Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.8 Engine 1 Bleed Over-Temperature Events - Anti-Ice OFF. . . . . . . . . . . . . . . . . . . 37
3.9 Bleed Over-Temperature Monitoring - Snapshot Parameters. . . . . . . . . . . . . . . . . 37
3.10 Bleed Pressure Oscillation Monitoring - Snapshot Parameters. . . . . . . . . . . . . . . . 40
3.11 Electronics Bay Air Flow Thresholds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.12 Center/Forward Electronics Bay Air Flow - Snapshot Parameters. . . . . . . . . . . . . . . 41
3.13 Engine 1 Ignition - Flight Data Snapshot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.14 Engine Light-Off Time Monitoring - Snapshot Parameters. . . . . . . . . . . . . . . . . . . 43
3.15 Engine Vibration Monitoring System - Vibration Limits. . . . . . . . . . . . . . . . . . . . . 44
3.16 Engine Vibration Monitoring - Snapshot Parameters. . . . . . . . . . . . . . . . . . . . . . 44
3.17 Hydraulic System Pressure Monitoring - Snapshot Parameters. . . . . . . . . . . . . . . . 46
3.18 Hydraulic System Quantity Monitoring - Snapshot Parameters. . . . . . . . . . . . . . . . 46
3.19 Nose Wheel Steering System Monitoring - Snapshot Parameters. . . . . . . . . . . . . . . 48
3.20 Total Air Temperature - Snapshot Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.21 APU EGT - Dissimilarity Matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
xiii
A.1 Exported Parameters by AGS 1/3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
xiv
List of Figures
1.1 World Annual Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Growth in Aircraft Data Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Adoption of AHM and PM techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Effects of the adoption of AHM and PM techniques . . . . . . . . . . . . . . . . . . . . . . 4
2.1 ARINC 717 Frame Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Quick-Access Recorder System - Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Analysis Ground Station (AGS) Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Flight Phases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 FLIGHT PHASE parameter progression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Data Mining Process - Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 Steps in Cluster Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Hierarchical Clustering - Dendrogram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1 Data Migration - Part I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Update Flights Routine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Process Flight Routine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Maximum altitude difference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 APU EGT Start Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6 APU EGT Run Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7 Bleed Over-Temperature Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8 Engine 1 Bleed Pressure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.9 Healthy Bleed System vs Faulty Bleed System. . . . . . . . . . . . . . . . . . . . . . . . . 39
3.10 Engine Bleed Pressure Standard Deviation of Healthy Aircraft. . . . . . . . . . . . . . . . 40
3.11 Forward Electronics Bay Air Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.12 Engine Two Low Pressure Stage Vibration. . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.13 Hydraulic System 1 Pressure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.14 Hydraulic Fluid Quantity System 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.15 Nose Landing Gear Left Wheel Longitudinal Angle. . . . . . . . . . . . . . . . . . . . . . . 48
3.16 Total Air Temperature Difference Between the Two Temperature Sensors. . . . . . . . . . 49
3.17 Data Migration - Part II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
xv
3.18 Graphical User Interface - Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.19 Selection Menu - Aircraft and System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.20 Aircraft Status - Normal, Alert and Critical. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.21 Application Settings - Action Buttons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.22 Bleed Pressure Oscillation - Normal, Alert and Critical Status. . . . . . . . . . . . . . . . . 55
3.23 Hydraulic System Pressure Monitoring - Hover Text. . . . . . . . . . . . . . . . . . . . . . 55
3.24 System Status Analysis - Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.25 Engine 2 Core Maximum Vibration at Take-Off. . . . . . . . . . . . . . . . . . . . . . . . . 56
3.26 APU EGT - fleet comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.27 Autocorrelation Function - APU EGT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.28 APU EGT - Dendrogram Cut. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.29 Cluster Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1 Altitude Split Monitoring - Aircraft Lambda. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.2 Center Electronics Bay Air Flow Monitoring - Aircraft Lambda. . . . . . . . . . . . . . . . . 66
4.3 Engine 2 Bleed Pressure Oscillation Aircraft Delta. . . . . . . . . . . . . . . . . . . . . . . 67
4.4 Engine 2 Bleed System Fleet Comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5 Case Study I - Timeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6 Engine 2 Bleed Pressure Oscillation Aircraft Lambda. . . . . . . . . . . . . . . . . . . . . 70
4.7 Engine 2 Bleed System time series - Lambda, Alpha and Delta. . . . . . . . . . . . . . . . 71
4.8 Engine 2 Bleed System Fleet Comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.9 Case Study II - Timeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.10 Engine 1 Bleed Pressure Oscillation Kappa. . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.11 Case Study III - Timeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.12 Auxiliary Power Unit EGT Monitoring Zeta - Start Mode. . . . . . . . . . . . . . . . . . . . 75
4.13 APU EGT Monitoring Zeta - Start and Run Modes. . . . . . . . . . . . . . . . . . . . . . . 76
4.14 Case Study IV - Timeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.1 Integrated Pitot/Static/AOA Sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

B.2 Auxiliary Power Unit - Location and Main Components. . . . . . . . . . . . . . . . . . . . . 90
B.3 Engine Pneumatic Bleed System - Control Schematic. . . . . . . . . . . . . . . . . . . . . 90
B.4 Engine Pneumatic Bleed System - Main Components Location. . . . . . . . . . . . . . . . 91
B.5 Avionics Compartment Ventilation - Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 91
B.6 Avionics Compartment Ventilation - Component Location. . . . . . . . . . . . . . . . . . . 92
B.7 Ignition System - Igniters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
B.8 Engine Vibration Monitoring System - Front Accelerometer. . . . . . . . . . . . . . . . . . 93
B.9 Engine Vibration Monitoring System - Rear Accelerometer. . . . . . . . . . . . . . . . . . 93
B.10 Hydraulic System - Control Surfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
B.11 Hydraulic Pressure Indication System - Components. . . . . . . . . . . . . . . . . . . . . . 94
B.12 Hydraulic Fluid Quantity Indication System - Components. . . . . . . . . . . . . . . . . . . 95
xvi
B.13 Nose Landing Gear and Doors - Main Components. . . . . . . . . . . . . . . . . . . . . . 95
B.14 Steering System - Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
B.15 Total Air Temperature Sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
xvii
xviii
Acronyms
A/C Aircraft. 12, 13, 44
ACARS Aircraft Communications Addressing and Reporting System. 4, 57
ACF Autocorrelation Function. 58
ACMS Aircraft Condition Monitoring System. 5
ADS Air Data System. 33
AFDAU Auxiliary Flight Data Acquisition Unit. 11
AGS Analysis Ground Station. xv, 12–17, 27, 29, 30
AHM Aircraft Health Monitoring. 3–5, 30
AIRMAN AIRcraft Maintenance ANalysis. 4
AMS Air Management System. 38
AOA Angle Of Attack. 33, 48, 66
AOG Aircraft On Ground. 2, 65
AOM Aircraft Operations Manual. 33
APU Auxiliary Power Unit. 34–36, 52, 57, 58, 62, 75–77
ARINC Aeronautical Radio Incorporated. 8–13, 27, 43
ASCII American Standard Code for Information Interchange. 16
BCD Binary Coded Decimal. 9, 10
CAS Crew-Alerting System. 57
CMC Central Maintenance Computer. 4, 57, 67
CSV Comma Separated Values. xiii, 16, 17, 27, 29
CVR Cockpit Voice Recorder. 10
xix
DAR Data At Rest. 12
DMU Data Management Unit. 11
DVDR Digital Voice and Data Recorder. 10
EGT Exhaust Gas Temperature. 34–36, 52, 57, 58, 62, 75–77
EICAS Engine-Indicating and Crew-Alerting System. 4, 43, 44
ERJ Embraer Regional Jet. 5
FADEC Full-Authority Digital Electronic Control. 32, 34, 41–43
FDR Flight Data Recorder. 10, 12
FF Fuel Flow. 30, 41
FHDB Fault History DataBase. 30
FOQA Flight Operational Quality Assurance. 12, 13
GSE Ground Support Equipment. 11, 12
GUI Graphical User Interface. 50, 52, 54
HIL Hold Item List. 69, 73
HPSOV High-Stage Shut Off Valve. 38
IEVM Integrated Engine Vibration Monitor. 43
ITT Inter-Turbine Temperature. 30, 42
LPSOV Low-Pressure Shut Off Valve. 38
MAU Modular Avionics Unit. 43, 46
MEL Minimum Equipment List. 69
MFD Multi-Function Display. 46, 49
MOQA Maintenance Operational Quality Assurance. 12, 13
MRO Maintenance, Repair and Overhaul. 3–5
N1 Fan Rotor Speed. 12, 44
N2 Core Rotor Speed. 12, 30, 31, 41, 42
NAPRSOV Nacelle Pressure-Regulating Shut-Off Valve. 38, 70, 73, 74
xx
NLG Nose Landing Gear. 47, 48
OEM Original Equipment Manufacturers. 3, 4
PCMCIA Personal Computer Memory Card International Association. 11, 14, 27
PFD Primary Flight Display. 33
PM Predictive Maintenance. 3, 4
QAR Quick-Access Recorder. 10–12, 14, 15, 27, 32, 36, 39, 40, 49
R R Programming Language. 27, 30, 50, 51, 59–63, 80
RPK Revenue Passenger Kilometers. 1
SAGEM Société d’Applications Générales de l’Electricité et de la Mécanique. 16
SDI Source/Destination Identifier. 9
SSM Sign/Status Matrix. 8, 9
TAT Total Air Temperature. 48, 49
WPS Words Per Second. 12
xxi
xxii
Chapter 1
Introduction
1.1 Motivation
The invention of the airplane has changed the way people live and experience the world. The major
conflicts of the 20th century pushed the aviation industry to vastly improve techniques for design and
construction, motivated by government subsidies and demands for new and better aircraft.
Over time, the aviation industry has been adapting to the seemingly never-ending changes of the
market and has proved to be resilient to external shocks while maintaining a strong and consistent
passenger traffic growth (Figure 1.1).
Figure 1.1: World Annual Traffic, in Revenue Passenger Kilometers (RPK) [1970-2016] [1].
Nowadays, air travel is no longer a luxury and the decrease in the cost of flying leads to a very
competitive market with low profit margins. In this sense, airline companies must implement strict man-
agement strategies if they wish to survive in such a competitive environment. The emergence of new
technologies compelled the airline industry to minimize its operating costs while improving profitability in
rapidly changing conditions. A major part of the financial problems is usually originated from the cyclical,
seasonal and ultimately unpredictable behaviour of demand. However, if correctly scheduled, mainte-
nance costs have proven to be one of the most reasonably controllable costs of all operating costs [2],
1
even though delays and unforeseen corrective maintenance procedures are still the major uncontrollable
components in the management process.
“Aircraft maintenance is all actions that can restore an item to a serviceable condition, and consist
of servicing, repair, modification, overhaul, inspection and determination of condition” [2]. It can be
classified as corrective maintenance, preventive maintenance or predictive maintenance. In corrective
maintenance, the actions performed are the result of a failure and are meant to restore a component
to a satisfactory condition. Also known as unscheduled maintenance, corrective maintenance provides
correction of a known or suspect malfunction or defect. Preventive maintenance, or scheduled main-
tenance, is based on actions undertaken at defined intervals to retain a component in a serviceable
condition by the means of systematic inspection, detection and replacement of wear out items [2]. Fi-
nally, predictive maintenance uses operational data gathered from the aircraft’s systems to assess the
condition of a given system and schedule maintenance activities on as needed basis. Preventive and
predictive maintenance allow companies to prevent imminent failures that could compromise the opera-
tion in case of an Aircraft On Ground (AOG) which can lead to high financial consequences.
The maintenance costs associated with the operation of an aircraft varies with its age. According
to A. Cook [3], new aircraft have relatively low costs in terms of airframe maintenance. However, these
costs rise steadily and level off at around 5 years of usage. From this point forward, an aircraft has a
steady and predictable maintenance cost, which ends up rising again after 15 years, due to airframe
and components ageing. Since the fleet of Portugália Airlines presents an average age of 5.6 years,
with the youngest aircraft being 4.2 years old and the oldest 6.7 years old, we are at a point where
most of the fleet has transitioned to the relatively predictable phase maintenance-wise. This allows
for more flexibility in terms of component inventory management, since fewer spare parts are needed
to account for unpredictable failures. Nonetheless, unforeseen failures still occur on a frequent basis
and the reduction of these incidents means companies must adopt more sophisticated and up-to-date
strategies that make use of data gathered from the on-board systems of the aircraft.
The latest aircraft in the market are equipped with technologies capable of delivering an unprece-
dented collection and transmission of data (Figure 1.2).
Figure 1.2: Growth in Aircraft Data Acquisition, modified from [4].
2
“Big data - the mining, analysis and exploitation of seemingly infinite reams of information - is in-
creasingly commanding the attention of top executives and military officials” [4].
This surge of operational and maintenance data could lead to major changes in the field of Predictive
Maintenance (PM). Nowadays, the big players in the aviation industry such as the Original Equipment
Manufacturers (OEM), operators and Maintenance, Repair and Overhaul (MRO) companies are adopt-
ing and investing in big data capabilities - mainly concerning Aircraft Health Monitoring (AHM) and
Predictive Maintenance systems.
According to a survey carried out by Oliver Wyman [5], big data in commercial aviation has already
moved past the early adopter phase for some applications; a majority of the respondents report the
implementation of AHM and PM systems on at least a modest scale (Figure 1.3).
Figure 1.3: Adoption of AHM and PM techniques, obtained from [5].
The first tangible impacts of the implementation of AHM and PM systems are beginning to be seen
by airline companies and MROs who report measurable gains in reliability and reduced maintenance
costs, particularly on engines (Figure 1.4).
The survey results presented in Figure 1.3 show a reality where nearly half of the operators surveyed
do not either rely on Aircraft Health Monitoring or Predictive Maintenance. These numbers could be the
result of data-management challenges due to old and often incompatible internal information technology
(IT) systems within airlines. This could also be explained by the fact that less than 50% of the global
aircraft fleet has the advanced systems necessary to collect and report all the data required to perform
an adequate analysis.
Although the aviation industry is still sceptical about the positive impact big data and predictive main-
tenance will have in the short term, “the industry is approaching an inflection point when it comes to
data-driven programs” [4].
3
Figure 1.4: Effects of the adoption of AHM and PM techniques according to survey respondents, ob-
tained from [5].
Nowadays, the aviation industry major OEMs already offer solutions for AHM software that imple-
ments predictive maintenance functionalities. Boeing and Airbus signed agreements with Microsoft and
IBM to provide IT infrastructure in order to speed up the development of analytical capabilities. Accord-
ing to Richard Brown [6], 2016 witnessed the entrance of the large MRO integrators in the data analytics
market which reflects the recent interest of this segment in AHM systems.
Boeing’s Airplane Health Management software gives airlines insight into the condition of airplanes
in the sky, providing in-flight access to data that allow preparation for the airline to minimize or eliminate
delays through advance preparation for maintenance procedures. This tool also supports long-term
fleet-reliability programs by helping airlines identify and respond to faults before they occur. This sys-
tem, similarly to the ones created by other big OEMs, benefits from the fact that it provides fleet-wide
information aggregated from other operators, which can be used to determine, for example, the effective-
ness of particular maintenance actions in fixing problems, helping airlines operate at the highest levels
of reliability and efficiency [7].
AIRcraft Maintenance ANalysis (AIRMAN) is a software tool designed by Airbus to optimise the
maintenance of its fleet. Similarly to Boeing’s AHM software, AIRMAN monitors the health of an airplane
and communicates fault or warning messages if registered through its on-board maintenance system,
placing an emphasis on early detection of abnormal behaviour [8].
AHEAD-PRO is a service provided by Embraer that makes use of the Aircraft Communications Ad-
dressing and Reporting System (ACARS) to send error messages in-flight from the Central Maintenance
Computer (CMC) and Engine-Indicating and Crew-Alerting System (EICAS) to the airline’s operations
center. The information is also transferred to the Embraer Customer Centre in Embraer’s headquar-
ters via the internet. This service is held on dedicated servers and makes use of QAR/DVDR data to
4
supplement its aircraft health monitoring system [9].
Other predictive MRO tools that exist in the market are Aircraft Condition Monitoring System (ACMS)
by SAFRAN [10]; Air France KLM Engineering & Maintenance developed “Prognos” [11] and Lufthansa
Technik launched “Condition Analytics” [12].
1.2 Objectives
The purpose of this dissertation is to develop an application that performs a trending analysis on several
systems of the Embraer Regional Jet (ERJ)-190/195 fleet of Portugália Airlines. The application should
be able to monitor key parameters of a given system and produce an alert in case an abnormal tendency
is detected. This Aircraft Health Monitoring program, designed to be used in the context of predictive
maintenance, focuses on the identification of unusual patterns of data that reflect system degradation
or faults so corrective actions can be undertaken, thus promoting a more reliable and cost-effective
operation.
1.3 Thesis Outline
This document is divided into five chapters. The first (current) chapter describes the motivation behind
this dissertation, contextualizing this work in the environment it was designed to operate at. In this chap-
ter, we also address the objectives we intend to achieve and present an overview of the thesis structure.
The second chapter provides some background on the subjects that will be discussed later, to help us
understand some key concepts and principles behind the methodologies used in the application. The
general characteristics of the E190 are presented, along with its recording system and on-board com-
munication protocols used to transmit and store information. We will review some important properties
of a flight data analysis software which will be used in our work, Analysis Ground Station, and also pro-
vide some insight on the data mining techniques that will be applied later on. Chapter three describes
the entire implementation process, including the data migration operations, the methodologies used to
monitor each system and the graphical user interface design. An in-depth explanation of the system
trend analysis is made, as this feature represents one of the most important aspects of this applica-
tion. In chapter four we showcase the results of the system trend analysis algorithms, providing some
examples and case studies that simulate the performance of this AHM tool. Finally, in chapter five, we
reflect upon the results obtained and elaborate on the conclusions that were made along this thesis. We
will also discuss future developments and present our suggestions to improve this tool and expand its
functionality.
5
6
Chapter 2
Background
2.1 Embraer E190
In this section, we will present the general characteristics of the E190 and its recording system, respon-
sible for collecting the data that we will later analyse. We will also address the on-board communication
protocols used to transmit and store data, which we believe is quite relevant given the data-driven nature
of this application.
2.1.1 General Specifications
The Embraer E190 is a narrow-body medium-range twin-engine jet airliner, capable of carrying a maxi-
mum of 118 passengers on a 2-class configuration (E190-200). It is powered by two turbofan CF34-10E
engines from General Electric, providing up 20,000 pounds of thrust each. This aircraft is manufactured
by Brazilian aerospace conglomerate Embraer and is still under production. The E190’s first flight was
in 2004 and more than 600 units were delivered up to date. The general specifications of the E190-100
are listed in Table 2.1.
Table 2.1: Embraer E190-100 General Specifications [13].
General Specifications
Engine 2 × General Electric CF34-10E
Power 2 × 20,000 lbf
Avionics Honeywell Primus Epic EFIS
Max Cruise Speed Mach 0.82
Service Ceiling 41,000 feet
Range 4,537 Km
Seating Capacity 106 (2-class)
Fuselage Length 36.24 meters
Fuselage Diameter 3.01 meters
Wingspan 28.72 meters
Maximum Take Off Weight (MTOW) 50,300 Kg
7
The current fleet of Portugália Airlines is composed by 9 Embraer E190 (E190-100) and 4 Embraer
E195 (E190-200). These two variants have 95% of systems commonality [14]; the E195 is fundamentally
similar to the E190-100 but with a longer fuselage which translates into 3 extra rows of seats (12 seats).
For the purpose of this thesis and from this point forward, all mentions of E190 will refer to the E190-
100 variant since the differences between the two variants are minor in the context of this work and we
consider they do not justify further comparisons.
2.1.2 Data Protocols

The data to be analysed is obtained from airborne recording systems which include units that record,
store and compute data. The recording system collects voice and flight parameter data from different
systems. This data is recorded and kept for future analysis of results.
In the Embraer 190/195, the communication between the main systems is specified by the ARINC-
429 protocol. The format of data stored in the different recording units on-board the aircraft is based
on the ARINC-717 specification. Aeronautical Radio Incorporated (ARINC) is a major company that
develops and operates systems and services to ensure the efficiency, operation, and performance of
the aviation and travel industries [15].
ARINC-429
This specification establishes how avionics equipment and systems communicate on commercial air-
craft. It defines the electrical mapping characteristics, the structure of the words and the protocol nec-
essary to establish bus communication [16].
The ARINC-429 protocol does not define how the data is stored in memory but rather how it is
transmitted. It employs unidirectional transmission of 32 bit words over two wire twisted pairs. ARINC-
429 data words are always 32 bits and typically use the format shown in Table 2.2.
Table 2.2: ARINC-429 Word Format [16].
The ARINC-429 data word is made up of five fields:
1. Parity (P): ARINC-429 defines the most significant bit of the data word (bit 32) as the Parity bit,
which constitutes one of the simplest forms of error detecting in communications. This protocol
uses odd parity, meaning that, for 31 out of the 32 bits that make up a word (excluding the parity
bit), if the number of bits with the value of 1 is even, the parity bit value is set to 1, making the total
count of 1’s in the whole set an odd number. Subsequently, if the receiving entity verifies that the
specification is not met, it discards this word for it is invalid. This method is only effective when the
number of incorrect bits is an odd number.
2. Sign/Status Matrix (SSM): Bits 31-30 are used to indicate sign or direction of data, or report
source equipment operating status and is dependant on the data type. Depending on the word’s
8
label, which indicates what type of data is being transmitted, the SSM field can provide different
information. The status coding for the different data types is represented in Table 2.3.
Table 2.3: Status/Sign Matrix - Sign and Status Coding [16].
Bit Status Coding

31 30 BCD BNR Discrete
0 0 Plus, North, East, Right, To, Above Failure Warning Normal Operation
0 1 No Computed Data No Computed Data No Computed Data
1 0 Functional Test Functional Test Functional Test
1 1 Minus, South, West, Left, From, Below Normal Operation Failure Warning
3. Data: ARINC-429 defines bits 29-11 as the word’s data information. As previously mentioned, this
specification supports different data types, those being:
• Binary Coded Decimal (BCD): this format uses 4 data fields to represent each decimal digit,
up to 5 digits (Table 2.4). The most significant sub-field (bits 29-27) only contains 3 digits
since the data field is limited to 19 bits; meaning this sub-field can not represent a decimal
digit if its value is greater than 7 (23 = 8). In that case, bits 29-27 would be padded with
zeros and the second sub-field (26-23) would become the most significant digit; this would
only allow the representation of 4 decimal digits. The sign of the value is presented in the
SSM field.
Table 2.4: Binary Coded Decimal Word Format [16].
• Binary (BNR): Data is stored as a binary number; Bit 29 is used as the sign bit in complement
of two - with the value of 1 indicating a negative number, South, West, Left, From or Below
and 0 indicating a positive number, North, East, Right, To and Above.
• Discrete: This data can be made up of BNR and/or BCD data, or as individual bits represent-
ing specific equipment conditions. If a parameter can be encoded in one bit (i.e., two states),
a single word can store information about up to 19 parameters. AIR/GROUND, ON/OFF,
OPENED/CLOSED, ENGAGED/NOT-ENGAGED, NORMAL/HIGH-PRESS and
TRUE/FALSE are some examples of the sort of information that can be represented by indi-
vidual bits - often used to describe the position of valves, doors, buttons, etc.
4. Source/Destination Identifier (SDI): Bits 10-9 are used to identify which source is transmitting
the data or by multiple receivers to identify which receiver the data is meant for. In special cases,
when a higher resolution is required, these bits may be added to the data field instead of using
them as an SDI field. When used as an identifier, the SDI is interpreted as an extension of the
word’s Label.
9
5. Label: This field is used to identify the word’s data type (BCD, BNR, Discrete) and can contain
instructions or data reporting information. Also known as the Information Identifier, the Label is
expressed as a 3 digit octal number. The Label is always sent first in an ARINC-429 transmission
and is a mandatory field, as well as the Parity Bit.
ARINC-717
The ARINC-717 protocol specifies the Flight Data Recorder (FDR) output format and defines how data
is stored in the different on-board recording devices. It consists in a continuous data stream of Harvard
Bi-Phase encoded 12 bit words which is encoded in frames [15]. A frame represents four seconds of
flight data and contains information collected by the avionics systems in that time frame. Each frame
contains the same data at a different snapshot in time and is divided in four subframes; each represents
one second of flight data. At the start of each sub-frame there is a unique sync word that is used by the
receiver to synchronize with the incoming data.
In the E190, a sub-frame is composed by 1024 words of 12-bits each (Figure 2.1).
Figure 2.1: ARINC 717 Frame Structure.
The ARINC-717 was introduced to achieve higher data security, in contrast to the ARINC-429 which
contains detailed and explicit information about the data it carries.
2.1.3 Recording System
The recording system is mainly divided in two subsystems: the Digital Voice and Data Recorder (DVDR)
and the Quick-Access Recorder (QAR).
The DVDR system maintains record of the critical flight data - FDR - and voice communications in the
cockpit area - Cockpit Voice Recorder (CVR). The FDR records the parameters required to determine
accurately the aircraft’s flight path, speed, attitude, engine power, configuration and operation [17]. Com-
monly known as the black-box, this electronic recording device’s purpose is to facilitate the investigation
of aviation accidents and incidents. The data collected by this system can help investigators determine
10
whether a certain accident was caused by an external condition (e.g. meteorological event), pilot error
or by a fault in the airplane.
Quick Access Recorder
The QAR is a piece of equipment that records a large amount of data which can be either ARINC-717
or ARINC-429. It allows easy access to recorded data by quick removal of the QAR card (Personal
Computer Memory Card International Association (PCMCIA)) and it is installed on the equipment rack
in the aft avionics compartment (Figure 2.2).
The QAR is composed of two main blocks [18]:
• The Auxiliary Flight Data Acquisition Unit (AFDAU), responsible for determining the incoming trans-
mission rate and collecting ARINC-717 data to make it available for the Data Management Unit
(DMU) block. It receives status information from various units of the aircraft in the form of individ-
ual data elements (parameters).
• The DMU, which is responsible for the collection of ARINC-429 data, its conversion into ARINC-
717 data and its recording into the QAR card. If the number of recorded bits from a parameter in
ARINC-429 exceeds the size of the word in ARINC-717 (12 bits), more words are assigned.
Figure 2.2: Quick-Access Recorder System - Overview [18].
The QAR is energized as soon as the aircraft is powered ON. The unit starts and stops the recording
process in accordance with the START/STOP logic programmed by the operator through the software
tool named Ground Support Equipment (GSE). The recording process begins when at least one of the
following conditions is met:
11
• Left Fan Rotor Speed (N1) > 10%
• Right N1 > 10%
• Left Core Rotor Speed (N2) > 10%
• Right N2 > 10%
• Air/Ground = FALSE (aircraft is airborne)
Essentially, two kinds of data frames can be recorded at the QAR card: an exact copy of the FDR
data frame, at 512 Words Per Second (WPS) and a programmable data frame, with parameters and rate
programmable by operator. The rate of the programmable frame can be selected from 64 WPS to 2048
WPS. Both data frames can be recorded in the QAR card and the memory space dedicated for each
one is programmable by GSE.
As previously mentioned, the data stored in the QAR unit can be accessed by quick removal of the
QAR card. This is done by specialized personnel that remove the card from the QAR unit, upload the
data to the server and then place it back in the airplane. Currently, this is done every couple of days,
meaning that the engineering and maintenance departments only have access to QAR data up to the
last manual upload.
The PCMCIA card contains Data At Rest (DAR) according to the format of the ARINC-717 protocol.
This information is later decoded and rebuilt in the Safety Management department using dedicated
software - Analysis Ground Station. From this point forward, it is possible to fully reconstruct a flight.
2.2 Analysis Ground Station Software
The Analysis Ground Station (AGS) software, used in Portugália Airlines’ Safety Management depart-
ment, is a flight data analysis tool developed by SAGEM to help airlines improve operational efficiency
and facilitate access to information. Its main features include report generation from automatic and
manual data selection for Flight Operational Quality Assurance (FOQA) and Maintenance Operational
Quality Assurance (MOQA), import/export functions and flight analysis.
In the scope of this dissertation, AGS will be responsible for decoding the data frames which contain
the flight parameters, recorded under the ARINC-717 specification, and then export the flight data in
a format it can be easily usable by our application. This saves us a significant amount of time as
programming this tool to recognize this protocol means we would have to specify the location of each
one of the several hundreds of parameters in the data frame, as well as their ARINC-429 characteristics.
A. Simões [19] describes the procedure behind the flight data decoding process of TAP’s A320-200 fleet.
Data frames usually vary according to Aircraft (A/C) type, its registration and recording device used.
Fortunately, Portugália Airlines owns a homogeneous fleet, meaning only one data frame specification
is needed.
12
2.2.1 Overview
Given the extensibility of AGS to different aircraft types and models, one must first programme the air-
craft’s database before conducting any further analysis. The programming of an A/C database version,
which is the configuration used by the software to adapt its flight data analysis to a specific aircraft, is
divided in two main parts [20]:
1. Decoding Frame: used to convert parameters in engineering values. It includes the equipment
list, parameter list, data frame and procedures for additional parameters computation. These
procedures are used to calculate the additional parameters, often called ground parameters, based
on flight data retrieved from the aircraft.
2. Procedures for Automatic Flight Analysis:
(a) Flight Operations: these include studies to identify and correct nonconformities during flight
operation for safety purposes, inserted in the FOQA program context.
(b) Maintenance: within the scope of the MOQA program, these procedures were implemented
to perform computations over flight data for maintenance purposes, providing the mainte-
nance department aircraft monitoring capacity.
Once the decoding frame is programmed, AGS can then convert the recorded flight data, which is
stored in binary format under the ARINC-717 specification, into its corresponding engineering values.
At this point, the software has enough information to execute the procedures mentioned above. These
procedures are essentially blocks of code, written in a dedicated programming language, that contain a
set of instructions and test conditions that allow the software to identify key segments of flight data. Since
the procedures for additional parameters calculate parameters that are later used in flight operations and
maintenance procedures, the former are executed first. In the following section, we will exemplify how
AGS computes the parameter that specifies the several flight phases that constitute a flight, which will
be quite useful later on.
After the database version is configured, AGS is in condition to perform the automatic analysis, which
includes:
• Flight Identification: date and hour, flight number, origin and destination.
• Decoding: conversion of recorded parameters into engineering values.
• Computation of Additional Parameters: calculation of the additional parameters based on the

data previously decoded.
• Storage: to enable future statistical analysis or flight replays, all data must be stored in the
database. This includes the raw data, the reports generated and other results of the flight analysis.
The automatic analysis is critical to the day-to-day operations of the Safety department of Portugália
Airlines, which serves as a center for safety related activities, acting as a focal point for safety reports
13
and information, and providing methodological guidance and expertise on safety related operational
issues to line managers [21]. Therefore, on a daily basis, an automatic analysis is performed over the
most recent flights.
Figure 2.3 provides an overview of AGS’s diverse activities. In the context of this work, the importance
of AGS lies in one of its exporting capacities - data files for dedicated interfaces. This feature will give
our application access to hundreds of recorded parameters of fully reconstructed flights, although the
exporting process must be done manually.
Figure 2.3: AGS Overview, obtained from [22].
Analysis Ground Station supports different forms of data transferring units, from the more antique
ones, such as tapes or optical disks, to more modern ones, that make use of wireless technology. At
the moment, Portugália Airlines makes use of the PCMCIA card to transfer QAR data from the aircraft
to the workstation, which requires trained personnel to remove and substitute the cards from the QAR.
14
2.2.2 Flight Phase Computation
The separation of a single flight into multiple phases allows to easily allocate our focus directly to the
relevant stages of the flight, avoiding further calculations and thus reducing computation time.
AGS calculates the several flight phases by analysing QAR parameters and identifying key moments
where specific conditions are satisfied (Figure 2.4). This procedure lies in the additional parameters
computation. It is worth noting that not every flight contains all flight phases, since some reflect unusual
manoeuvres that are often the result of unplanned and undesired situations, such as rejected take-off or
go around.
Figure 2.4: Flight Phases, modified from [22].
The results of these calculations are later stored in the FLIGHT PHASE parameter with a numerical
coding that unequivocally identifies every flight phase. Figure 2.5 illustrates an example of the progres-
sion this parameter takes, over an entire commercial flight.
Figure 2.5: FLIGHT PHASE parameter progression over a flight.
15
For instance, AGS will consider the aircraft is in cruise, phase 8 in Figure 2.4, when the absolute value
of its vertical speed is less than 300 ft/min during 15 seconds, providing it is above the reference altitude
and the current flight phase is climb. As soon as this condition is satisfied, at around 17:21 in example
from figure 2.5, the algorithm will consider the aircraft is in cruise and will only advance to the next flight
phase, descent, if the aircraft is losing altitude and its vertical speed is higher than 420 ft/min during 5
seconds or if its altitude is lower than the reference, which happens at around 18:36. J. Freitas [20],
which studies and implements algorithms for in-flight performance analysis, lists the transitions between
the remaining flight phases and the associated conditions that were implemented in the procedure.
Table 2.5 contains the numerical mapping of the flight phases, as set by the software provider, Société
d’Applications Générales de l’Electricité et de la Mécanique (SAGEM).
Table 2.5: Flight Phases - numerical mapping by SAGEM standards [22].
Phase Number Flight Phase

0 Illegal
1 Engine Stopped
2 Taxi Out
3 Take-Off
4 Rejected Take-Off
5 2nd Segment
6 Initial Climb
7 Climb
8 Cruise
9 Descent
10 Approach
11 Final Approach
12 Landing
13 Go Around
14 Taxi In
2.2.3 Data Export
As previously mentioned, AGS provides flight exporting functionalities that allow the user further statisti-
cal analysis outside AGS’s scope. This feature is of great importance to our work, since it is responsible
for feeding flight data to our application that otherwise would have to be decoded. AGS offers the
possibility of exporting files in three different formats: binary, American Standard Code for Information
Interchange (ASCII) and Comma Separated Values (CSV). Conveniently, R language includes built-in
functions for data importing in CSV format, which organizes the information in dedicated data structures,
facilitating its readability and accessibility later on. This way, every flight is separated into a distinct file
in an easily readable format. Among the parameters recorded on-board and computed on ground, AGS
contains thousands of parameters, and exporting all of them in every flight would take an unreasonable
amount of time, occupy unnecessary memory and reduce the performance of our application in terms
of computation time. Therefore, we need to select the set of parameters we want to export beforehand,
according to our necessities.
16
Other important aspect of the parameter exportation is its sampling rate. Each parameter has its own
frequency, according to its relevance within the aircraft’s systems or for flight data analysis. The limited
space in the messages used in the communication between aircraft’s systems means it is not possible
to record every parameter at the maximum rate. For instance, if we were to export a certain flight with a
sampling rate of 8 Hz, every row would consist of a sample and every second of data would correspond
to 8 rows. In this case, parameters with a sampling rate of 8 Hz would appear in every row, in contrast to
a parameter sampled at 4 Hz, which would appear every 2 rows. Refer to S. Ribeiro [23] for an example
considering a sampling rate of 8 Hz. Most parameters are recorded at the rates of 1 Hz and 0.25 Hz,
meaning they would appear once every 8 and 32 samples, respectively. Most of the parameters that we
will be exporting are sampled once every second or four seconds, although a sampling rate of 0.25 Hz
would mean the loss of a considerable amount of information. As such, we decided to export the flights
with a sampling rate of 1 Hz, as to decrease file size and processing time. We believe that the information
lost in parameters with higher sampling frequencies does not justify increasing the parameter exporting
rate any further, at least in the scope of our work.
Table 2.6 illustrates an example of the parameters exported from AGS with a sampling rate of 1Hz.
Table 2.6: Example of the contents of an exported CSV file - viewed in R Studio.
The example above presents the content of 10 parameters over 15 seconds of flight data. The
first two parameters, TIME R and DATE R, exist in every exported flight and represent the time and
date, respectively. In this example it is possible to distinguish parameters with different sample rates.
NLG POS 1 and STEER HWC contain a sample once every four samples, meaning its sampling rate is 0.25
Hz. NLG POS 2, TAT 1 and TAT 2 are sampled once every two seconds, thus presenting a 0.50 Hz rate.
The rest of the parameters are sampled at a minimum of 1Hz, since it is possible they are recorded at a
higher rate, but we would not be able to tell as we exported them at a lower sampling rate.
17
2.3 Data-Mining Techniques
Given the sheer amount of data available for analysis, a problem arises: how to extract relevant infor-
mation out of this seemingly never ending stream of data. Realistically, only a small portion of this data
will ever be used since the volumes are, quite often, too large to handle and the data structures prove
to be too complex to be analysed effectively. This is often due to a primary effort to implement data sets
focusing on issues such as storage efficiency, while lacking a plan on how to use and analyse that data
later on [24].
In today’s competitive world, the ability to extract valuable knowledge hidden in this data and to work
on that knowledge has progressively become more important. This can be achieved through the process
of applying computer-based methodologies to discover intelligence from data, called data mining.
“Data mining consists in an iterative process within which progress is defined by discovery, through
either automatic or manual methods. Data mining is most useful in an exploratory analysis scenario in
which there are no predetermined notions about what will constitute an “interesting” outcome” [24]. It
consists in the search for new, useful, and significant information in seemingly unintelligible reams of
data, by balancing the knowledge of human expertise in problem statement and goal description with
the search potential of a computer.
In fact, data mining is not simply a collection of isolated tools, but rather a whole process where
the problem of discovering or estimating data dependencies is only one step (Figure 2.6). The prob-
lem statement is a crucial step that requires domain-specific experience and combines the application
domain with the data mining model. The next steps include data collection and its pre-processing,
responsible for feeding the following stages of the process with refined and meaningful data.
The entire data mining process should be highly interactive, because even the most powerful data
mining methods may present inconclusive or invalid data if the problem statement is not meaningful.
Figure 2.6: Data Mining Process - Overview [24].
In practice, there are two main forms of data analysis that can be used to extract models which
describe important data sets or to predict future data trend: descriptive and predictive [25]. The former
is focused on discovering patterns which describe the data in order to be interpreted by humans, based
18
on data aggregation. The latter makes use of variables or entries in the data set to predict future or
unknown values of other variables, employing forecasting techniques and statistical models. As such,
data mining tasks can be classified into one of the following two categories:
• Descriptive Data Mining: focuses on the production of new, meaningful information based on the
data available, providing insight into the past. Its goal is to understand the analysed system by
exposing patterns and connections in data sets.
• Predictive Data Mining: formulates the model of the system described by the given data set,
providing estimates about the likelihood of a future outcome based on previous data. Afterwards,
this model can be used to perform classification, estimation, prediction, or other related activities.
The relative importance of these data mining approaches may vary significantly, according to the
particular application. On a first evaluation, it seems that a descriptive data mining approach would be
more suitable in our application, since our main focus is not to predict the future behaviour of systems
but rather to identify abnormal patterns in the recently collected data.
Users often have no idea which kind of patterns in the data present an interesting outcome, so it is
important to have a data mining system capable of discovering multiple kinds of patterns to accommo-
date different applications or expectations [25]. Data mining functionalities are used to specify the sort
of patterns to be discovered in data mining tasks.
2.3.1 Data Mining Functionalities
J. Han and M. Kamber [25] distinguish several data mining functionalities and the types of patterns they
can expose. We will elaborate on them and try to identify the most appropriate one in our context. As
such, we can differentiate the following functionalities:
1. Characterization and Discrimination: This analysis is based on the concept or class used to
associate data. It can be useful to describe individual classes/concepts in succinct, summarized
and explicit terms. These descriptions can be obtained in two ways: via data characterization,
which summarizes the data of the target class in general terms, or data discrimination, responsible
for comparing the target class with a set of comparative classes.
2. Association Analysis: This approach is associated with the discovery of association rules which
indicate attribute-value conditions that occur together repeatedly in a given data set. In this anal-
ysis, the association is usually made between several attributes, where one tries to identify an
outcome based on the conjunction of attribute conditions. Considering the attribute-value pairs X
and Y , where “X1 ∧ ... ∧ Xi → Y1 ∧ ... ∧ Yj ”, the association rule X ⇒ Y is interpreted as “if a given
input tuple satisfies the conditions in X, it is likely to satisfy the conditions in Y ”.
3. Classification and Prediction: The process of assigning objects to one of several predefined
categories is called classification. This is done by finding a classification model that describes and
distinguishes data classes, which is later used to predict the category of objects whose category
19
is unknown. This model is obtained from the analysis of a training data set, i.e., objects whose
category is known. It may be presented in many forms, such as classification rules, decision trees,
mathematical formulae or neural networks.
Prediction, however, focuses on predicting missing or inaccessible data values within objects,
rather than the object’s category. Often referred to both data value and category prediction, this
analysis is usually confined to data value prediction as to differentiate from classification.
A relevance analysis may be needed beforehand to indicate the object attributes that do not con-
tribute to the classification/prediction process, and so a correlation analysis is frequently used to
find whether any given pair of attributes is related or not.
This approach is often used in supervised machine learning algorithms, where prior knowledge
about the system is required.
4. Cluster Analysis: Also called data segmentation [26], cluster analysis aims at forming groups of
objects, called clusters, based on the principle of maximizing the intra-cluster similarity and mini-
mizing the inter-cluster similarity. This way, the algorithm will form clusters of objects, where objects
within a cluster present a high similarity in comparison to one another, while being very dissimi-
lar to objects in other clusters. This analysis is rather different from classification and prediction,
which focus on the categorization of data objects, since it analyses the data objects despite their
category. The analysis of clusters is commonly used in unsupervised machine learning problems,
where knowledge about the system is very little or non-existent and algorithms try to discover and
present structures in input variables.
5. Evolution and Deviation Analysis: This approach studies and describes trends for objects
whose behaviour changes over time. Evolution analysis models evolutionary trends in data, and
may be assisted by characterization, discrimination, association, classification, or clustering of time
series data. The distinct features of this analysis include time series data analysis, sequence/pe-
riodicity pattern matching, and similarity-based data analysis.
A deviation analysis focuses on the differences between measured values and corresponding ref-
erences, such as previous data patterns or normative values. In a time-related data analysis, this
concept not only aims to model the evolutionary trend of data, but also identifies deviations that
occur over time as to describe their characteristics and find an explanation to the cause behind
them.
The data mining functionalities to be applied in our application should be capable of distinguishing
objects that are already defined, and whose variables consist in the multiple observations of system
behaviour over time (time series). By separating aircraft into distinct objects, we wish to obtain some
sort of distribution that allows to differentiate aircraft that present a normal behaviour from those whose
systems are at fault. This exclusively comparative approach should not require knowledge about the
particular aircraft’s systems.
20
When confronting our expectations with the data mining functionalities listed above, we believe some
of them go out of the scope of our application, since their predictive nature does not achieve the results
we are seeking. For instance, characterization and discrimination excel at describing objects in precise
terms, which is not relevant in our context since we already specify the set of objects and their content.
The association analysis provides an output estimation based on attribute-value conditions, assuming
there is a relation between the attributes that constitute the object. In our case, however, all attributes
represent the same quantity over time and show no clear relation between each other, which from
our point of view nullifies the purpose of this approach. The following functionality, classification and
prediction, is not adequate in our context, since its supervised classification nature requires prior system
knowledge in order to be taught. We believe a conjunction between the two last functionalities, cluster
and evolution analysis, could yield interesting results since their specificities are in line with what we
want to obtain.
Performing cluster analysis to a time series data set could allow to pinpoint the objects whose data
sets show unusual patterns in comparison with the other objects. This similarity-based data analysis
highly relies on a successful implementation of a cluster analysis algorithm. As such, in the following
section, we will discuss its particularities and overall methodology.
2.3.2 Cluster Analysis
In this section, we will discuss the methodology behind a cluster analysis, identifying the methods and
metrics we have decided to apply in our work. As previously mentioned, this analysis consists in the
partitioning of a data set into subsets, or clusters, so that the data in each cluster present some common
characteristic. Although the notion of a cluster is not precisely defined, there is a common agreement
that it consists in a group of data sets [27]. The goal of clustering is then to maximize between-cluster
variance while minimizing within-cluster variance. This can be achieved in many different ways, since
different methods and distance metrics yield various results. Nevertheless, the standard procedure
behind most cluster analyses can be split into several steps, represented below (Figure 2.7).
Figure 2.7: Steps in Cluster Analysis [26].
In the following sub-sections, we will be discussing some of the clustering analysis steps shown
above, more specifically the ones that we consider as more relevant in the context of this application.
21
Object Selection
The output from a cluster analysis is a number of clusters that form a partition of the data set as well as
the subsets they include. Therefore, the objects should represent the entities we are looking to group.
As previously referred, the purpose of this analysis is to provide us insight into the behavioural
differences between the same system in different aircraft. As such, we decided to represent the different
aircraft as objects, where an object represents the characteristics of the system under analysis of that
particular aircraft. This way, by separating objects into groups with similar characteristics, we are forming
groups of aircraft whose systems behave similarly, as intended.
Variable Selection
The following step is to select the object’s variables, or attributes. These are the values that will be used
by the clustering algorithm to assess similarity between observations. In our context, these variables will
correspond to observations of the systems’ behaviour in key moments of the flight, where specific condi-
tions are satisfied. Over time, these observations represent the evolution of the system’s behaviour and
constitute the only information that is provided to the system trend analysis algorithm. In practical terms,
the objects will consist in a numerical array, chronologically ordered, where the variables correspond to
observations obtained from the most recent set of flights.
To exemplify, suppose we are analysing the behaviour of system A over the last 10 flights, within
a fleet of 5 aircraft. Let’s assume the property we want to monitor is the maximum value of a given
parameter of system A, parameter X. In this example, the objects would correspond to the different
aircraft and the variables to the maximum observed value of parameter X over the course of a flight.
A set of objects is often represented as an m by n matrix, where there are m rows, one for each object,
and n columns, one for each observation. This matrix is often called data matrix and is exemplified in
Table 2.7, where objects correspond to aircraft and variables to the measurements. For the purposes
of this example, the values below were randomly generated; for Aircraft 1 to 4, we generated integer
values in the interval [40 − 50] and for Aircraft 5, we considered the interval [70 − 80].
Table 2.7: Cluster Analysis - Data matrix.
Measurements
1 2 3 4 5 6 7 8 9 10
Aircraft 1 41 43 49 49 48 42 42 40 49 43
Aircraft 2 42 47 40 42 44 42 44 46 45 50
Aircraft 3 47 40 43 43 46 41 48 40 46 40
Aircraft 4 44 50 47 48 43 43 41 40 49 49
Aircraft 5 80 80 75 71 78 73 79 76 77 77
Once the system’s data matrix is obtained, we are in condition to move on to the following stage of
this process, that consists in the construction of the data structure upon which the cluster analysis will
operate, the dissimilarity matrix.
22
Dissimilarity Matrix
Even though cluster analysis often uses the original data matrix, many clustering algorithms, such as the
one we will implement, use a dissimilarity matrix to assess the degree of similarity between the individual
objects being clustered. This structure consists in a square matrix containing all the pairwise dissimi-
larities between the objects under consideration. For instance, if xi and xj are the ith and j th objects,
respectively, then the entry at the ith row and j th column of the dissimilarity matrix is the dissimilarity
value, dij , between xi and xj .
The attributes of the objects can be of different data types - binary, discrete and continuous - and can
be measured in different data scales, according to their nature. Data scales can either be qualitative,
such as binary variables, or quantitative, where the difference between values is meaningful, such as
height, width or other physical quantities [28]. The data type and scale are important factors since the
most effective clustering method depends on these characteristics. In the context of this dissertation,
the objects under analysis are discrete, since we consider a finite number of observations, and the data
scale is quantitative, as the observations represent physical quantities.
The next step concerns the approach used to determine the degree of similarity or proximity between
objects, since there are multiple ways of measuring this [29]. From Cichosz [30], we distinguish the
following proximity measures:
• Euclidean distance: based on the Pythagorean formula, this measure calculates the distances
between two points in Euclidean space. For instance, if we consider two points in Cartesian co-
ordinates, i = (i1 , i2 , ..., in ) and j = (j1 , j2 , ..., jn ), then the distance between them would be
p
dij = dji = (j1 − i1 )2 + (j2 − i2 )2 + ... + (jn − in )2 . In our context, the dimension of the Eu-
clidean n-space would correspond to the number of flights under analysis.
• Squared Euclidean distance: this metric makes use of the same equation as the Euclidean
distance metric, but does not take the square root. As a result, clustering with the Euclidean
Squared distance metric would be faster than clustering with the regular Euclidean distance.
• Manhattan distance: this metric calculates the sum of the absolute differences of the Cartesian
coordinates of two given points. Considering the same two points defined above, the Manhattan
Pn
distance between i and j would be dij = dji = k=0 |ik − jk |.
• Chebyshev distance: also known as the chessboard distance, this metric returns the greatest
difference between any two given coordinate dimensions of the two points. As such, the difference
between i and j would be determined as follows: dij = dji = maxk (|ik − jk |).
We believe that the metric that would yield better results is the Manhattan distance, since this metric
returns the sum of the differences between all the observations. This particularity would allow us to
obtain a cumulative error between all object observations. This way, behavioural differences between
systems would directly be considered in this quantity and the longer a degraded pattern persists, the
greater this value would be, as intended.
23
To exemplify, let’s consider the data matrix from Table 2.7. In this example, Aircraft 5 was purposely
assigned a higher set of values, as to verify how the methodology implemented distinguishes it from the
remaining objects. The Manhattan distance between objects Aircraft 1 and Aircraft 2, below represented
as AC1 and AC2 , would then be determined as follows:
10
X
dAC1 ,AC2 = |AC1k − AC2k |
k=1
= |AC11 − AC21 | + |AC12 − AC22 | + |AC13 − AC23 | + · · · + |AC110 − AC210 |
= |41 − 42| + |43 − 47| + |49 − 40| + · · · + |43 − 50|
=1+4+9+7+4+0+2+6+4+7
= 44.
Since this metric calculates the sum of the absolute differences between observations, then dAC1 ,AC2 =
dAC2 ,AC1 , which means the dissimilarity matrix will be symmetrical. Performing this calculation for every
other object configuration allows to obtain the dissimilarity matrix, represented in Table 2.8. To facilitate
the readability, we opted to hide the upper matrix triangle, since this data was simply a reflection of the
lower triangle data relatively to the main diagonal.
Table 2.8: Cluster Analysis - Dissimilarity matrix example.
Aircraft 1 Aircraft 2 Aircraft 3 Aircraft 4 Aircraft 5
Aircraft 1 0 - - - -
Aircraft 2 44 0 - - -
Aircraft 3 36 40 0 - -
Aircraft 4 26 34 46 0 -
Aircraft 5 320 324 332 312 0
The interpretation of this matrix is relatively straightforward. Higher dissimilarity values represent
more distinct objects, which is consistent with the data from Table 2.7. It is possible to observe the
significant difference between the dissimilarity values of Aircraft 5 in comparison with the remaining
configurations. Evidently, the dissimilarity value between the same object is zero.
Although this example illustrates a clear pattern difference between objects, we still need to imple-
ment a feature to allow the algorithm to autonomously identify and group objects according to their
behaviour, as most scenarios are not as clear as the example previously provided. The next step in this
analysis is then the selection of the clustering technique to apply to the dissimilarity matrix.
Method Selection
Although no clustering technique is universally applicable in uncovering patterns in multidimensional

data sets, the user’s understanding of the problem and the characteristics of the data, such as its type
and scale, present the best criteria to select the appropriate method [24].
24
According to Everitt et al. [27], Hansen and Jaumard [31], Jain et al. [32] and Jain and Dubes [33],
clustering techniques are generally classified as partitional clustering and hierarchical clustering, based
on the properties of the generated clusters. The former, known as agglomerative hierarchical clustering,
directly divides data points into a pre-defined number of clusters without hierarchical structure, while the
latter, called divisive hierarchical clustering, groups data with a sequence of nested partitions, either from
individual clusters to a cluster including all individuals or the opposite way [34]. Since we have already
separated our data set into objects, we now want the algorithm to group them according to their similarity.
Hence, we believe the agglomerative hierarchical clustering approach presents the characteristics we
are looking for.
2.3.3 Agglomerative Hierarchical Clustering
Agglomerative Hierarchical Clustering starts at the bottom of the hierarchy and, at each level, recursively
merges a given pair of clusters into a single cluster. This way, at every new level, a grouping is produced,
thus reducing the number of clusters. This “bottom-up” approach merges the most similar groups first,
with the selected pair consisting of the two groups with the smallest intergroup dissimilarity [26].
The merging process of a given pair of clusters, or the creation of a new cluster at a certain hierar-
chy level, relies on the definition of closeness between clusters. There are many ways of aggregating
clusters at any given step, either by merging individual objects together or by merging an object to an
existent cluster. This is defined by the linkage methods, which describe how inter-cluster dissimilarity is
measured. From Rencher [35], we distinguish the following strategies:
• Nearest-neighbour: also known as single linkage, this strategy defines the distance between two
groups as the distance between their closest elements, one of each group. This particularity leads
the algorithm to group together, at an early stage, relatively distant objects, due to the existence
of intermediate objects in the same cluster. Graphically, these clusters tend to present elongated
horseshoe-like shapes [26].
• Farthest-neighbour: this approach determines the distance between clusters based on the most
remote pair of elements of each group, as opposed to the previous strategy. This method is also
known as complete linkage and tends to form clusters of relatively close objects at an early stage,
which translates into circularly shaped clusters [26].
• Centroid: in this method, each group is considered and defined in Euclidean space and is re-
placed by the co-ordinates of its centroid. As such, the difference between clusters is the distance
between its centroids.
• Ward’s method: also called the incremental sum of squares method, this method makes use of
the within-cluster and between-cluster distances [36]. Based on the centroid approach described
above, Ward’s method minimizes the total within-cluster variance and, at each step, the pair of
clusters with minimum between-cluster distance are merged. In comparison with the centroid
method, this approach is more likely to join smaller clusters or clusters of equal size, since cluster
sizes have an impact in this approach [35].
25
Based on the characteristics of the linkage methods described above, we believe Ward’s method
is the best option for our application. Considering the fact that this method takes into account both
within-cluster and between-clusters distances means we will most likely obtain the most meaningful
data aggregation out of all methods.
The results of hierarchical clustering are usually presented in a dendrogram, which provides highly
interpretable and informative descriptions of the clustering structures in a graphical form. To exemplify,
we produced a dendrogram based on the data from the dissimilarity matrix from Table 2.8 (Figure 2.8).
Figure 2.8: Hierarchical Clustering - Dendrogram.
The root node of the dendrogram, at height zero, represents the entire data set, where each leaf node
is regarded as an object. In this example, the dendrogram is composed by 5 leaf nodes, one for each
aircraft. The intermediate nodes provide a description of the proximity between its objects or clusters.
The height of the dendrogram usually expresses the distance between each pair of objects/clusters. As
such, larger height differences between nodes reflects high between-cluster variance.
For example, the intermediate node that connects Aircraft 1 to Aircraft 4 is located at height 26, which
is consistent with the data from Table 2.8. This intermediate node was the first to be created since it
represents the fusion of the two most similar objects, whose dissimilarity value was minimum. A similar
scenario can be observed regarding Aircraft 2 to Aircraft 3, whose intermediate node is at height 40.
The following node connects the two previous nodes shortly after the previous connection, suggesting
a strong similarity between these two clusters. The final merge takes place at height above 400, which
is not unforeseen given the data differences between Aircraft 5 and the remaining. This height contrast
helps us understand the disparity between these objects without even requiring numerical data analysis.
Without any prior system knowledge, one could easily identify the two major groups of the previous
example: an individual cluster containing Aircraft 5 and a big cluster including the remaining aircraft.
However, we want to enable the application to reach this conclusion autonomously. This can be achieved
by cutting the dendrogram at different levels. If we provide the algorithm with a specific cutting height,
it can then arrange the clusters accordingly. In this example, a cut at height 200 would return the
cluster configuration previously mentioned (see red dashed line in Figure 2.8). The methodology used
to determine the optimal cut height for each scenario will be discussed in the implementation chapter.
26
Chapter 3
Aircraft Health Monitoring Program
The application was developed in R Programming Language (R), an open source programming language
and software environment focused on statistical computing and graphs. It provides a wide variety of
statistical (classical statistical tests, time series analysis, clustering, ...) and graphical packages, and is
highly extensible.
Although R facilitates data manipulation, calculation, and graphical display, it was also important that
the application to be developed was able to run in a web environment, in order to make it remotely
accessible to anyone in the company. Fortunately, R language provides a web framework solution,
Shiny, which is an open source R package/library capable of providing a powerful web framework for
designing highly interactive web applications.
3.1 Data Migration
In section 2.1.3 we explain where the data we will analyse is originated. The data collected by the
several airborne systems is stored in the QAR unit and accessible by the removal of the PCMCIA card.
Afterwards, this ARINC-717 data is uploaded to a server, in the form of a binary file, which can promptly
be accessed and decoded by the AGS software, located in the Safety Management Dep. (Figure 3.1).
The application we developed will make use of files exported from the AGS, in comma-separated
values format (CSV). Therefore, every time new flights are uploaded from the PCMCIA card to the
QAR data server, AGS must process every new flight and export those flights according to the QAR
parameters that we previously defined in an export template. This means that, if we want to extend the
analysis to other systems later on, we will most likely need to modify this template in order to include
the new QAR parameters. This limitation could be circumvented if, for every flight, we included the data
from every QAR parameter that the aircraft records and other parameters that are later calculated on the
ground in AGS, which would largely increase the size of every file. This would also cause further delays
in the application when new flights needed to be processed so we decided to solely export the QAR
parameters that were explicitly needed in the application. Tables A.1, A.2, and A.3 contain information
about all the exported parameters in the context of this work (appendix A).
27
Figure 3.1: Data Migration - Part I.
The flight database will contain all the Embraer E190/195 flights made by Portugália. Those files are
named in a way that will allow the program to extract key information about that specific flight simply
by checking the file name, since every flight consists in a separate file (Table 3.1). This specification
makes it possible to determine if a given flight has already been processed, by keeping track of the file
numbers which are unique to each flight, allowing the application to only analyse the newest flights in
that directory.
Table 3.1: File name specification - fictional flight.
Flight CS-PGA 20171016 235959 73733 TAP3101.csv

CS-PGA Aircraft Tail Number
20171016 Flight Date - 16 October 2017
235959 Recording Start Hour - 23:59:59
73733 File Number
TAP3101 Flight Number
28
3.2 Application Overview
Before getting into the specific systems that the application will monitor, and now that we already have
the desired data available, we will describe the overall structure of the application and its main functions.
Although the main application will be running in a browser environment, we created a script to be
executed on a daily basis, making use of the Windows Scheduler. This function will check for new
flights in the directory that contains the CSV files exported by AGS, process every new flight, conduct an
analysis based on the new data gathered and produce alerts if justified. This functionality assures the
application’s database is always up to date without the need of a manual flight database update, which
can still be done by the user at any time.
First off, we need to make sure our application only processes valid flights. We achieved this by
creating a function that filters not only invalid flights but also flights that have already been processed.
After changing to the flight database directory and checking that it is not empty, the function will open
a backlog file, “AnalysedFiles.txt”, that contains every file number that has already been previously
processed. Afterwards, a file will be selected and the function will retrieve its information based on the
file name. If the file name contains a valid flight number, the program will proceed to check if the file
number is already in the backlog. In case it is not, meaning this flight was not processed, the program
will open the file and check if it contains valid flight data. This is done by verifying if all the main flight
phases are present, which is not the case in tests conducted on ground, such as engine run-ups. Valid
flights move on to the following stage of the program - flight processing (Figure 3.2).
Start
Flights Directory
Select Next File
New flight?
Open File
Valid flight?
Process Flight
Figure 3.2: Update Flights Routine.
29
Flight processing is the program stage where we extract all the information that will later be used for
analysis. Given the sheer amount of data available, and considering the computing limitations of the R
programming language, we needed to figure out how to make the most out of the data while reducing
the processing time as much as possible.
The goal of this AHM application is to be able to monitor the behaviour of some critical systems in
the long term in order to identify degradation patterns. It was neither created to identify the causes of
a failure nor analyse specific flights, since the company already has the tools to do so. AGS has the
functionality to analyse thousands of parameters of entire flights and the Fault History DataBase (FHDB)
already creates fault messages that help the Maintenance Department trace the origin of failures that
have taken place. This application is rather meant to produce alerts when it detects abnormal behaviours
in order to prevent such failures from happening or at least inform the competent entities so they can
allocate the resources beforehand.
The long-term nature of this application means we should not focus on specific flights but rather on
a set of recent flights, since we are trying to find unusual patterns in the long run. Therefore, we needed
to find a way to represent a flight with as little information as possible, as long as this was relevant and
representative of a property we wanted to monitor. This is where the concept of snapshot is included
in the application. In the context of this work, a snapshot represents a state of the aircraft’s systems
at a particular point in time. To exemplify, let’s consider a short sample of data retrieved from a real
flight, where we intend to capture a snapshot of some key parameters of the ignition system, the instant
fuel starts being injected into the combustion chamber of Engine #1, i.e., when the FF1 (Fuel Flow (FF)
Engine #1) parameter transitions from 0 to a positive value (Table 3.2).
Table 3.2: Engine 1 Fuel Flow Start - Flight Data Snapshot.
Time N2 Igniter A FF1 ITT1

14:01:21 14.3 On 0 59
14:01:22 16.3 On 0 59
14:01:23 18.1 On 0 59
14:01:24 19.6 On 116 60
14:01:25 21.1 On 123 59
14:01:26 22.6 On 134 80
14:01:27 24.5 On 145 139
The real time value at which the snapshot is taken is called time hack. In the example above, fuel
started flowing in the chamber at time hack 14:01:24. At this time, fuel flow was at 116 Kg/h and
the Inter-Turbine Temperature (ITT) was 60 °C. In this instant, the N2 was 19.6%, which is within the
manufacturer’s defined interval for this stage, 20% to 25% N2, thus reflecting normal behaviour. Since
our goal was to monitor this property over time, we did not need to consider the whole flight, which
lasted over 3 hours. Instead of storing 13,180 samples, we would only capture one, at time hack, which
would already represent the instant we wanted to analyse. The parameters captured at time hack will
be designated as the snapshot parameters, and will help us contextualize the events and possibly even
identify strange behaviours based on their values. The application would then make use of the snapshot
30
data to create the graphical interface that would allow the user to visualize the progression of a certain
parameter over time, by the means of a time series plot.
Plots will contain several hundreds of points and it would take an unreasonable amount of time to
process every flight - identify the desired property, locate the time hack and obtain the snapshot parame-
ters - every time we wanted to visualize a plot. We circumvented this by separating the flight processing
from the plot construction, thus allowing the application to load the plot data without the need to process
it. This means that, before plotting the graphics, data must have already been processed beforehand.
In this sense, we created a function that will process a flight and promptly store the processed data
(desired property value, time hack and snapshot parameters) in a text file, which will later be used by the
plotting function to build the plot. We will designate these text files as system files, and each monitored
system will consist of a separate system file. This routine, with flowchart in Figure 3.3, analyses all the
monitored systems before loading the next file in order to optimize processing time as file manipulation
is a rather slow process.
Figure 3.3: Process Flight Routine.
Tracing back to the example of Table 3.2 and based on the flowchart above, we consider the identifi-
cation stage to be locating the sample where, in engine start phase, the value of the fuel flow parameter
changes from 0 to 116 Kg/h. After we find that sample we check the time hack, which in the current
example was at 14:01:24 and then, in the same sample, we capture a snapshot of other relevant param-
eters: N2 = 19.6%, Igniter A = On and ITT = 60 °C. Following this, we print this data in a single line
of the respective system file. Every line in a system file corresponds to an observation and, for some
systems, multiple observations are obtained from a single flight.
Although all system files are different, the structure is similar since the plotting function was designed
to be able to build a graph independently of the system, to facilitate the application’s extensibility to other
31
systems in the future. A given system file contains all the observations relative to said system from every
aircraft since the beginning.
If we were to append the data from the example of Table 3.2 in its system file, the output file would
have a similar structure to Table 3.3.
Table 3.3: Engine 1 Fuel Flow Start - System File Example.
File Date Tail Time N2 FF1 Igniter A Igniter B ITT1

1 08/03/16 CS-TPW 09:48:19 21.0 152 Off On 27
...
6967 16/01/17 CS-TPS 18:14:11 23.1 131 Off On 118
6968 16/01/17 CS-TPS 21:37:24 24.9 138 On Off 117
6969 17/01/17 CS-TPS 06:21:17 20.4 152 Off On 23
6970 17/01/17 CS-TPS 08:03:30 29.5 142 On Off 118
6971 17/01/17 CS-TPS 10:27:15 20.4 123 Off On 81
6972 17/01/17 CS-TPS 14:01:24 19.6 116 On Off 60
It is worth mentioning that, although the system above is an example and does not correspond to an
actual monitored system, all the data was obtained from real flights. Note the alternation between igniter
A and B usage in consecutive flights - this is not coincidental since the Full-Authority Digital Electronic
Control (FADEC) alternates between the two igniters for extended life and reliability.
Data from the system files will later be used for two main purposes: building the time series plots
and trend analysis. Before we get into those we need to decide which systems we want the application
to focus on.
3.3 Monitored Systems
As previously mentioned, the focus of the program was to be able to study the behaviour of critical
systems, in the context of maintenance, regarding the Embraer 190/195 fleet.
The first step was determining which systems were to be included in the program, based on reliability
reports within the company and input/advice from experts of the Maintenance Department - Engineering
and Troubleshooting. The know-how obtained from working closely with the aircraft over a year, along
with intelligence gathered from E190 World Operators Conference, allowed us to highlight the majority
of the systems that compromise the reliability of this fleet in the maintenance context as well as other
parameters and systems that are important to keep track off.
The following step was to ascertain, for each system, which QAR parameters contained the infor-
mation we were seeking, and which variables reflected the behaviour we wanted to monitor. This part
presents a challenge since it is not always possible to directly quantify a certain property of a system,
meaning that a different approach is likely to be required for every other system without the guarantee it
will lead to meaningful results.
32
3.3.1 Altitude Split
Altitude Split represents the difference between the pilot’s and co-pilot’s altitude indicators on the Primary
Flight Display (PFD). The analysis of this parameter is important to detect problems with the Air Data
System (ADS).
Since the indicators of each pilot collect data from different sensors, a significant difference between
the indicated altitudes could be originated from a failure in one of the four integrated pitot/static/Angle
Of Attack (AOA) sensors, a defective aerodynamic sealing or a defect in the forward fuselage skin in the
nose section (see Figure B.1 in Appendix B).
Altitude differences, especially during climb and descent, are quite common due to measuring errors
and atmospheric conditions (e.g. clouds). To verify if the altitude difference is within tolerance, the
manufacturer provides a table that defines the thresholds as a function of the altitude (Table 3.4).
Table 3.4: Altitude split manufacturer thresholds.
Altitude Tolerance
Lower than 10 000 ft 50 ft
Between 10 000 and 20 000 ft 120 ft
Higher than 20 000 ft 180 ft
The Aircraft Operations Manual (AOM) states that, to verify if altimeter difference is within tolerance,
the aircraft should be under straight and levelled flight conditions for at least 15 seconds, preferably with
autopilot engaged. As to reduce false warnings, and based on the AOM, it was decided to only analyse
altitude differences in the cruise flight phase, where the aircraft is stabilized in terms of altitude and
speed.
The algorithm developed calculates the difference between the altimeters in every instant of the
cruise and returns the maximum registered difference (Figure 3.4).
Figure 3.4: Maximum altitude difference.
The application displays a snapshot of key parameters of the air data system, at the moment altitude
split was maximum (Table 3.5).
33
Table 3.5: Altitude Split Monitoring - Snapshot Parameters.
Parameter Description Units

ADS SEL P Air Data System of Pilot -
ADS SEL C Air Data System of Copilot -
ALT SPLIT LIM Altitude Difference Tolerance for current altitude feet
ALT STD Indicated Altitude Pilot feet
ALT STD COP Indicated Altitude Copilot feet
CAS Airspeed Pilot knots
CAS COP Airspeed Copilot knots
FLIGHT PHASE Flight Phase See Table 2.5
TAT 1 & TAT 2 Total Air Temperature °C
VERT SPD Vertical Speed feet/min
3.3.2 Auxiliary Power Unit Exhaust Gas Temperature
The Auxiliary Power Unit (APU) is a gas-turbine engine system that is designed to deliver electrical power
and bleed air to the aircraft on the ground and in flight. It allows an aircraft to operate autonomously
without reliance on ground support equipment such as a ground power unit, an external air-conditioning
unit or a high pressure air start cart. This device is located in the tail section of the aircraft and its main
purpose is to provide power to start the main engines (see Figure B.2 in Appendix B).
The Exhaust Gas Temperature (EGT) is a measurement of the temperature of the exhaust gases at
the exhaust manifold. High values of this parameter may indicate a failure of the anti-surge valve, APU
tubing, APU FADEC, the APU itself or a defective harness.
This system will be monitored by the analysis of the APU EGT parameter. The program will determine
the maximum values of this parameter in the whole flight, depending on the APU’s operation. The
manufacturer established different thresholds according to the APU’s current operation: Start and Run
(Table 3.6).
Table 3.6: Temperature limits according to APU operation.
Status APU Operation Thresholds

Normal up to 976 °C
Caution Start from 976 °C to 1032 °C
Critical more than 1032 °C
Normal up to 717 °C
Run more than 717 °C up to 3 seconds or more than 787 °C
Caution
up to 0.5 seconds
more than 717 °C during more than 3 seconds or more
Critical
than 787 °C during more than 0.5 seconds
To exemplify the approach used to obtain the maximum EGT values for each APU operation mode,
we will consider a snapshot of flight data from an on-ground APU operation, obtained from a real flight.
In this example, the APU was active for about 17 minutes and the starting operation lasted around 20
seconds. Given that there are different thresholds for each one of the two operating modes, we need to
34
obtain two points per flight: one for the maximum EGT in start mode and another for the maximum EGT
in run mode.
Based on the APU START parameter, which indicates if the APU is currently operating in starting mode,
we obtain the maximum APU EGT value that was captured by the temperature sensor in the APU during
start (Figure 3.5). The algorithm only searches for a maximum in the time interval where the APU is in
Start mode, which is when APU START = 1.
Figure 3.5: APU EGT Start Operation.
The same principle is applied when the APU is in Run mode, but in this case APU START = 0 (Figure
3.6).
Figure 3.6: APU EGT Run Operation.
The application also displays a snapshot of key parameters of the APU system, at the moment where
the EGT was maximum (Table 3.7).
35
Table 3.7: APU EGT Monitoring - Snapshot Parameters.

APU BLD VLV APU Bleed Valve Opened/Closed
APU START Indicates if APU is in Start Operation On/Off
APUGEN LOAD APU Generator Load kVA
APUGEN VOLT APU Generator Voltage RMSV
PACK FLOW 1 & PACK FLOW 2 Air Flow in the Packs ppm
3.3.3 Engine Bleed System Temperature
As previously mentioned, the engine bleed system is critical in terms of reliability and we believe a
temperature analysis could help the maintenance department identify faulty systems.
Initially, we implemented an algorithm that would detect the highest bleed manifold temperature value
in the whole flight. The expectation was that this would allow to detect abnormal behaviours by checking
which aircraft would present a temperature pattern higher than the rest of the fleet. The results obtained
were unsatisfactory since we verified that it was quite common for the bleed temperature to be above
the manufacturer’s defined thresholds and that higher values did not directly indicate degraded systems.
We then decided to consider a different approach by analysing the duration of bleed over-temperature
conditions, meaning we were not focusing on the values achieved but rather on the duration of this
temperature exceedance.
The algorithm analyses the MANF STMP L and MANF STMP R parameters from the QAR and determines
the maximum duration, in seconds, of the over-temperature conditions for every flight. A snapshot of
other parameters is also taken at that instant to contextualize the event.
Based on the documentation provided by the manufacturer, a message indicating bleed failure will
be generated by the aircraft’s on-board computer if one of the following conditions is met:
• Manifold temperature between 235 °C and 260 °C for longer than 2 minutes, under normal oper-
ating conditions.
• Manifold temperature between 246 °C and 260 °C for longer than 2 minutes, during anti-ice system
operation.
• Manifold temperature greater than 260 °C for longer than 3 seconds.
The algorithm will scan the entire flight and identify the moments where the MANF STMP L and
MANF STMP R parameters exceed the defined thresholds, depending on the anti-ice system current oper-
ation.
To demonstrate how this point is obtained we represent, in Figure 3.7, the progression of engine 1
manifold bleed temperature obtained in a real flight. In this example, the anti-ice system was not active,
meaning the temperature threshold is 235 °C.
36
Figure 3.7: Engine 1 Bleed Over-Temperature Events (Anti-Ice OFF) - red dots indicate over-temperature
events.
Afterwards, we determine the duration of every over-temperature event and select the longest. The
duration of the four over-temperature events detected in the flight depicted in Figure 3.7 is represented
in Table 3.8. In this case, the longest over-temperature event started at 08:00:19 and lasted 13 seconds.
Table 3.8: Engine 1 Bleed Over-Temperature Events - Anti-Ice OFF.
Hour Duration (seconds)

06:19:23 4
07:35:23 5
07:39:59 3
08:00:19 13
The application also displays a snapshot of key parameters of the engine bleed system, at the mo-
ment the longest over-temperature was observed (Table 3.9).
Table 3.9: Bleed Over-Temperature Monitoring - Snapshot Parameters.

ALT STD Altitude feet
ANTI ICE VLVE1 & ANTI ICE VLVE2 Anti-Ice Valve Position OPEN/CLOSED
ANTI ICE WG OF Anti-Ice (Panel) Wing Off True/False
AT EGD Auto-Throttle Engaged ENGAGED/’NOT EGD’
BLEED1 VLV & BLEED2 VLV Engine Bleed Valve Position OPEN/CLOSED
CAS Calibrated Airspeed knots
MANF STMP L & MANF STMP R Manifold Bleed Temperature °C
N21 & N22 Engine Core Rotor Speed %
XBLV CL DI 01 Cross-Bleed Valve Position OPEN/CLOSED
37
3.3.4 Engine Bleed System Pressure
An analysis of maintenance reports within the company showed that there were written reports from the
flight crew of pressure oscillations of the bleed system during stable flight conditions. We verified that, in
the days that followed those reports, several indications of bleed failures were reported. This correlation
leads us to believe that an analysis of the engine bleed pressure could indicate issues with this system.
The pressure sensor is located after the pre-cooler, meaning that it reads the pressure value of air
that has already passed all the major bleed system components. An analysis on this parameter could
indicate problems in any of the components that precede the sensor, such as the High-Stage Shut Off
Valve (HPSOV), Low-Pressure Shut Off Valve (LPSOV), Nacelle Pressure-Regulating Shut-Off Valve
(NAPRSOV), pre-cooler, the torque-motors and their controller and the Air Management System (AMS)
controller (Figure B.4 in Appendix B).
Since the engine bleed system takes advantage of compressed hot air coming from the engines
(Figure B.3 in Appendix B), a small variation in the engine power setting results in an abrupt pressure
oscillation in the bleed system, which means that, in order to improve our analysis, we should focus on
a time window where the engine power is relatively constant, i.e., in cruise (Figure 3.8).
Figure 3.8: Engine 1 Bleed Pressure.
An analysis of Figure 3.8 allows to conclude that, as expected, the cruise flight phase is the one that
presents the highest bleed pressure stability. The next step was to verify that, for the cruise flight phase,
we could distinguish a healthy system from a faulty one. Several comparisons were made between
flights where the aircraft’s bleed system functioned normally and flights where the aircraft’s bleed system
was known or strongly suspected to be degraded. The conclusion was that, by analysing the bleed
pressure parameter in cruise, we could clearly tell the difference from a healthy system to a faulted
one. To demonstrate, we obtained flight data from two different flights, one where the aircraft’s engine
bleed system was behaving normally and the other where the same system was severely degraded,
and plotted the first hour of cruise for both air-planes (Figure 3.9). In the example below, the first 100
38
seconds of cruise were discarded to account for bleed pressure stabilization.
Figure 3.9: Healthy Bleed System vs Faulty Bleed System - cruise flight phase.
A simple statistical analysis of the data of Figure 3.9 allows to confirm that, although the mean value
of both curves is very similar (µHealthy = 34.71 psia and µF aulty = 34.60 psia), the standard deviation
values reflect the heavy contrast that we can observe in terms of oscillation: σHealthy = 0.58 psia and
σF aulty = 5.20 psia. Based on these results, we believe that an analysis of the standard deviation
reflects, at a very satisfactory level, the oscillatory behaviour of the bleed pressure.
Afterwards, we needed to define limits for the standard deviation values to differentiate a normal
system from a degraded one. As one could expect, the manufacturer did not define thresholds for this
particular property of the bleed system. In this sense, we gathered several months of data (5191 flights)
of aircraft which presented a healthy bleed system, i.e., never had documented unscheduled repairs or
failure reports in the bleed system and showed a consistent behaviour over several months. From this
data, we calculated, for each flight, the standard deviation values for the MANIFOLD1 P or MANIFOLD2 P
parameters from the QAR when the aircraft was in stable flight conditions. The values obtained are
represented in Figure 3.10, where every flight is represented by a single point and the flight order, on
the horizontal axis, was randomly assigned.
Afterwards, we defined the caution and critical thresholds based on the quantile property of the data
set from Figure 3.10. We established the caution threshold to be the upper limit of the region where
95% of the values are located, meaning 95% of all points are located below this value. The same
principle was applied to the critical threshold, but for the 99% percentile. The values obtained were
σCaution = 2.10 psia and σCritical = 3.57 psia.
Since the point that will be represented in the time series plot was obtained from data over time and
not at a particular instance of the flight, we decided to represent a snapshot of the bleed system main
parameters at an arbitrary moment of the cruise (Table 3.10).
39
Figure 3.10: Engine Bleed Pressure Standard Deviation of Healthy Aircraft.
Table 3.10: Bleed Pressure Oscillation Monitoring - Snapshot Parameters.

BLEED1 VLV & BLEED2 VLV Engine Bleed Valve Position OPEN/CLOSED
LDGL Landing Gear Logic AIR/GROUND
MANIFOLD1 P & MANIFOLD2 P Manifold Bleed Pressure psia
N21 & N22 Engine Core Rotor Speed %
3.3.5 Center/Forward Electronics Bay Air Flow
The main function of the avionics compartment ventilation system is to provide a reliable ventilation
source that will maintain a safe temperature in the applicable avionics compartment. It is critical that
the center and forward electronics bays, which are the ones with dedicated fans, remain within tolerated
values of temperature (Figures B.5 and B.6 in Appendix B).
The manufacturer established flow thresholds for the normal operation of each ventilation system
(Table 3.11).
Table 3.11: Electronics Bay Air Flow Thresholds.
Electronics Bay Alert Critical

Forward 65 f t3 /min 50 f t3 /min
Centre 50 f t3 /min 40 f t3 /min
In order to monitor the air flow in these compartments, our program will analyse the EBAY FL FWD
(forward electronics bay air flow) and EBAY FL CNT (center electronics bay air flow) parameters from the
QAR unit. The algorithm determines the minimum value of air flow in the whole flight, when the aircraft
is airborne (Figure 3.11).
The application also displays a snapshot of key parameters of the electronic bay ventilation system,
at the moment the lowest air flow was observed (Table 3.12).
40
Figure 3.11: Forward Electronics Bay Air Flow.
Table 3.12: Center/Forward Electronics Bay Air Flow - Snapshot Parameters.

CAS Calibrated Airspeed knots
EBAY FL CNT Centre Electronics Bay Air Flow f t3 /min
EBAY FL FWD Forward Electronics Bay Air Flow f t3 /min
3.3.6 Engine Light-Off Time
The purpose of the ignition system is to provide the electrical spark to initiate the combustion of the
fuel/air mixture in the engine during start, auto-relight and when continuous ignition is required.
The control of the engine ignition is provided by an integrated engine-aircraft system that automat-
ically starts ignition in response to engine core speed. The ignition system provides the function to
energize either igniter (A or B) from either FADEC channel; only one igniter is turned on for ground
starts so latent faults can be detected (Figure B.7 in Appendix B).
During the on-ground engine start, the FADEC starts ignition at approximately 7% N2 (Core Rotor
Speed) and the fuel flow (metering valve opens) at approximately 20% to 25% N2, depending on the
engine start altitude. If no light-off is detected within 15 seconds of fuel on, FADEC will automatically
turn off ignition and fuel, continue dry motoring for 30 seconds, then turn on both igniters and turn on
fuel again. Subsequently, if no light-off is detected after the reintroduction of fuel, the FADEC will not
turn off fuel or ignition and the start must be manually aborted 15 seconds after the reintroduction of fuel
flow or start duty limit, whichever occurs first [18].
What we intend to monitor is the time difference between the instant fuel starts being injected in the
engine and the instant ignition is detected. A pattern of high light-off values may indicate a degradation
of the ignition system.
The parameters FF1 and FF2 indicate the fuel flow value, in Kg/h, in the left and right engines. The
41
instant fuel starts flowing in the chamber is obtained directly from this parameter by identifying the
moment fuel flow in the engine transitions from 0 to a positive value, while at least one of the ignition
systems is on.
Light-off is detected by analysing the ITT, ITT1 and ITT2 parameters, which indicates the temper-
ature, in degrees Celsius, inside the engine between the turbine stages. A sudden raise in ITT will
indicate a light-off. The algorithm identifies the instant a 10% increase of ITT over 1 second takes place
and determines the time delay relative to the moment fuel started flowing in the engine - this is the
light-off time.
To demonstrate the methodology used to determine the light-off time, we will consider a snapshot
of flight data from an on-ground engine start, obtained from a real flight and with a sample period of 1
second (Table 3.13).
Table 3.13: Engine 1 Ignition - Flight Data Snapshot.
Stage N2 Igniter A FF1 ITT1 Light-off Time [s]

Engine Start 0 Off 0 28 -
1.9 Off 0 27 -
4.5 Off 0 27 -
7.1 Off 0 28 -
Igniter On 9.8 On 0 28 -
12.3 On 0 28 -
14.4 On 0 28 -
16.4 On 0 29 -
18.1 On 0 29 -
Fuel Flow Start 19.9 On 138 29 ∆t = 0
21.3 On 142 29 ∆t = 1
22.5 On 145 29 ∆t = 2
23.5 On 149 30 ∆t = 3
Ignition 25.3 On 167 81 ∆t = 4
27.1 On 178 155 -
29.1 On 189 216 -
In the example provided, the FADEC turned on igniter A at 9.8% N2 and the metering valve, which
controls fuel flow, opened at 19.9% N2. It took 4 seconds for the temperature to raise over 10% in the
course of 1 second, meaning the light-off time was 4 seconds. The manufacturer defined 10 seconds
to be the critical value for an engine light-off and 5 seconds as an intermediate threshold for warning
purposes. In this case, the value is within normal operation and did not ensue a warning.
The application displays a snapshot of key parameters of the ignition system (Table 3.14), at the
moment of ignition.
42
Table 3.14: Engine Light-Off Time Monitoring - Snapshot Parameters.

FF1 Fuel Flow Kg/h
IGNIT 1A Igniter A ON/OFF
IGNIT 1B Igniter B ON/OFF
ITT1 Inter Turbine Temperature °C
ITT1 INC ITT1 increment in last second °C
N11 Fan Rotor Speed %
N21 Core Rotor Speed %
3.3.7 Engine Vibration
Engine vibration data can offer real-time warning signs of the critical mechanical engine issues that
often lead to premature component failure. Although pressure, flow, temperature and acoustic param-
eters are also important, they tend to offer later-stage clues of an ongoing mechanical issue, long after
damage may have already occurred. As such, the use of high-accuracy sensors and instrumentation
for engine vibration monitoring is essential for the establishment of longer-term predictive maintenance
strategies. The Embraer 190 is equipped with software that offers engine vibration monitoring capacity,
the Integrated Engine Vibration Monitor (IEVM) [18].
The IEVM system main functions are to monitor the vibration of both engines, provide engine trim
balancing, detect engine running, store vibration data in the history memory and check internal and
external functions by build-in test equipment procedures. In order to perform these tasks, the IEVM re-
ceives signals from 4 accelerometers, 2 per engine, and the tachometer signals from the speed sensors
(Figures B.8 and B.9 in Appendix B).
The accelerometers signals are sent to the Modular Avionics Unit (MAU), specifically to the IEVM
board. The IEVM board processes them and then the MAU sends this information via ARINC-429 to the
FADEC. The FADEC converts the vibration values to non-dimensional vibration units and sends them
back to MAU to be displayed on the EICAS. These are the parameters that we will use to conduct the
engine vibration monitoring. N11 VIB contains the vibration value of Engine 1’s Low Pressure Stage (left
side) and N21 VIB stores the vibration value of the Engine’s High Pressure Stage. The same order is
used for N12 VIB and N22 VIB but for Engine 2 (right side).
Even though the IEVM unit monitors the vibration of both engines, it will produce warnings when the
vibration levels are already exceeding the normal operational range. We want to extend that functionality
to the point where we can detect which engines stages (high pressure and low pressure) are behaving
differently from the rest of the fleet, despite still being in the normal operational range. This could allow
to highlight mechanical issues at an early stage.
The algorithm that we implemented will determine, for each one the main four flight phases (Take-Off,
Climb, Cruise and Descent), the maximum vibration value for both pressure stages of each engine. This
means that we will retrieve 16 points per flight: maximum N11 VIB, N21 VIB, N12 VIB and N22 VIB for
every flight phase (Figure 3.12). The example below illustrates the points that were captured relative to
43
the Low Pressure Stage (N1) of the right engine.
Figure 3.12: Engine Two Low Pressure Stage Vibration - red dots indicate the maximum value at each
flight phase.
The manufacturer established vibration limits which are used by the engine vibration monitoring
system (Table 3.15).
Table 3.15: Engine Vibration Monitoring System - Vibration Limits.
EICAS Display Value (A/C Units) Condition EICAS Indication

From 0 to 3.99 Normal Green
From 4 to 5 Exceedance Amber
Based on the data gathered over the course of several months and on the thresholds defined by the
manufacturer, we have defined 3 A/C units to be the warning/caution threshold and 4 to be the critical
threshold.
In the time series plot, each point will contain a snapshot of relevant parameters, taken from the
instant the maximum value was observed (Table 3.16).
Table 3.16: Engine N1 Vibration Monitoring - Snapshot Parameters.

AT EGD Auto-Throttle Engaged ENGAGED/’NOT EGD’
E1 N1A VIB Engine #1 N1 Vibration A Sensor A/C Units
E1 N1B VIB Engine #1 N1 Vibration B Sensor A/C Units
N11 & N12 Fan Rotor Speed %
N21 & N22 Core Rotor Speed %
44
3.3.8 Hydraulic System Pressure
The hydraulic system is comprised of three independent systems, which operate at a nominal pressure
of 3,000 psig and provide hydraulic power for the operation of the primary flight controls, the spoilers,
the landing gear, the nose-wheel steering, the brakes and the thrust reversers.
The hydraulic power users are distributed among the three systems in order to maximize the aircraft’s
functionality should one or two hydraulic systems become inoperative. The operation of the hydraulic
system is mostly automatic and requires minimal pilot action. The system architecture and level of
redundancy allows it to accommodate most system failures without degradation to the airplane’s safe
operation (Figure B.10 in Appendix B).
Given the importance of this system, we found it essential to monitor its key parameters in the context
of maintenance: hydraulic system pressure and hydraulic fluid quantity.
Even though the hydraulic system is designed to operate at around 3,000 psig, it tolerates higher
values. We verified that it is very common for a healthy system to operate at around 3,100 psig for the
entire flight. Although we did not find any clear limits in the aircraft’s documentation, we found out the
manufacturer has created a specific fault warning to alert when the hydraulic system pressure is between
3,200 and 3,300 psig, which could suggest failures in the pressure transducer, the engine-driven pump
or the AC motor driven pump (Figure B.11 in Appendix B). As such, we defined 3,200 psig to be the
warning/caution threshold and 3,300 psig the critical threshold.
The application will monitor the hydraulic pressure of each one of the three systems by determining
the highest value in the entire flight (Figure 3.13); 3 points per flight. Although simple, this approach
allows us to identify degraded systems since faulty systems tend to present higher pressure peaks
over-time.
Figure 3.13: Hydraulic System 1 Pressure.
As usual, the application will display a snapshot of the relevant parameters to contextualize every
event (Table 3.17). The snapshot was taken at the moment the maximum value was observed.
45
Table 3.17: Hydraulic System 1 Pressure Monitoring - Snapshot Parameters.

AC MP1 ON Hydraulic System 1 AC Pump Switch ON True/False
AC MP2 ON Hydraulic System 2 AC Pump Switch ON True/False
AC MP3A ON & AC MP3B ON Hydraulic System 3 AC Pump A/B Switch ON True/False
HYD SYSX PRESS Hydraulic System Pressure of the other two systems psig
HYDEDPDEP EX Engine X Hydraulic Engine Driven Pump De-pressurized True/False
SYS1 MEAN PRESS Hydraulic System 1 Mean Pressure entire flight psig
WHEEL IBL & WHEEL IBR Wheelspeed Inboard Left/Right ft/sec
WHEEL OBL & WHEEL OBR Wheelspeed Outboard Left/Right ft/sec
3.3.9 Hydraulic System Quantity
A fluid quantity indicating device is used to measure hydraulic fluid quantity in the hydraulic reservoir
low-pressure storage chamber. The indicating device is mounted on the end of the hydraulic reservoir
on the #1 and #2 hydraulic systems and on the end of the reservoir bootstrap cylinder of the #3 hydraulic
system (Figure B.10 in Appendix B). The quantity indicators are monitored by the MAUs, which send the
hydraulic quantity information to the Multi-Function Display (MFD). The MFD hydraulic synoptic page
displays fluid quantity, as percentage of full, in both digital and analog slider form [18].
Although the crew alerting system advisory messages “HYD 1 LO QTY”, “HYD 2 LO QTY” and “HYD
3 LO QTY” already indicate that the hydraulic fluid level in the relevant system reservoir is low and
requires servicing, it is important to monitor these quantities to properly schedule future servicing and
study the consumption of hydraulic fluid over time to detect abnormal patterns.
Since the fluid quantity indicated values shift very often in a flight, due to hydraulic system usage, we
decided to search for the lowest hydraulic quantity value in a phase when the aircraft was not likely to per-
form any major modifications in the primary flight controls which is, once again, the cruise flight phase.
As such, the application will find the lowest hydraulic quantity value, for each system, in cruise (Figure
3.14). The parameters that contain this information are HYD SYS1 QTY, HYD SYS2 QTY and HYD SYS3 QTY.
To contextualize every sample, the application displays a snapshot of some hydraulic system param-
eters at the moment the lowest fluid quantity was observed (Table 3.18).
Table 3.18: Hydraulic System 1 Quantity Monitoring - Snapshot Parameters.

HYD SYSX PRESS Hydraulic System Pressure of every system psig
HYD PRESS 1A Hydraulic System Low Pressure in EDP ’NORMAL’/’HIGH PRESS’
HYD PRESS 1B Hydraulic System Low Pressure in AC Motor Pump ’NORMAL’/’HIGH PRESS’
HYD SYSX QTY Hydraulic System Quantity of the other two systems % of full capacity
N11 Fan Rotor Speed of Engine 1 %
46
Figure 3.14: Hydraulic Fluid Quantity System 3.
3.3.10 Nose Wheel Steering System
The landing gear system provides ground-rolling capability to the airplane, thus enabling take-off, land-
ing and taxi operations. The airplane is equipped with a retractable tricycle landing gear hydraulically
operated. It consists of two main units: the nose and main landing gears. Each landing gear is a
conventional dual wheel unit.
The Nose Landing Gear (NLG) incorporates a powered steering system, which performs the aircraft
directional control on the ground. Its main functions are to give structural support to the aircraft when it
is on the ground, control the direction of the aircraft when it is on the ground (through the nose wheel
steering system) and absorb shocks to the aircraft structure during take-off, landing or during movement
on the ground (Figure B.13 in Appendix B).
Taking into account the importance of the nose wheel steering system in controlling the aircraft on
the ground, and given the system under-performance reliability, it was decided to include this system in
our Aircraft Health Monitoring application.
When the landing gear is retracted, four doors close the NLG wheel well to reduce aerodynamic drag.
The nose landing gear retracts forward inside its compartment on the aircraft fuselage nose section, and
it is installed with an inclination of 8 degrees forward in order to create the “caster effect”. This is used to
keep the wheels centered during landing roll and allows the use of differential braking technique in case
of loss of hydraulic system two that forces the steering system into passive mode.
To make sure the NLG retraction and alignment functionality is working properly, the application
will monitor the angle measured by the sensors located in the NLG compartment (Steering Feedback
Sensors in Figure B.14 in Appendix B). Ideally, this value would be 0◦ when the landing gear is retracted,
although in most cases the absolute value goes up to 0.5◦ . According to the manufacturer [18], absolute
values higher than 1◦ may indicate problems in the nose wheel steering system. As such, and based on
advice from specialists within the company, we established 1◦ to be the caution/warning threshold and
1.4◦ to be the critical threshold.
47
The application will determine, for each flight, the mean value of the position of each of the two
wheels of the NLG, when it is fully retracted and locked. This value is measured by the sensors in the
NLG compartment and kept in the NLG POS 1 and NLG POS 2 parameters. The LDGNOS POS parameter
indicates the current Nose Landing Gear position, which helps us select the time interval where the NLG
is retracted (Figure 3.15).
Figure 3.15: Nose Landing Gear Left Wheel Longitudinal Angle.
In the example above, the application would calculate the mean value of the NLG POS 1 parameter
when LDGNOS POS indicated the position “UP & LOCKED”. In this case, the absolute value of the mean
is |µLef tW heel | = 0.30◦ , which lies within the normal range of values that we set.
Once more, a snapshot of some relevant parameters in this context is presented. The snapshot
refers to the moment the landing gear was retracted and locked, i.e., the very second where LDGNOS POS
transitioned from “IN TRANSIT” to “UP & LOCKED” (Table 3.19).
Table 3.19: Nose Wheel Steering System Monitoring - Snapshot Parameters.

LDGNOS POS Nose Landing Gear Position ’DW & LOCKD’/’IN TRANSIT’/’UP & LOCKD’
NLG POS 1 Nose Landing Gear Left Wheel Angle °
NLG POS 2 Nose Landing Gear Right Wheel Angle °
3.3.11 Total Air Temperature
The forward fuselage of the aircraft has two Total Air Temperature (TAT) sensors that sense the TAT of
the external air (Figure B.15 in Appendix B). The sensor reads the air temperature with a wire probe
that projects into the air stream. Each sensor contains a 500 Ω resistor that changes its value according
to the temperature. It sends an analog signal to the Integrated/Pitot/Static/AOA system, which shows
as degrees (°C ) on the cockpit displays. The TAT sensor housing has a hermetic seal that prevents
48
the contamination of the sensor and includes resistive elements to ensure de-icing and anti-icing sensor
accuracy in an icing environment [18].
The values that both sensors read should be very similar, especially when the aircraft is airborne
since the TAT readouts on the MFDs will be blank if the aircraft is on the ground.
The application calculates the difference between the TAT values read by the sensors in every instant
of the climb, cruise and descent flight phases, and returns the maximum difference observed in each
phase (Figure 3.16). These values are stored in the TAT 1 and TAT 2 parameters.
Figure 3.16: Total Air Temperature Difference Between the Two Temperature Sensors (red dots indicate
the maximum value at each flight phase).
Each point in the time series plot will contain a snapshot of key parameters (Table 3.20). These were
obtained from the moment the TAT difference was maximum in that flight phase.
Table 3.20: Total Air Temperature - Snapshot Parameters.

FADEC FAN1 T Engine 1 Selected T2 °C
TAT 1 Total Air Temperature Sensor 1 °C
3.4 Graphical User Interface
In the previous sections, we described how the application collects and processes flight data. We
selected the systems we want to monitor, implemented algorithms to extract the desired information from
QAR flight data and stored it in system files (Figure 3.17). At this stage, the application is capable of
generating and storing all the information it needs to conduct its aircraft health monitoring functionalities.
49
Therefore, the next step was to build the Graphical User Interface (GUI), to allow the user to visualize
this data.
Figure 3.17: Data Migration - Part II.
The application’s GUI was designed to provide the user the capacity to filter the desired information
through direct manipulation of the graphical elements. This was achieved using the Shiny package of
the R language, which facilitates the construction of interactive web applications straight from R.
Although Shiny had the tools to build the main features of the application’s interface, we still required
a package with plotting capabilities - Plotly. This open-source web-based data visualization platform
provides graphing, analytics and statistics tools aimed at data scientists and engineers. It proved to be
a very powerful and flexible add-on, meeting our expectations in terms of plot interaction.
When designing the graphical interface, we intended to present the information as straightforward
and clear as possible, while maintaining a clean and simple environment. The selection menus, for
aircraft and system, are easy to navigate, intuitive and do not require any keyboard input from the user.
The reactive nature of this application means that, if the user modifies any option in either the aircraft
or system selection menus, the application will react accordingly without the need for a confirmation or
submit action button.
We used a green coloured environment to fit this product in Portugália Airlines’ theme. The final
outlook of the GUI is presented below (Figure 3.18), where the application represents a plot regarding
the monitoring of the Hydraulic System Pressure of the CS-TPT aircraft.
An observation of Figure 3.18 allows us to identify two major sections. The left side of the screen
contains three distinct sections, separated into different boxes and on the right side of the screen lies
the main section which contains graphical interface and it is where the time series plot is located.
50
Figure 3.18: Graphical User Interface - Overview.
In the following sub-sections, we will briefly explain the purpose of each one of the sections that
constitute the Graphical User Interface.
As we previously mentioned, this web-browser application is accessible to anyone in the company

as long as their device is connected to the network, and it is possible for multiple users to be connected
at the same time. Although this remains true, there are limitations that prevent several users from
requesting plot data from the server simultaneously. Since the R language internals are single-threaded,
it is not possible for the server to execute multiple processes, or threads, concurrently. What this means
is that, if multiple clients are requesting plot data from the server, it can only deal with one request
at a time. We believe this limitation is somewhat minor in our context, given this scenario is unlikely
considering the nature of this application and the dimension of the company. Even in that case, it
only takes the application a few seconds to attend each request, so the consequences are minimal.
There is, however, another drawback to this software limitation. In case we wanted to analyse a large
amount of flights, the program would be busy until this process was finished, preventing the user from
interacting with the application. If it was developed in a language with concurrency capabilities, this
could be circumvented by assigning different tasks to distinct threads. This way, multiple clients could
be dealt with separately and simultaneously while processing flights in the meantime. We believe this is
something that could be looked into, in the future, as to improve this application’s performance.
51
3.4.1 Selection Menu: Aircraft & System
This section of the GUI is where the user will select what he pretends to visualize in the time series
window. An aircraft and system must be selected and, by default, the application will select the first
aircraft and system on the respective lists. Since the application is reactive, any change in these menus
will immediately trigger a response from the server.
The aircraft selection widget consists of a drop-down menu that contains every registration number
of the Embraer E190/195 fleet of Portugália. In the example below (Figure 3.19), the selected aircraft is
“CS-TPO”.
The system selection menu is different from the aircraft drop-down menu. We implemented a radio-
button type menu that only allows the selection of one system at a time but, unlike the small aircraft
menu that only presents the current selected aircraft, we wanted the user to be able to easily switch
between the various systems.
Figure 3.19: Selection Menu - Aircraft and System.
In some cases, the selection of a certain system will trigger an additional sub-menu which will be
displayed in the bottom part of this box. For instance, the selection of the APU EGT system prompts the
application to display a radio-button type sub-menu with the options “Start” or “Run”, given the two APU
operating modes require two different monitoring windows, since they present different thresholds.
3.4.2 Aircraft Status Window
The second box on the left side of the application’s window (Figure 3.18) contains information about the
status of the currently selected aircraft. As soon as an aircraft is selected, the application will check
an auxiliary text file that contains information about the fleet’s current health status and update this
window accordingly. It was created to inform the user about the systems that, for the selected aircraft,
52
are in alert or critical status. This way, when the user selects an aircraft, he can check this window to
determine which systems were signalled by the application to be behaving abnormally, without the need
to check them one by one. The methodology used by the program to determine the system’s status will
be explained later in the implementation section.
The layout of this window will depend on the current status of the aircraft (Figure 3.20). If the current
aircraft’s systems are all operating normally, from the application’s point of view, this box will be green
and will only display the messages text box. Otherwise, the layout will either be orange or red, for
the alert and critical status respectively. In those cases, additional text boxes will be displayed, with
information regarding the systems in alert/critical state.
The “Messages:” labelled text box will display several messages indicating the result of actions
performed by the user, such as updates or resets.
Figure 3.20: Aircraft Status - Normal, Alert and Critical.
As seen in the examples above, specifically the center and right boxes, the aircraft status box will
specify the systems that did not present a normal behaviour. If a certain aircraft has systems with critical
and alert status, the overall status of the aircraft will be critical. This means the aircraft status box will be
displaying a red layout to draw the user’s attention.
3.4.3 Application Settings Window
The application settings window contains action buttons that allow the user to access some key functions
of the application. Some of these functionalities are incorporated in the daily task and their inclusion in
this interface was meant to give the user more control and provide an alternative in case the scheduled
task ceases to function properly. The action buttons (Figure 3.21) have the following function:
• Reset Status: this button was implemented to enable the user to reset the current aircraft’s status
back to Normal. This functionality was introduced to nullify all the alert and critical status warnings
of the selected aircraft, which is often desired when the user has already analysed the warnings.
In some cases, the user might want to ignore or discard the warnings because he is already aware
of the faulty systems or knows the warnings are either false positives or unjustified.
• Reset Fleet Status: this action button has a similar function to the “Reset Status” button. In this
case, the application will reset the entire fleet’s system status. After this button is pressed, every
53
system of all aircraft will be at the Normal status.
• Update Status: this button will trigger the function responsible for determining the status of every
system within the entire fleet. This process can take up to 2 minutes and the final result is an
up-to-date status matrix with the current status of every system for each aircraft.
• Update Database: pushing this button will call the Update Flights Routine, described in the ap-
plication overview section. Although this routine is included in the daily scheduled function, it was
important to include it in the applications GUI in the event a user desires to perform an immediate
update of the system files without having to wait for the next scheduled task.
Figure 3.21: Application Settings - Action Buttons.
3.4.4 Time Series Plot
The time series plot is undoubtedly the most important feature of the GUI. This is where the data col-
lected so far will be displayed, and an analysis of the information presented in the graphic could help the
user validate or disregard the unusual data patterns detected by the algorithm. The graph consists of a
time series plot of data points indexed in time order, meaning the program will load the plot data from
the system files, order it chronologically and then plot it.
In some cases, a single plot will contain information from different systems. For instance, when
plotting the hydraulic system pressure data, the graph will contain data sets from the three distinct
systems that comprise the hydraulic system (Figure 3.18). It is possible to select/filter the data sets that
we want visualize by simply clicking on the respective data set names, in the legend.
The Plotly library includes a zoom feature that enables the user to navigate through the time axis in
a very practical and efficient way. The range-selector, located in the top-left corner of the plot window, is
another useful feature that allows the user to re-scale the time axis by narrowing/broadening the time-
window to the selected interval. For example, if the user selected the “1w” option, the time axis would
be adjusted so that the plot would only display data from the last week. The same principle would be
applied for “1d”, last day, “1m”, last month and “1y”, last year.
54
The layout of the graph will adjust to the current system. The vertical axis will correspond to the
parameter that is being monitored and the minimum and maximum Y values were set by us, although it
is possible to re-adjust this axis’ range by click-and-dragging on the axis. Its alert and critical thresholds
are represented by a yellow and red dashed line, respectively.
One of the features we implemented, and based on the request from the future users of this appli-
cation, was a coloured plot background based on the systems’ current state. In the example displayed
in Figure 3.18, the bottom section of the graph was coloured green, meaning that system was operating
within normal standards. Figure 3.22 shows, for the same system, three distinct patterns from different
planes at the same time of the year. The first picture (green) illustrates a healthy system; the second
(yellow) an already degraded system that shows a worrying trend; and the third (red) a severely de-
graded system that was eventually repaired mid-June. The coloured background helps the plot stand
out and draws attention to the relevant region of the plot.
Figure 3.22: Bleed Pressure Oscillation - Normal, Alert and Critical Status.
Additional information such as the time hack, the monitored parameter, its value and units, and the
snapshot parameters will appear when the user hovers the mouse over any given point (Figure 3.23).
Figure 3.23: Hydraulic System Pressure Monitoring - Hover Text.
55
3.5 System Trend Analysis
In this section, we will explain how the application determines the current status of the monitored sys-
tems. This routine is part of the daily task but, as previously mentioned, it can also be manually carried
out by the user in the settings box.
The algorithm we implemented applies two different methods, independent of one another, that will
analyse recent data to identify unusual patterns (Figure 3.24).
Figure 3.24: System Status Analysis - Overview.
The first method provides a simpler and more classic statistical approach to the data. It consists in
using the operating thresholds that we defined in the previous section, in the selection of the monitored
systems. The algorithm will check the percentage of flights, over a recent period, that lie within each
one of the following three regions: normal, alert and critical. For instance, if more than 10% of the last
50 flights present data points are located above the alert threshold, the program will classify that system
as in alert. Similarly, if more than 5% of the data points are located above the critical threshold, we will
classify the system as in critical condition. If both conditions are met, the system will be classified as in
critical condition, since this represents the most serious warning level. These values were established
based on feedback from specialists in the company and can easily be modified in the code by accessing
a particular file that contains every adjustable parameter so that one can modify them without prior
programming knowledge. To demonstrate how this method classifies a system’s status, we selected 50
consecutive flights performed by the aircraft Lambda (Figure 3.25). The data was imported from the
Engine Vibration system file and represents the maximum engine 2 core vibration in the take-off flight
phase. For confidentiality purposes, we modified the thresholds defined previously in the current chapter
and removed the values from the vertical axis.
Figure 3.25: Engine 2 Core Maximum Vibration at Take-Off.
56
In the example provided, which contains a total of 50 flights, 12 (24%) registered a vibration value
above the alert threshold and 1 (2%) above the critical threshold. In this case, only the alert threshold
was violated, since the critical region only contained 2% of the points in its region (< 5%). As such, this
would generate an alert status warning for the Engine Vibration system due to threshold violation.
Even though the threshold violation method helps us identify cases where a fragment of the data lies
within a problematic region, its effectiveness heavily relies on the threshold values that we established.
A significant portion of the limits previously defined were obtained from the aircraft’s documentation.
This means that, if these safety limits are violated, the aircraft’s on-board computer will most likely
detect it and inform the Maintenance Department via ACARS with Crew-Alerting System (CAS) or CMC
messages. This scenario is usually associated with a serious problem that requires immediate action. By
using the same thresholds the aircraft’s systems use to detect faults, the application loses its predictive
nature and becomes more of an informative tool that reacts when the damage is already done. We could
try lowering the thresholds so the program would generate warnings sooner but this would increase the
amount of false positives and it is unclear whether this trade-off would ultimately be beneficial. We
believe a different approach, independent of pre-defined thresholds, should be contemplated.
The second method completely disregards the specificities of the system it analyses, making exclu-
sive use of system file data. This method will compare data within the fleet and determine which aircraft
present a different behaviour from the rest of the fleet. This comparative approach does not require any
thresholds or specific information, since the analysis is conducted under a purely statistical standpoint,
making use of data-mining techniques.
This is achieved by performing a cluster analysis of the already pre-processed data. The algorithm
starts by loading recent flight data from a given system file. It collects data from the last 50 flights of
every aircraft and organizes it into data sets - objects - where each object represents an aircraft. To
exemplify the methodology used, we will demonstrate the steps taken in the cluster analysis of the APU
EGT system (Figure 3.26).
Figure 3.26: APU EGT over 50 flights - fleet comparison.
57
In this analysis, the variables, of quantitative nature, correspond to the snapshot points of a time
series, i.e., to observations of a single variable over a specified time horizon. The following aspect
we wanted to analyse was the impact of temporal correlation within objects, since the proximity mea-
sure selected in the previous chapter does not account for this property. We believe that, when the
aircraft’s systems are functioning normally, flights could be considered as independent events, although
this should not be the case when dealing with degraded systems, since it is very likely that there is a
correlation between the values obtained in consecutive flights. This makes sense if we consider that, in
the time period where the system is degraded, the values obtained will be similar between each other
but considerably different from the ones where the system operates normally (Aircraft Epsilon in Figure
3.26).
Figure 3.27 illustrates the partial Autocorrelation Function (ACF) estimation of the APU EGT monitor-
ing for the aircraft Gamma and Epsilon, where the former behaves normally and the latter shows signs
of degradation.
Figure 3.27: Autocorrelation Function - APU EGT.
The case study presented above shows a clear contrast between the ACFs, particularly for low lag
values. Gamma, in blue, presents a relatively uniform function, implying a lack of dependence between
observations. Epsilon, on the other hand, shows high peaks for low lag values, especially when the
lag value is 1, suggesting a significant autocorrelation and thus a dependence between observations,
as expected. This confirms the lack of independence between variables when data shows abnormal
behaviour. Even though that scenario is less likely to happen and constitutes only a small fraction of the
data sets, the implementation of a distance measure that accounts for temporal correlation could yield
interesting results. However, due to time constraints and given the satisfactory results, this subject was
left out of the scope of this work. P. Montero and J. Vilar [37] provide insight on time series clustering
using R, describing correlation and auto-correlation based proximity measures.
The following step in our cluster analysis is the construction of the dissimilarity matrix, with N being
58
the fleet size under analysis. In our case, the algorithm will determine the sum of the absolute value of
the differences between the 50 observations. This is done by the R function daisy(), which computes all
the pairwise dissimilarities between observations in the data set. The arguments of this function are the
numeric matrix with the snapshot points and the metric that we want to use to calculate the differences,
which in our case is the “Manhattan” metric. The output of this operation, applied to the data from Figure
3.26, is represented in Table 3.21.
Table 3.21: APU EGT - Dissimilarity Matrix.
Alpha Beta Gamma Delta Epsilon Zeta Eta Theta Iota Kappa
Beta 1618 - - - - - - - - -
Gamma 1498 2010 - - - - - - - -
Delta 2119 1899 2399 - - - - - - -
Epsilon 5283 4881 5509 4792 - - - - - -
Zeta 8345 7697 8829 7226 6214 - - - - -
Eta 2190 1944 2274 2309 4977 7069 - - - -
Theta 1507 1899 1627 2082 5782 8944 2401 - - -
Iota 1417 1825 1855 1774 4720 7534 1801 1728 - -
Kappa 1583 1731 1689 2056 5508 8514 2299 1382 1824 -
Lambda 1558 2340 1734 2335 5821 9109 2684 1361 1811 1417
As expected, the dissimilarity matrix highlights the major differences in the behaviour within the fleet.
Higher values show us larger discrepancies between those two aircraft. Zeta and Epsilon show a big
disparity in comparison with the rest of the fleet. The values presented in this matrix have little meaning
without context, since the values themselves carry no useful information, i.e., since the algorithm has
no intelligence about the system, it has no way of telling if a certain value reflects healthy or degraded
behaviour. What it does, however, is compare the values of the dissimilarity matrix and, based on the
discrepancies, identify the outlying objects.
Afterwards, the data sets are compared with each other and the algorithm will arrange the data
sets into groups (clusters) according to data pattern similarity. This way, aircraft that present a similar
behaviour will be in the same cluster. More data sets means there is a higher likelihood of finding a
large cluster with healthy systems and a small cluster with degraded systems. As Portugália Airlines
continues to increase the size of its homogeneous fleet and thus the amount of “healthy” data, so does
the accuracy of our results, as the difference between an healthy and unhealthy system becomes clearer.
As mentioned in section 2.3, we chose to conduct this analysis by means of a hierarchical method,
the dendrogram, which presents a simple graphical summary of the data from the dissimilarity matrix.
R function hclust() presents hierarchical cluster analysis on a set of dissimilarities and several
methods for analysing it. To do so, we need to provide it, as input arguments, a dissimilarity structure,
such as a matrix, and the agglomeration method to be used. We have decided to apply the “ward.D2”
method, also called minimum variance method, which minimizes the total within-cluster variance. At
each step the pair of clusters with minimum between-cluster distance are merged.
Afterwards, we need to cut the dendrogram horizontally at a particular height in order to partition
59
the data into disjoint clusters, which are represented by the vertical lines that intersect it. This stage of
the process is critical, since the height we decide to cut will determine how many clusters we will have
and what objects they include. If we cut too low, we end up with several clusters and no clear way of
comparing them. Cutting too high will often get us two clusters with no significant difference in terms
of behaviour, since hierarchical methods impose hierarchical structure whether or not such structure
actually exists in the data.
Fortunately, R language provides a package for determining the best number of clusters. NbClust
package provides over 20 indices for determining the number of clusters and suggests the best clustering
scheme to the user from the different results obtained by varying the number of clusters. NbClust()
requires, as input arguments, the dissimilarity matrix, the distance measure, the clustering method, and
the maximum and minimum number of clusters. The output of the function includes the optimal number
of clusters suggested by each one of the indices as well as other supporting data. The overall suggestion
on the best number of clusters is decided according to the majority rule. For demonstration purposes,
we applied this function to the data from the example illustrated in Figure 3.26. Part of its output is listed
in the box below (Listing 3.1).
Listing 3.1: NbClust function output
*******************************************************************
* Among a l l i n d i c e s :
* 8 proposed 2 as t h e b e s t number o f c l u s t e r s
* * * * * Conclusion * * * * *
* According t o t h e m a j o r i t y r u l e , t h e b e s t number o f c l u s t e r s i s 3
*******************************************************************
Given the clear behavioural difference between aircraft Zeta and Epsilon in comparison to the rest
of the fleet, one would expect the number of clusters to be 2: one small cluster with those two aircraft
and a big cluster with the rest of the fleet. This partition would make it fairly simple to distinguish healthy
aircraft from faulty ones, since a small number of clusters means a high between-cluster variance. By
identifying the aircraft that lie in each cluster, we could pinpoint which aircraft are likely to show abnormal
patterns - the ones from the small cluster. However, in the output listed above, the function suggested the
best number of clusters to be 3, which somewhat differs from our initial expectations. It is possible that
the algorithm has separated Zeta and Epsilon into different clusters since, although Zeta and Epsilon
show distinct data patterns from the rest of the fleet, their behaviour is far from similar, considering
60
Zeta maintains a steady behaviour and Epsilon a more abrupt one. Unfortunately, NbClust() does not
specify which objects lie in the clusters or their size. Conveniently, R provides a function, cutree(),
which performs a cut in the dendrogram, into several clusters, either by specifying the desired number
of clusters or the height of the cut. Since the algorithm has no intelligence over the system, it is not
possible to know at what height should the dendrogram be cut. However, given the output of NbClust(),
we can specify how many clusters we want the dendrogram to be cut in. In order to perform the cut, we
need to provide cutree() a dendrogram, which is obtained from the hclust() function, and an integer
scalar with the desired number of clusters, which is suggested by the NbClust() function.
Applying the NbClust() function to data from the example of Figure 3.26, with the number of clusters
suggested in Listing 3.1, returns the dendrogram shown in Figure 3.28:
Figure 3.28: APU EGT - Dendrogram Cut.
The dendrogram above allows to visualize the relations between aircraft. The horizontal lines that
connect objects are placed at a certain height based on the dissimilarity values. Similar objects are
paired together and, the smaller the height between objects, the more similar they are. For instance,
although Lambda and Theta are paired together, their behaviour is identical to Kappa’s, since the height
difference between the horizontal lines is practically nil. The difference between Zeta and Epsilon com-
pared with the rest of the fleet also becomes quite clear. The height of the cut will determine how many
clusters will be formed and their constitution. If the cut was made below every bifurcation, the result
would be 11 clusters, each one with one object. This prospect would yield no meaningful results, since
the algorithm would have no way of highlighting the objects that presented unusual patterns. Contrarily,
if we were to cut this dendrogram before any bifurcation, we would end up with 2 clusters: one contain-
ing Zeta and Epsilon, and the other containing the rest of the fleet. This would allow the algorithm to
differentiate the “good” cluster from the “bad” one by their size.
61
Figure 3.28 includes a cut below the bifurcation of Zeta and Epsilon, which divides the dendrogram
into 3 clusters:
• Cluster 1: A big cluster containing 9 objects, which corresponds to the set of aircraft that present
a healthy/normal behaviour.
• Cluster 2: A small cluster containing only one object, Zeta, reflecting a steady albeit damaged
system.
• Cluster 3: A small cluster also containing only one object, Epsilon, which reflects an unusual and
inconsistent behaviour.
This R function not only determines the size of the clusters but also specifies the objects that lie within
each one of the clusters. At this point, the algorithm acknowledges the existence of different clusters,
their sizes and objects. Even so, it still does not recognize which clusters reflect normal or abnormal
behaviour. Therefore, we need to implement a methodology that allows the program to identify the
objects that show anomalous data patterns.
We verified that, when a specific system is functioning normally in the entire fleet, our algorithm
would arrange the objects into a high number of clusters. On the other hand, the existence of a severely
damaged system would often lead to a small number of clusters. These scenarios make sense since
the agglomeration method focuses on minimizing the total within-cluster variance while maximizing the
between-cluster variance. This means that, if all aircraft behave similarly, small behavioural differences
carry more weight and will cause the function to separate those objects accordingly, ending up with
many small clusters without a significant difference between them. However, this is not the case if there
is at least one aircraft that displays unusual data patterns, since in that case, the difference between
faulty aircraft and the rest of the fleet is much bigger than the differences between healthy aircraft. This
scenario would cause the algorithm to separate the objects into a small number of clusters, otherwise
the between-cluster variance would suffer a significant raise. Therefore, based on the output of the
NbClust() function for a particular system, we can infer the overall behaviour of the fleet.
We analysed several systems over time and studied their behaviour, cross-checking the alerts the
program would produce with maintenance reports and concluded that too many false warnings would
be generated if we considered every arrangement. As a solution, we have decided to only analyse
the scenarios where the algorithm separates objects into 2 or 3 clusters, since for every other case we
noticed the existence of too many false positives, as the differences between clusters did not reflect
meaningful behavioural disparities.
Thus, assuming there are always more healthy aircraft than faulty ones and by considering 2-3 cluster
arrangements exclusively, we establish the “healthy” cluster to be the one with the highest number of
objects. As for other clusters, the application will classify its objects as in state of alert since their patterns
present a worrying trend. In the previous example, as the algorithm had divided the dendrogram into 3
objects, it would identify the objects from the smaller clusters - Zeta and Epsilon. The result would be
the modification of the “APU EGT” system status, in both aircraft, from normal to alert.
62
Figure 3.29 summarizes the several steps performed by the algorithm in the cluster analysis. The R
functions used in this analysis are also represented in the flowchart.
Figure 3.29: Cluster Analysis.
The stage where the system’s status is updated will depend on the number of clusters determined by
NbClust(). In case this is higher than three, the algorithm will reset every aircraft’s system status back
to normal. If it is less than three, it will change the status of applicable aircraft to alert, maintaining the
rest at normal status.
Once the cluster analysis is completed, the algorithm will execute the threshold violation routine,
overwriting the necessary statuses. This ensures the most serious status level remains at the end of the
system status analysis routine.
The number of flights plays an important role in both these analyses. In one hand, a small sample of
flights means that abnormal patterns will trigger a warning sooner, which is desired if that pattern does,
in fact, represent the consequences of a faulty system. If it does not, then the application is more likely
to produce false warnings since outliers carry more weight as we reduce sample size. On the other
hand, if we increase the size of our flight sample excessively, dubious data patterns will be out-shined
by the normal behaviour that precedes it and will require a longer time to be identified. Reaching the
optimal sample size is not simple nor straightforward but, with time, experience may help achieve the
most advantageous value.
63
64
Chapter 4
Results and Case Studies
In this section we will present some results of the system trend analysis algorithms that we implemented
in the application. Our focus here is to demonstrate how the application reacts to unusual system be-
haviours that we identified in documented reports of system faults and repairs. Due to space limitations,
we will not be able to illustrate scenarios for all the monitored systems, so we will address the most crit-
ical ones in the context of maintenance. As such, we will focus on the engine pneumatic bleed system,
responsible for cabin acclimatization and pressurization during high altitude flights. This system has
proven to be critical in terms of reliability.
The scenarios discussed in this section will also determine if the methodology used to obtain the sys-
tem snapshot points yields meaningful results. For confidentiality purposes, aircraft registration codes
have been replaced by Greek words, randomly assigned, and dates have also been modified.
4.1 Problem Description
In the introduction of this work, we mentioned that even with the adoption of preventive maintenance
programs, unexpected failures still occur quite frequently, which could lead to great financial losses if,
for instance, a given failure were to cause an AOG scenario with the aircraft away from its home base. It
is also mentioned that, although unpredicted, some failures could be prevented if a proper system trend
analysis was conducted, since these incidents are often preceded by a deterioration pattern, which is the
result of an increasingly faulty behaviour. In many cases, these anomalous data patterns start to unravel
at a relatively early stage. As such, we wish to uncover and identify those patterns, and produce alerts
so preventive actions can be performed beforehand, thus reducing the number of unforeseen failures.
4.2 Aircraft Health Monitoring
In this section, we will present two examples of the time series plots generated by the application. The
purpose of this section is to verify if the data points used to monitor the systems reflect the desired
properties and if system faults or deterioration patterns manifest themselves in the data.
65
The first example we wanted to present concerns Aircraft Lambda’s Air Data System. As explained
in the previous chapter, an analysis of the difference between the pilot’s and co-pilot’s altitude indicators
could indicate problems in the integrated pitot/static/AOA sensors, which are essential components for
data collection. Figure 4.1 shows an abrupt data shift, suggesting a failure or malfunction in this system.
Shortly after this incident, several reports indicated high altitude differences, which is consistent with
the time series data (vertical axis was hidden for the sake of confidentiality). It is worth noting that, for
system trend analysis, the algorithm only uses data points collected above 20,000 feet.
Figure 4.1: Altitude Split Monitoring - Aircraft Lambda.
The following example regards Lambda’s center electronics bay air flow. In this example, no failures
were detected, although it is possible to identify a slow degradation pattern over time, reducing the air
flow from about 120 f t3 /min to almost 100 f t3 /min, still well within the normal operating region. We
believe this degradation trend is quite normal, and could be related, for example, to the accumulation of
dust in the system’s fans/ducts over time.
Figure 4.2: Center Electronics Bay Air Flow Monitoring - Aircraft Lambda.
66
4.3 Case Studies
4.3.1 Case I - Engine Bleed System (Aircraft Delta)
The first analysed scenario was the result of multiple Engine 2 Bleed System possible fault messages
produced by Aircraft Delta, which occurred twice on the 17th of Month 6 and later on the 21st. On the
22nd, this system was documented as inoperative. In some occasions, “BLEED FAIL” messages, which
are generated by the aircraft’s CMC, turn out to be false alarms or one-off cases. This situation, however,
not only included several fault messages in a short time interval but it also required a maintenance action
that reinstated the system back to normal functionality.
Figure 4.3 illustrates the system data plot regarding the “Bleed System Pressure Oscillation” moni-
toring, where the last 6 months of snapshot point data of Delta are represented.
Figure 4.3: Engine 2 Bleed Pressure Oscillation Monitoring - Aircraft Delta.
A visual examination of this system’s time series plot leaves no doubts about the serious degradation
pattern that it presented in the couple of months preceding the failure. It is possible to observe a slow
albeit consistent increase in the standard deviation values of the engine bleed pressure during cruise,
which reaches critical values until it drops back to a normal range of values, after a repair procedure.
It seems this degradation behaviour began at the end of Month 3, and then displayed a continuously
increasing trend until the end of Month 4, where the snapshot point values started to exceed the alert
threshold. At a certain point, around the first week of Month 5, the threshold violation algorithm would
produce an alert warning that would last until the last week of Month 5, where the status of this system
of Delta would be changed to critical.
In this case study, the application would notify the user of an alert threshold violation at least 5 weeks
prior to the failure, which in our opinion is more than enough time to assess the situation, allocate the
resources and perform the corrective measure, which will be discussed later in this example.
67
The scenario described above only mentions one of the two methods used by the algorithm to per-
form a system trend analysis. The results obtained were quite satisfactory but we will take this opportu-
nity to determine how the other method, fleet comparison, would perform.
The output of a cluster analysis over the fleet’s time series data is a set of groups containing different
aircraft. As mentioned in section 3.5, we aim at scenarios where this output is three clusters or less,
which means there is a high behavioural difference between clusters. In this sense, we performed a
series of daily cluster analyses starting in Month 4, as our aim was to determine at which point the
number of formed clusters was three or less.
Surprisingly, the first 15 days of analysis presented a similar scenario, constantly returning two clus-
ters: one with a single aircraft, Alpha, and the other with the rest of the fleet, which at that moment had
8 aircraft. It made sense that the aircraft under analysis, Delta, was still not being separated from the
rest of the fleet, since, based on Figure 4.3, it showed a seemingly normal behaviour until late Month
4. However, the separation of a single aircraft, Alpha, into a separate cluster strongly suggests a faulty
bleed system, which we will not scrutinize due to space limitations.
Resuming the daily analysis, we do not obtain particularly interesting results until the 7th of Month 5,
where the algorithm once again returns only two clusters but this time with Alpha and Delta in the same
cluster, and separated from the remaining (Figure 4.4).
Figure 4.4: Engine 2 Bleed System Fleet Comparison - Dendrogram.
In this scenario, this approach would generate a warning message at the 7th of Month 5, presenting
a similar outcome to the threshold violation approach. This is not coincidental since, for this particular
system, we established the thresholds based on an analysis of the system’s behaviour over thousands
of flights rather than the manufacturer’s documentation. This way, a slight pattern shift will easily cross
the defined thresholds, since these were designed based on healthy behaviour. This is often not the
case if we consider the limits defined by the manufacturers since they often establish operating margins
according to the operating limitations of components, which turn out to be higher than (initial) abnormal
operating conditions.
68
To conclude this case study, let’s consider its timeline, where the major events described above are
displayed chronologically on top of the “Engine 2 Bleed Pressure” monitoring time series plot (Figure
4.5).
Figure 4.5: Case Study I - Timeline (Numbered vertical lines point out events discussed in the text).
The vertical lines displayed in the figure above represent the most important events of this case
study. Each event was assigned a number, with further information provided in the list below.
1. 29th Month 4: Alert threshold violated - over 10% of the last 50 flights located within alert region.
2. 7th Month 5: Fleet comparison detects unusual behaviour in Delta and Alpha.
3. 22nd Month 5: Critical threshold violated - over 5% of the last 50 flights located within critical
region.
4. 17th Month 6: Engine 2 Bleed System possible fault message, twice on the same day.
5. 21st Month 6: Engine 2 Bleed System possible fault message.
6. 22nd Month 6: Engine 2 Bleed System deemed inoperative.
7. 28th Month 6: Engine 2 Bleed System successfully repaired.
An examination of Figure 4.5 allows to identify a particularly unexpected situation. Even though
the repair procedure was undertaken on the 28th of Month 6 (line no. 7), the system seemed to have
re-established a normal operation immediately after being considered inoperative (line no. 6). After
examining the respective work-orders, we found out that on the 22nd of Month 6 and after unsuccessful
repair attempts, this system was transferred to the Hold Item List (HIL). This list represents the damaged
components aboard the aircraft that were dispatched in accordance to the Minimum Equipment List
(MEL). Effectively, this means the aircraft was considered fit to fly despite having an inoperable engine
bleed system. One of the limitations however is that, in this condition, its maximum allowed altitude was
69
31,000 ft. As such, the apparent healthy behaviour of this system was actually due to the influence of
the other engine’s bleed system operation, since in this scenario a cross-bleed valve is opened to allow
air from the operative bleed system to flow into the other system, as to compensate its inoperability.
The procedure that solved this issue was the replacement of the engine no. 2 NAPRSOV (Nacelle
Pressure Regulating Shut-Off Valve), which regulates the manifold pressure in the bleed system.
4.3.2 Case II - Engine Bleed System (Aircraft Lambda)
In this case study we will describe a similar situation as the one presented in the previous section,
but concerning the Engine 2 Bleed System of Aircraft Lambda. While searching through maintenance
reports we came across several reports of possible fault messages and anomalous behaviour over the
span of two weeks, which strongly suggested a problem with this system.
Figure 4.6 depicts the behaviour of Lambda’s Engine 2 Bleed System over 6 months, where each
point represents the standard deviation of the pressure parameter during cruise flight phase.
Figure 4.6: Engine 2 Bleed Pressure Oscillation Monitoring - Aircraft Lambda.
Once again, this system’s time series plot shows a clear deterioration pattern that ends sharply,
probably due to maintenance intervention. In fact, this scenario suggests a more serious problem than
the one presented in case study I, since this degradation pattern shows a considerably faster progres-
sion. The deterioration appeared to have begun around the first half of Month 5, followed by a rapid and
persistent increase until the first week of month 6, where it seemed to stabilize for a couple of weeks
before dropping back to normal levels.
The threshold violation algorithm would produce the first alert on the 6th of Month 6, where we
verified the existence of 5 points, out of the last 50, in the alert region. On the 25th of Month 5, this
function would change the status of this system from alert to critical.
70
Afterwards, we performed a daily cluster analysis, starting in the beginning of Month 5, in order
to determine when the fleet comparison algorithm would detect anomalous bleed system behaviour in
Aircraft Lambda. It is worth noting that, between Month 4 and Month 6, aircraft Alpha and Delta were
also presenting faulty systems. This can be seen in Figure 4.4, where the cluster analysis conducted on
the 7th of Month 5 had placed them in the same cluster. As such, we will take this opportunity to examine
how this algorithm performs when dealing with multiple faulty systems simultaneously, considering the
data example in Figure 4.7.
Figure 4.7: Engine 2 Bleed System time series - Lambda, Alpha and Delta.
An examination of the graph above allows to verify that, in the beginning of Month 4, Alpha was
showing abnormal behaviour, while the other two were indicating normal operation. The dendrogram
from the previous case study, depicted in Figure 4.4, isolates Alpha and Delta into a single cluster,
which is consistent with the data above, since both aircraft had been presenting unusually high values
the recent week (1st-7th of Month 5). At that time, Lambda was still presenting a normal behaviour. One
week later, on the 14th of Month 5, the fleet comparison algorithm had once again arranged the fleet
into two clusters, but this time with Delta isolated in a cluster (left dendrogram of Figure 4.8). This is
in accordance with the data above, since at that date Alpha was already presenting normal behaviour.
Eventually, on the 22th of Month 5, the algorithm detected anomalous data from Lambda, adding it to
the degraded cluster that contained Delta (right dendrogram of Figure 4.8).
The results obtained in this case study have shown that the methodology used to determine the
status of a given system is working as intended, being capable of identifying multiple faulty systems
simultaneously while quickly adapting to pattern changes. As referred in the end of section 3.5, this
analysis is highly influenced by the number of analysed flights. Reducing this value would allow the
application to identify unusual patterns sooner but would very likely increase the number of false warn-
ings, since in those scenarios outliers carry more weight. Too many false positives will reduce the user’s
trust in the application and lead to meaningful results being ignored in the future. Based on the results
obtained, we believe this parameter does not require further calibration.
71
Figure 4.8 illustrates the two dendrograms mentioned above, obtained on the 14th and 22nd of
Month 5. It is worth mentioning that, despite Lambda not being in the “degraded” cluster on the 14th of
Month 5, it is possible to verify that it had already started to shift towards Delta, when comparing with
the dendrogram in Figure 4.4. On the contrary, Alpha had started to move towards the main cluster,
indicating its return to normal operation.
Figure 4.8: Engine 2 Bleed System Fleet Comparison - Dendrograms.
A timeline of this case study is presented below, with the main events mentioned above chronologi-
cally organized over the “Engine 2 Bleed Pressure” time series plot of Lambda (Figure 4.9).
Figure 4.9: Case Study II - Timeline (Numbered vertical lines point out events discussed in the text).
From the timeline above, we can identify the following events:
1. 14th Month 5: Alert threshold violated - over 10% of the last 50 flights located within alert region.
2. 22th Month 5: Fleet comparison detects unusual behaviour in Lambda and Delta.
72
3. 25th Month 5: Critical threshold violated - over 5% of the last 50 flights located within critical
region.
4. 6th Month 6: Engine 2 Bleed System possible fault message.
5. 10th and 11th of Month 6: Engine 2 Bleed System possible fault message.
6. 16th Month 6: Engine 2 Bleed System possible fault message and deemed inoperative.
7. 20th Month 6: Engine 2 Bleed System successfully repaired.
The scenario described above is fairly identical to the one presented in case study I. Although the
degradation pattern shown in the first case study developed slower than this example, the final stages
of the anomalous behaviour were quite similar, as the time interval between the first documented failure
and the ultimate inoperability of the system was relatively small. Once again, we verified that the repair
procedure was conducted a few days after normal operation was resumed, which was also due to the
assignment of this system to the HIL, as explained in study case I. The replacement of the NAPRSOV,
on the 20th of Month 6, appeared to have solved this problem.
4.3.3 Case III - Engine Bleed System (Aircraft Kappa)
In this case study, we will once more examine the performance of the “Bleed Pressure Oscillation”
monitoring algorithm, regarding the Engine 1 Bleed System of aircraft Kappa. In this example, the
degradation pattern is not as consistent as in the previous cases, where a clear and gradual growth was
observed. This can be seen in Figure 4.10, which presents the latest 6 months of data.
Figure 4.10: Engine 1 Bleed Pressure Oscillation Monitoring - Kappa (Grey Zones define time gaps
discussed in the text).
An examination of Figure 4.10 allows to identify some unusual patterns, highlighted in the grey re-
gions. Firstly, it is possible to observe an increasing data trend in the beginning of Month 2 (region 1),
which seemed to normalize in the following weeks without any maintenance intervention.
73
Then, in the second week of Month 3, a sudden increase of the standard deviation values included
several flights in the critical region (region 2). We will analyse with more detail the events that occurred
in this time window since the outcome is different from the previous case studies. In this sense, let’s
consider a timeline that represents the main events associated to the abnormal data pattern highlighted
by region 2 in Figure 4.10 (Figure 4.11).
Figure 4.11: Case Study III - Timeline (Numbered vertical lines point out events discussed in the text).
From the timeline above, we can highlight the following events:
1. 16th Month 3: Alert threshold violated.
2. 18th Month 3: Critical threshold violated and unusual behaviour in Kappa (fleet comparison).
4. 8th Month 4: Engine 1 Bleed System pressure oscillation in cruise.
6. 10th Month 4: Engine 1 Bleed System pressure oscillation in cruise.
8. 17th Month 4: Engine 1 Bleed System possible fault message and promptly repaired.
It would appear that the events presented above (Figure 4.11) describe a similar scenario as the
ones we analysed in the previous case studies. However, looking into region 3 (Figure 4.10), we verify
the existence of what seems to be a continuity of the increasingly faulty behaviour of region 2, that was
merely interrupted for a few days after the repair procedure (line 8 in Figure 4.11), which consisted in the
replacement of the NAPRSOV. We do not know what caused this unusual data pattern but, if we look
closely at the data in region 3, we can also distinguish a group of points that lie in the normal region,
suggesting healthy behaviour. This is noteworthy since, in previous cases, there was a clear data shift
74
to critical regions and in this case it appears that we are dealing with two separate groups of points that
overlap in the same time window. Moreover, we did not find any reports of failures or other incidents in
this interval, suggesting healthy engine bleed operation.
Eventually, points stabilized in the normal operating region, although showing a bigger dispersion
than usual. As such, we believe the maintenance action undertaken on the 17th of Month 4 fixed one of
the problems of this engine’s bleed system, although the existence of another underlying issue is prob-
able. The normal behaviour presented between the regions 3 and 4 was short-lived, as a degradation
pattern started to develop early in Month 5. We only possess flight data prior to the 7th of Month 6
and, therefore, we are unable to properly study the scenario depicted in region 4, although maintenance
reports indicate multiple failures on the 20th of Month 6, which is in line with this worrying trend.
4.3.4 Case IV - APU EGT (Aircraft Zeta)
This case study addresses the scenario presented in section 3.5, where we exemplify the methodology
used in a cluster analysis. The circumstances of this example are considerably different from the pre-
vious cases and present a good opportunity to test our algorithm. We verified that, prior to the issue
described in this case study, there were no documented reports of failures or other problems related to
this aircraft’s auxiliary power unit. Shortly after an unusual APU EGT data shift, several reports started
to emerge, which strongly suggested a faulty operation.
Figure 4.12 presents the progression of aircraft Zeta’s APU EGT over a year, where each point
represents the maximum temperature value during its start operation.
Figure 4.12: Auxiliary Power Unit EGT Monitoring Zeta - Start Mode.
This situation is rather unusual since, in the previous cases, there was usually an increasing data
trend that indicated a slow system/component degradation over time. In this case, however, the temper-
ature values simply shifted abruptly to 100-200 °C higher, maintaining a steady and apparently uniform
evolution. The data pattern changed suddenly on the 22nd of Month 8, and remained in a constant
75
range of values until the most recent flight date, the 25th of Month 13. During this time, we discovered
multiple reports of abnormal behaviour and failures regarding this system, which supports the unusual
data.
Another particularity of this scenario is the fact that, although this data drift is unusual, the values
remain within the normal domain for this operation, meaning the classical threshold violation approach
would be unable to detect this irregular trend. This is expected to happen on a frequent basis, since
for many systems, the application uses thresholds defined by the manufacturer, which tend to be signifi-
cantly higher than the range of values a system normally operates at. Lowering these limits would allow
the application to detect pattern deviations earlier. At the moment, given the relatively small amount of
data, and as new aircraft are entering the fleet, this is still not a very viable option since the knowledge
about the normal behaviour of all systems is reduced. This is something that should be looked into in
the future.
As seen in the previous section, the algorithm was eventually capable of identifying abnormal APU
Start Operation in Zeta, also highlighting a strange behaviour in Epsilon. We decided to verify if this
abnormal behavioural shift of Zeta, which happened on the 22nd of Month 8, could also be seen in the
APU EGT Run Operation monitoring plot (Figure 4.13).
Figure 4.13: APU EGT Monitoring Zeta - Start and Run Modes.
Surprisingly, the results obtained did not show any meaningful pattern changes in the run operation,
and were identical to the rest of the fleet. This is rather strange since the APU start operation lasts about
5-15 seconds, and this unit usually operates over 10 minutes per flight. One would expect a substantial
rise in temperature in the first seconds of operation to have some sort of consequences in the remaining
operation. Although this could be true, it is not reflected in the monitoring methodology used for the APU
EGT in run operation and therefore would not be detectable through fleet comparison.
This particularity shows how important it was to separate the distinct APU operations in our applica-
tion, since otherwise we would not have been able to detect this incident.
Nonetheless, our application did detect this unusual trend, placing Zeta in a separate cluster, which
can be seen in Figure 3.28 of the previous section. Additional data such as the dissimilarity matrix used
to build the dendrogram and a time series comparison between the fleet can be found in Table 3.21 and
76
Figure 3.26, respectively.
Figure 4.14 presents a timeline of this case study. It is worth mentioning that only the fleet comparison
approach was capable of detecting the behavioural drift that occurred on the 22nd of Month 8.
Figure 4.14: Case Study IV - Timeline (Numbered vertical lines point out events discussed in the text).
Several reports were created over the months, due to the long persistence of this system fault.
Since many reports addressed the same issue, we decided not to specify them in Figure 4.14. The non-
numbered vertical lines correspond to reports of “possible APU high oil consumption”, and the remaining
to the following events:
1. 24th Month 8: Fleet comparison detects unusual behaviour in Zeta and Epsilon.
2. 13th Month 9: First report of possible APU high oil consumption.
3. 31st Month 9: APU starter problems.
4. 2nd Month 11: APU FMU/WRG degraded message.
5. 20th Month 12: APU possible fault message during start operation.
6. 28th Month 12: APU possible fault message during start operation.
7. 31st Month 12: APU possible fault message during start operation.
The scenario presented above illustrates the severe consequences of the EGT increase in start
mode, since prior to that event there were no documented reports of failures or abnormal behaviour
related to the APU regarding this particular aircraft. Based on the data above, it seems this issue had
yet to be resolved, as the over-temperature pattern showed no sign of recovery. In this example, the
algorithm we implemented was able to autonomously detect abnormal system behaviour just two days
after the incident.
77
78
Chapter 5
Conclusion
In the introduction chapter, we presented the main objectives of this thesis, which consisted in the
development of an application capable of monitoring some key systems of the Embraer E190/195, in the
context of maintenance. Once again, we should mention that this aircraft health monitoring application
is not meant to be used for flight safety purposes but rather to promote a more efficient maintenance
operation. All the failures presented in this work were not significant in terms of safety, and are part of
the daily operation obstacles that airline companies face. Thus, this work aims to reduce the occurrence
of failures, based on flight data analysis, therefore reducing aircraft downtime and ultimately saving the
company money. In the following sections, we will provide an insight on the main achievements of this
work and discuss future developments that could be made to improve this application.
5.1 Achievements
Firstly, we developed a routine that filtered the relevant information from the large set of flight data
collected since the fleet introduction. This process included the selection of the most critical systems
maintenance-wise, the implementation of methodologies to extract significant information from flight data
and the storing operation into system files. Afterwards, we implemented a web browser application that
allows the user to visualize and interact with the data previously refined. This feature proved to offer
a rather practical and intuitive method of flight data interpretation. It was possible to observe multiple
system/component degradation patterns, from the more gradual ones, indicating an over-time decline in
performance, to more abrupt behavioural shifts, caused by a sudden failure. We verified that, for some
systems, it was possible to observe the degradation patterns that ultimately led to a failure.
Even though the visual approach already yielded the desired results, it required an exhaustive pro-
cess that consisted in individually interpreting the time series plots of every system for each aircraft.
As to improve this program’s functionality, we implemented programming routines capable of perform-
ing a trend analysis on every aircraft’s systems autonomously. This way, the user would be notified of
abnormal tendencies and would only resort to the application to validate the authenticity of the warning
messages. If justified, maintenance actions could be undertaken, thus preventing imminent failures.
The process of detection and identification of degraded behaviour was performed by two separate
methodologies. One was based on operational thresholds, whose repeated violation indicated abnor-
mal system performance. Although this approach requires knowledge of the expected behaviour of a
system, which is not always possible to determine, it demonstrated to be very effective in detecting the
79
early stages of the deteriorating process, generating warning messages several weeks prior to failing
incidents. The second methodology, of comparative nature, made use of data-mining techniques to
identify anomalous data patterns by comparing the systems’ data within the fleet. This approach also
proved to be successful in identifying early precursors of system faults in relatively early stages. One of
the advantages of the fleet comparison approach is its complete disregard for system intelligence. This
particularity means this analysis is conducted under a statistical standpoint, neglecting any sort of user
bias motivated by a misconception of the system’s normal behaviour.
In conclusion, we consider the objectives stated in the introduction were fully accomplished. We
believe the user interface is practical and simple to navigate, offering the user visual aids and guidance
towards the relevant systems. We verified that, for many systems, the abnormal data behaviours iden-
tified were strongly correlated to faulty behaviour and failure reports. The application also proved to be
resilient to distinct scenarios and systems, consistently identifying erroneous patterns in their primary
stages. From our perspective, the introduction of sophisticated data analysis techniques undoubtedly
yields remarkable results in the context of predictive maintenance, albeit the degree of success is heavily
reliant on the amount of dedication, energy, and resources allocated into these procedures.
5.2 Future Work

We acknowledge this application still has a lot of room to grow. Since we developed this program
from the very beginning, a lot of focus was put into data import/export operations as well as graphical
user interface design and implementation. In turn, less time than desired was devoted into scrutinizing
the numerous available data mining techniques. Although the results obtained were satisfactory, we
did not test all the possible configurations of proximity measures, linkage methods and data mining
functionalities. Different arrangements could enable the algorithm to identify abnormal patterns sooner
or to distribute objects differently. Part of the algorithm makes use of built-in R functions that suggest
the optimal number of clusters for a certain data set configuration, making use of over 20 indices. It is
very likely that, in the scope of this work, not all the indices generate productive results and a further
comprehension behind each one of these indices and their measures could be beneficial. In this sense,
we believe further investigation and testing should be done over this subject.
Throughout the dissertation, we mentioned some weaknesses of the threshold violation methodol-
ogy, more specifically how the operational thresholds defined by the manufacturer are too conservative
in the context of this application. We believe these thresholds should be defined based on the normal
behaviour of the systems rather than on the operational limits of the components. This way, a slight
pattern deviation from the normal range of values would place data points inside the alert region earlier,
thus ensuing a user warning sooner. The relatively recent introduction of the Embraer E190 in Portugália
Airlines’ fleet means there is still not enough data to clearly define the normal and abnormal operational
thresholds. As the fleet size increases and more maintenance reports are generated, unusual data pat-
terns could be cross-checked with similar patterns from the past and the respective work-orders. This
way, the process of determining the normal operational limits becomes a more viable option. As such,
we suggest a revision of all the systems’ operational thresholds based on the historical behaviour of the
fleet rather than on the aircraft’s documentation, similarly to the methodology used to obtain the engine
bleed pressure standard deviation thresholds.
80
Bibliography
[1] AIRBUS. Growing Horizons. AIRBUS S.A.S., April 2017. Airbus Global Market Forecast 2017-
2036.
[2] Vega, D. J. Gonzales, Pamplona, D. Alberto, Oliveira, and A. V. M. Assessing the influence of the
scale of operations on maintenance costs in the airline industry. Journal of Transport Literature.
[3] A. Cook, G. Tanner, V. Williams, and G. Meise. Dynamic cost indexing – managing airline delay
costs. Journal of Air Transport Management, 15(1):26 – 35, 2009.
[4] M. Bruno. Data Crunch. Aviation Week & Space Technology, pages 37–39, May 29 - June 11 2017.
Maintenance, Repair and Overhaul.
[5] T. Hoyland, C. Spafford, and A. Medland. MRO BIG DATA – A LION OR A LAMB? Oliver Wyman,
2016. Innovation and Adoption in Aviation MRO.
[6] R. Brown. The Connected Fleet: Further Implications of Aircraft Health Monitoring for the Aviation
Supply Chain. ICF, 2017.
[7] Boeing. Real-Time Operations - Airplane Health Management. Boeing Commercial Airplanes,
2012. Boeing EDGE Information Services.
[8] AIRBUS. Real-Time Aircraft Health Monitoring. Airbus Commercial Aircraft. AIRMAN.
[9] Embraer. AHEAD - Aircraft Health Analysis and Diagnosis. Empresa Brasileira de Aeronáutica, .
[10] SAFRAN. Aircraft Condition Monitoring System (ACMS). Safran Electronics & Defence.
[11] K. E. . Maintenance. Prognos: the Predictive Aircraft Maintenance tool. AIRFRANCE Industries.
[12] L. Technik. Condition Analytics. Lufthansa.
[13] Embraer. Maintenance Training Manual. Embraer S.A., . Embraer ERJ-170/190 (GE CF34) General
Familiarization.
[14] B. Vasigh, R. Taleghani, and D. Jenkins. Aircraft Finance: Strategies for Managing Capital Costs in
a Turbulent Industry. J. Ross Publishing, 2012.
[15] C. Engineering. ARINC Protocol Tutorial, June 2000.
81
[16] A. I. Technologies. ARINC 429 Protocol Tutorial, November 2010.
[17] ICAO. Operation of aircraft. International Standards and Recommended Practices Part I, Inter-
national Commercial Air Transport — Aeroplanes, International Civil Aviation Organization, July .
Annex 6 to the Convention on International Civil Aviation.
[18] Embraer. Aircraft Maintenance Manual - System Description Section. Embraer S.A., São José dos
Campos, São Paulo, Brasil, August 2008. Revision 25 - 22 September 2017.
[19] A. S. de Oliveira Simões. Programming/Decoding of flight data from an airline’s A320-200 fleet -
Practical applications and optimization of flight analysis. MSc thesis, Instituto Superior Técnico,
2010.
[20] J. P. R. Freitas. Study and Implementation of Algorithms for in flight performance analysis of the
PW4000-100 Turbofan engine for the purpose of Engine Condition Monitoring. MSc thesis, Instituto
Superior Técnico, July 2014.
[21] ICAO. Safety Management Manual. International Civil Aviation Organization, 3rd edition, 2013.
[22] Sagem. Analysis Ground Station User Manual. Safran Group, 2nd edition, Dec 2008. V12.
[23] S. da Cruz Ribeiro. Implementation of an Engine Condition Monitoring tool for Airbus Aircraft. MSc
thesis, Instituto Superior Técnico, June 2015.
[24] M. Kantardzic. Data Mining: Concepts, Models, Methods, and Algorithms. Wiley-IEEE Press, 1st
edition, 2002.
[25] J. P. Jiawei Han, Micheline Kamber. Data mining: concepts and techniques. The Morgan Kaufmann
Series in Data Management Systems. Morgan Kaufmann, 2nd edition, 2006.
[26] C. Amado. Statistical methods in data mining. Instituto Superior Técnico, 2016/2017. Lecture
Notes.
[27] B. S. Everitt, S. Landau, M. Leese, and D. Stahl. Cluster Analysis. Wiley Series in Probability and
Statistics. Wiley, 5th edition, 2011.
[28] An Introduction to Cluster Analysis for Data Mining. University of Minnesota, October 2000. URL
http://www-users.cs.umn.edu/~han/dmclass/cluster_survey_10_02_00.pdf.
[29] E. Deza and M. M. Deza. Encyclopedia of distances. Springer Berlin Heidelberg, 2009.
[30] P. Cichosz. Data Mining Algorithms: Explained Using R. Wiley, 1st edition, 2015.
[31] P. Hansen and B. Jaumard. Cluster analysis and mathematical programming. Mathematical Pro-
gramming, pages 191–215, April 1997.
[32] A. K. Jain, M. Murty, and P. Flynn. Data clustering: A review. ACM Computing Surveys, pages
264–323, 1999.
82
[33] A. K. Jain and R. C. Dubes. Algorithms for Clustering Data. Prentice Hall, 1988.
[34] D. W. Rui Xu. Clustering. IEEE Press Series on Computational Intelligence. Wiley-IEEE Press,
illustrated edition, 2008.
[35] A. C. Rencher. Methods of multivariate analysis. Wiley series in probability and mathematical
statistics. J. Wiley, 2nd edition, 2002.
[36] J. H. Ward. Hierarchical Grouping to Optimize an Objective Function. Journal of the American
Statistical Association, 58(301):236–244, March 1963.
[37] P. Montero and J. Vilar. Tsclust: An R Package for Time Series Clustering. Journal of Statistical
Software, pages 4–8, November 2014. Volume 62, Issue 1.
83
84
Appendix A
Exported Parameters
Table A.1: Exported Parameters by AGS 1/3.

AC MP1 ON Hydraulic System 1 AC Pump Switch - On True/False
AC MP2 ON Hydraulic System 2 AC Pump Switch - On True/False
AC MP3A ON Hydraulic System 3 AC Pump A Switch - On True/False
AC MP3B ON Hydraulic System 3 AC Pump B Switch - On True/False
ADS SEL P Selected Air Data System Pilot 0/1/2/3
ADS SEL C Selected Air Data System Co-pilot 0/1/2/3
ALT STD Indicated Altitude Pilot feet
ALT STD COP Indicated Altitude Co-pilot feet
ANTI ICE VLVE1 Anti-Ice Valve 1 Position OPEN/CLOSED
ANTI ICE VLVE2 Anti-Ice Valve 2 Position OPEN/CLOSED
ANTI ICE WG OF Anti-Ice Panel Wing - Off True/False
APU BLD VLV APU Bleed Valve Position OPEN/CLOSED
APU EGT Auxiliary Power Unit EGT °C
APUGEN LOAD Auxiliary Power Unit Generator Load KVA
APUGEN VOLT Auxiliary Power Unit Generator Voltage V rms
APU START APU Start Bus SPDA ON/OFF
APU START CMD APU Start Pilot Command START/’NOT START’
AT EGD Auto Throttle Engaged ENGAGED/’NOT ENG’
BLEED1 VLV Engine 1 Bleed Valve Position OPEN/CLOSED
BLEED2 VLV Engine 2 Bleed Valve Position OPEN/CLOSED
CAB ALT Cabin Pressure (Altitude) feet
CAB DIF PRS Cabin Differential Pressure psi
E1 N1A VIB N1 Engine 1 Vibration A A/C Units
E1 N1B VIB N1 Engine 1 Vibration B A/C Units
85

EBAY FL CNT Center Electronics Bay Air Flow f t3 /min
EBAY FL FWD Forward Electronics Bay Air Flow f t3 /min
FF1 Fuel Flow Engine 1 kg/h
FF2 Fuel Flow Engine 2 kg/h
FLAP Flap Surface Position Angle °C
FLAP LEVER Flap/Slat Cockpit Lever FCM 0/1/2/3/4/5/FULL
FLIGHT PHASE Flight Phase See table 2.5
HYD PRESS 1A Hydraulic Pressure Low A System 1 NORMAL/’HIGH PRESS’
HYD PRESS 1B Hydraulic Pressure Low B System 1 NORMAL/’HIGH PRESS’
HYD SYS1 PRESS Hydraulic System 1 Pressure feet
HYD SYS1 QTY Hydraulic Fluid System 1 Quantity %
HYD SYS1 TEMP Hydraulic System 1 Temperature °C
HYDEDPDEP E1 Engine 1 Hydraulic Engine Driven Pump De-pressurization True/False
HYDEDPDEP E2 Engine 2 Hydraulic Engine Driven Pump De-pressurization True/False
IAS Indicated Airspeed Pilot knots
IAS COP Indicated Airspeed Co-pilot knots
IGNIT 1A Engine 1 Ignition - On Command Channel A True/False
IGNIT 1B Engine 1 Ignition - On Command Channel B True/False
IGNIT 2A Engine 2 Ignition - On Command Channel A True/False
IGNIT 2B Engine 2 Ignition - On Command Channel B True/False
ITT1 Inter-Turbine Temperature Engine 1 °C
ITT2 Inter-Turbine Temperature Engine 2 °C
LDGL Landing Gear Position AIR/GROUND
LDGNOS POS Nose Landing Gear Position 0/1/2/3
MANF STMP L Manifold Bleed Temperature Left °C
MANF STMP R Manifold Bleed Temperature Right °C
MANIFOLD1 P Manifold Bleed Pressure Left psia
MANIFOLD2 P Manifold Bleed Pressure Right psia
N11 Engine 1 Fan Rotor Speed %
N11 VIB Engine 1 Fan Vibration A/C Units
86

N12 Engine 2 Fan Rotor Speed %
N12 VIB Engine 1 Core Vibration A/C Units
N21 Engine 1 Core Rotor Speed %
N21 VIB Engine 2 Fan Vibration A/C Units
N22 Engine 2 Core Rotor Speed %
N22 VIB Engine 2 Core Vibration A/C Units
NLG POS 1 Nose Landing Gear Wheel Deflection Sensor 1 °
NLG POS 2 Nose Landing Gear Wheel Deflection Sensor 2 °
PACK FLOW 1 Air Flow in the Packs ppm
PACK FLOW 2 Air Flow in the Packs ppm
STEER HWC Nose Landing Gear Steering Hand-wheel Command °
TLA1 Thrust Level Angle 1 °
TLA2 Thrust Level Angle 2 °
VERT SPD Inertial Vertical Speed ft/min
WHEEL IBL Wheel Speed Inboard Left ft/s
WHEEL IBR Wheel Speed Inboard Right ft/s
WHEEL OBL Wheel Speed Outboard Left ft/s
WHEEL OBR Wheel Speed Outboard Right ft/s
WING A ICE P1 Wing Anti-Ice Pressure Left psia
WING A ICE P2 Wing Anti-Ice Pressure Right psia
XBLV CL DI 01 Cross-Bleed Valve Position OPEN/CLOSED
87
88
Appendix B
Aircraft System Description Section
The information presented in this appendix was obtained from the official Aircraft Maintenance Manual
- System Description Section documentation (AMM-3213, 5 August 2008, Revision 25 - 22 Septem-
ber 2017) [18]. The purpose of this section is to provide some insight and context over the systems
mentioned throughout this dissertation.
B.1 Integrated Pitot/Static/AOA Sensor
The integrated pitot/static/AOA sensors are symmetrically located on the nose of the aircraft. Sensors 1
and 2 are located farther forward and lower on the aircraft nose, in relation to sensors 3 and 4. Each of
the integrated pitot/static/AOA sensors include resistive heating elements that protect them against ice
formation, thus providing a safe operation of the sensor under icing environments (B.1).
Figure B.1: Integrated Pitot/Static/AOA Sensor.
89
B.2 Auxiliary Power Unit
Figure B.2: Auxiliary Power Unit - Location and Main Components.
B.3 Engine Pneumatic Bleed System
Figure B.3: Engine Pneumatic Bleed System - Control Schematic.
90
Figure B.4: Engine Pneumatic Bleed System - Main Components Location.
B.4 Avionics Compartment Ventilation
Figure B.5: Avionics Compartment Ventilation - Overview.
91
Figure B.6: Avionics Compartment Ventilation - Component Location.
B.5 Ignition System - Igniters
Figure B.7: Ignition System - Igniters.
92
B.6 Engine Vibration Monitoring System - Accelerometers
Figure B.8: Engine Vibration Monitoring System - Front Accelerometer.
Figure B.9: Engine Vibration Monitoring System - Rear Accelerometer.
93
B.7 Hydraulic System
Figure B.10: Hydraulic System - Control Surfaces.
Figure B.11: Hydraulic Pressure Indication System - Components.
94
Figure B.12: Hydraulic Fluid Quantity Indication System - Components.
B.8 Nose Landing Gear
Figure B.13: Nose Landing Gear and Doors - Main Components.
95
Figure B.14: Steering System - Components.
B.9 Total Air Temperature Sensor
Figure B.15: Total Air Temperature Sensor.
96

Thesis 73733 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Thesis 73733 PDF

Caricato da

Copyright:

Formati disponibili

Development of an Aircraft Health Monitoring Program for

Nuno Alberto Fonte Silva e Lima

Thesis to obtain the Master of Science Degree in

Supervisors: Prof. Pedro da Graça Tavares Álvares Serrão

O crescimento acelerado da indústria da aviação gerou um mercado altamente competitivo, onde

Palavras-chave: Dados de voo, Análise de Tendências, Monitorização da Saúde da Aeron-

3 Aircraft Health Monitoring Program 27

4 Results and Case Studies 65

B Aircraft System Description Section 89

2.1 Embraer E190-100 General Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 File name specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.1 World Annual Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 ARINC 717 Frame Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Data Migration - Part I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Altitude Split Monitoring - Aircraft Lambda. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

B.1 Integrated Pitot/Static/AOA Sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A/C Aircraft. 12, 13, 44

ACARS Aircraft Communications Addressing and Reporting System. 4, 57

ACF Autocorrelation Function. 58

ACMS Aircraft Condition Monitoring System. 5

ADS Air Data System. 33

AFDAU Auxiliary Flight Data Acquisition Unit. 11

AGS Analysis Ground Station. xv, 12–17, 27, 29, 30

AHM Aircraft Health Monitoring. 3–5, 30

AIRMAN AIRcraft Maintenance ANalysis. 4

AMS Air Management System. 38

AOA Angle Of Attack. 33, 48, 66

AOG Aircraft On Ground. 2, 65

AOM Aircraft Operations Manual. 33

ARINC Aeronautical Radio Incorporated. 8–13, 27, 43

ASCII American Standard Code for Information Interchange. 16

BCD Binary Coded Decimal. 9, 10

CAS Crew-Alerting System. 57

CMC Central Maintenance Computer. 4, 57, 67

CSV Comma Separated Values. xiii, 16, 17, 27, 29

CVR Cockpit Voice Recorder. 10

DMU Data Management Unit. 11

DVDR Digital Voice and Data Recorder. 10

EICAS Engine-Indicating and Crew-Alerting System. 4, 43, 44

ERJ Embraer Regional Jet. 5

FADEC Full-Authority Digital Electronic Control. 32, 34, 41–43

FDR Flight Data Recorder. 10, 12

FF Fuel Flow. 30, 41

FHDB Fault History DataBase. 30

FOQA Flight Operational Quality Assurance. 12, 13

GSE Ground Support Equipment. 11, 12

GUI Graphical User Interface. 50, 52, 54

HIL Hold Item List. 69, 73

HPSOV High-Stage Shut Off Valve. 38

IEVM Integrated Engine Vibration Monitor. 43

ITT Inter-Turbine Temperature. 30, 42

LPSOV Low-Pressure Shut Off Valve. 38

MAU Modular Avionics Unit. 43, 46

MEL Minimum Equipment List. 69

MFD Multi-Function Display. 46, 49

MOQA Maintenance Operational Quality Assurance. 12, 13

MRO Maintenance, Repair and Overhaul. 3–5

N1 Fan Rotor Speed. 12, 44

N2 Core Rotor Speed. 12, 30, 31, 41, 42

NAPRSOV Nacelle Pressure-Regulating Shut-Off Valve. 38, 70, 73, 74

OEM Original Equipment Manufacturers. 3, 4

PCMCIA Personal Computer Memory Card International Association. 11, 14, 27

PFD Primary Flight Display. 33