KTH Safran Electronics & Defense
School of Engineering Sciences Data Management Solution
Master in Aerospace Engineering Massy - FRANCE
Supervisor: Ulf Ringertz Tutor: Victor Lefebvre
M ASTER T HESIS
Developing algorithms for Flight Data Monitoring
Utveckling av algoritmer för övervakning av flygdata
Clémence Rossignol
This document and the information contained herein are the property of Safran.
They must not be copied or disclosed to third parties without prior Safran written authorization.
Abstract
Flight data are recorded on every commercial aircraft to be analysed and therefore improve flight safety. This analysis is done through various algorithms computing new parameters and detecting precise instants of the flight (rotation, take-off, touchdown, etc.). These instants are used to flag events when a safety risk occurred during the flight. High-accuracy in the detection of instants is of prime importance to avoid missed events and flagged false events.
This document and the information contained herein are the property of Safran.
They must not be copied or disclosed to third parties without prior Safran written authorization.
Sammanfattning
Flygdata registreras på alla kommersiella flygplan för att analyseras och därmed förbättra flygsäkerheten. Denna analys görs genom olika algoritmer som beräknar nya parametrar och upptäcker exakta tillfällen av flygningen (rotation, start, landning, etc.). Dessa tillfällen används för att flagga händelser då en säkerhetsrisk uppstått under flygningen. Hög noggrannhet i upptäckten av dessa tillfällen är av största betydelse för att undvika missade händelser och flaggade falska händelser.
Contents
1 Introduction 2
1.1 Safran Electronics & Defense . . . 2
1.2 Flight Data Monitoring . . . 2
1.2.1 Cassiopée AGS software . . . 3
1.2.2 Cassiopée FDM services . . . 4
1.3 Scope of the internship . . . 4
2 Algorithms development 5 2.1 Relevance of the instants . . . 5
2.2 Existing solutions . . . 5
2.3 New algorithmic logic . . . 6
3 Algorithms validation 9 3.1 Development of the validation tool . . . 9
3.2 Tests of the new algorithms . . . 10
4 Conclusion 11
1 Introduction
1.1 Safran Electronics & Defense
This Master Thesis work has been done in partnership with the company Safran Electronics &
Defense in which the author spent 6 months as an intern. It is part of Safran Group, which is a world leader in the aerospace industry, gathering more than 10 companies. Safran is a French-registered company with presence in 30 countries over Europe, America, Africa and Asia. Its core businesses are mainly Aerospace propulsion and Aircraft equipment but also Defense, Aerosystems and Aircraft interiors, as shown in Figure 1.
Figure 1: Revenue by business sector in 2018. (source: Safran)
Safran Electronics & Defense is the Group’s electronics specialist. In 2005 Safran Group was formed from the merging of SAGEM with the company SNECMA. The electronic knowledge and facilities inherited from SAGEM have been grouped again together in 2009, within the Safran Electronics division. It finally took the name of Safran Electronics & Defense in 2016. The company has today two divisions: Avionics on one side and Defense on the other, with several facilities in France and subsidiaries worldwide.
The author worked in the Avionics Division from August 2019 to January 2020. This division develops high precision avionics, inertial, electronics and optics solutions for aeronautics, space and astronomy. Many of the systems developed by the company are dedicated to civil aircraft, such as the A380. The author was part of the Data Management Business Unit who is responsible for Safran Electronics & Defense’s flight data management service.
1.2 Flight Data Monitoring
Commercial aircraft are equipped with flight-data acquisition units, receiving various parameters from sensors and avionic systems. This data is then recorded in a Flight Data Recorder (FDR) and a Quick Access Recorder (QAR) or a Digital ACMS Recorder (DAR). Every airline operating a commercial aircraft1 above a certain weight is responsible for routinely capturing and analysing this data in order to improve flight operations safety. This process is called Operational Flight Data Monitoring (OFDM). Safran Electronics & Defense provides different solutions to aircraft operators, enabling them to take profit on their flight data. These solutions are grouped under the name Cassiopée. Two of them will be described here as they are linked to the internship missions.
1Flight Data Monitoring is mandatory on airlines operated under European EASA jurisdiction for aircraft whose mass is greater than 20 tons.
1.2.1 Cassiopée AGS software
Flight data are received in a binary format. The Cassiopée Analysis Ground Station (AGS) software uses a dataframe file to make these binary recordings match with flight parameters and convert them into engineering values. The software then analyses flight data and extracts valuable information from it. It relies on numerous algorithms that read recorded parameters, compute additional useful parameters, monitor the occurrence of defined events and perform measurements at precise moments in each flight.
Events monitored are of different types:
• safety events (such as the measurement of a low pitch at lift-off for example),
• operational events (such as the detection of a go around),
• maintenance events (such as the measurement of a too high brake temperature).
Each event detection relies on one or several predefined limits. If one of this limit is exceeded during a flight, the event is triggered with a corresponding severity class (ranking from 1 to 3, the latter representing the highest risk).
The results are displayed in the AGS software with different means. For each flight analysed, all the parameters (recorded and computed) can be plotted or shown in tables. The measurements can also be displayed. A list of the events triggered during the flight is provided with associated information.
Additionally, a 3D animation of the flight, a GPS display and a view of the cockpit instruments are also available, as in Figure 2.
Figure 2: Example of flight analysis results displayed in AGS. (source: Safran)
The recorded parameters being different from a recorder type and an aircraft type to another, the dataframe and the algorithms treating them will also be different. Moreover from an airline to another, the events monitored will be different and their associated limits as well. This results in the necessity of having a specific set of algorithms and a dataframe for every single aircraft. This set of algorithms together with the dataframe is called in the AGS an Analysis Configuration (or anaconf ).
To enable efficient deployment of algorithms modifications or new algorithms, Cassiopée service uses a tool named Cobalt. It consists of generic algorithms that can adapt to any anaconf using information stored in configuration files.
In order to analyse their flight data, airlines have the possibility to buy the AGS software and customize it as they wish with new algorithms. They will receive training and support from the Cassiopée AGS team. This requires for the airline to have in-house analysts dedicated to flight data analysis. For those who would not have this resource, Cassiopée FDM services can be provided.
1.2.2 Cassiopée FDM services
Cassiopée FDM offers global flight data analysis services for airlines. This includes flight data analysis by the AGS software and extra-analysis of flights and triggered events by Safran flight safety engineers. Resulting reports, statistics and trends are available within a few hours through a simple and secure website. Safran engineers thus help airlines safety managers in analysing their data and adapting their FDM policy to the airline daily operations.
Airlines using these services also have access to new algorithms developed, all modifications brought to existing algorithms and can ask for customized algorithms. Additional analysis is sometimes needed and asked by the airline when a major specific safety event occurred for example.
Then Safran engineers investigate on the problem and deliver a dedicated report to the airline.
In addition to these services, pilots can also use Cassiopée FDM website to report any issue that could have occurred during a flight to their safety department or flight safety authorities. They have access to personalised statistics regarding their flights and safety managers can contact them to ask for further details. It is a important tool to increase flight safety in a non punitive manner.
1.3 Scope of the internship
During the six months she spent in the Data Management Business Unit, the author worked with the Cassiopée team on developing and enhancing algorithms for events detection. After a few weeks spent on fixing some minor bugs within the existing algorithms in order to get familiar with the product and the programming language, she started to work on long-term improvements. The topic developed in this Master Thesis report is the following: Development of new means of detection for rotation and touchdown instants from algorithmic logic, through solution validation and up to deployment in production.
This project went through the following steps, then developed in details in further sections:
• investigating on existing solutions and defining an algorithmic logic,
• developing the generic algorithms with Cobalt,
• creating a new tool to test these algorithms
• fixing algorithms according to tests results,
• validating algorithms and deploying them to customers.
2 Algorithms development
2.1 Relevance of the instants
Algorithms have already been developed in the past by Cassiopée team to detect rotation and touchdown instants. These instants are used in other algorithms to perform measurements or trigger safety events, therefore their accuracy is critical.
For example, the rotation instant is an input in the Long time lift-off event detection algorithm. This event is triggered when the duration between the start of the rotation (back pitch stick input by the pilot) of the aircraft and the actual lift-off (no contact with ground anymore) is too long. The occurrence of such event is classified as a risk of runway excursion by the EOFDM2 and is consequently a key safety issue. A poor accuracy in the detection of the rotation instant might lead to false positive triggered events, which means extra workload for analysts, or undetected events, which means safety risks not visible and therefore not taken into account by airlines.
At touchdown instant, many measurements are performed such as the pitch of the aircraft, the flaps position, the normal acceleration or the fuel mass. These values are then used to detect events such asLow pitch at touchdown orHigh normal acceleration at touchdown for example, but also to provide aircraft operators with general trends on the way landings are performed. If the touchdown instant is detected with a delay, the associated measurements are not as accurate as they should be.
2.2 Existing solutions
Rotation instant During take-off phase, rotation starts when the pilot applies a back yoke or side-stick input in order to increase the aircraft pitch and eventually leave the ground. This instant is the rotation instant in question. In the existing algorithm, it is detected using two different parameters: the angle of backward input on the yoke or side-stick, depending on the aircraft type (PITCH PILOT parameter) and the PITCH parameter. In the nominal mode, the PITCH PILOT is used (being the command applied either by the Captain or the Flight Officer, depending on who performs the take-off). When it reaches 1◦ in the backward direction, the instant is considered as the rotation instant. If the PITCHPILOT parameter is not recorded for a specific anaconf, thePITCH parameter is used (degraded mode): the rotation instant is then defined as the instant when the pitch reaches 1◦. This method of detection can lead to different problems: a delay is induced when waiting for a 1◦ pull (late detection) and if the pilot pulls the yoke or side-stick by mistake or for command testing before the actual rotation, it can be considered as the rotation instant (false detection).
Touchdown instant A common recorded parameter is the boolean AIR/GROUND STATUS of each landing gear wheel. From these parameters, a global AIR/GROUND STATUS is computed indicating whether the aircraft touches the ground or not at each instant. In the existing algorithm, the touchdown instant is defined as the moment at which this computed parameter switches fromAIRto GROUND. This method of detection might lead to inaccuracy as theAIR/GROUND STATUSparameter often indicates GROUND only when the associated part of the landing gear is fully compressed. Thus there is a delay between the actual touchdown and the detected one.
2The European Operators Flight Data Monitoring (EOFDM) forum is a voluntary partnership between European Operators and the EASA. Three working groups give recommendations to help operators with their FDM Programmes.
2.3 New algorithmic logic
Rotation instant A new logic was developed for the rotation detection using the same recorded parameters as before (PITCH PILOT and PITCH). To avoid delay or false detection, rotation start should be defined as the very beginning of the last significant backward yoke or side-stick input before lift-off. The rotation detection is now done with the following method: (1) the instant when a backward input is detected is stored, (2) if the yoke or side-stick is pushed back or is not moved for a few seconds, this instant is reset and the algorithm waits for a new backward input (3) when the PITCHreaches a significant value, the stored instant is confirmed to be the rotation instant.
This method has the advantages to avoid detecting false instant in case of backward input during the taxi out phase for example, but also to provide high-precision detection by taking into account small inputs. The accuracy gain is visible in Figure 3 where the red arrow corresponds to the former rotation instant and the green arrow to the new one. In this particular case, there used to be a false detection:
the rotation was detected too early because of a non significant yoke or side-stick movement. The new method figures out that the command remains stable after this movement and takes the next significant movement as the rotation. There is a 17 seconds time difference between former and new instants.
PITCH PILOT (deg)
Figure 3: New and former rotation instants using thePITCHPILOTparameter.
ThePITCH PILOTparameter can happen not to be recorded for some aircraft. In this case and as the rotation instant is still needed in flight data analysis, a degraded mode using thePITCH parameter is employed. This mode will provide less accuracy than the nominal one but false detection still has to be avoided. The rotation detection is then done with the following method: (1) the instant when a PITCH increase is detected is stored, (2) if the PITCH decreases or stays stable for a few seconds, this instant is reset and the algorithm waits for a new increase inPITCH(3) when thePITCHreaches a significant value, the stored instant is confirmed to be the rotation instant. As shown in Figure 4, this method uses the first significant PITCHincrease as the rotation instant. The red arrow corresponds to the former instant detected (late detection because the algorithm waits for a 1◦value ofPITCH) while the green one is the result of the new method. Here there is a 2 seconds time difference between them, which is already significant.
PITCH (deg)
Figure 4: New and former rotation instants using thePITCHparameter.
Touchdown instant As explained above, taking into account the AIR/GROUND STATUS parameter alone is not sufficient. Therefore different parameters have been investigated: the LONGITUDINAL
ACCELERATION, the PITCH and the NORMAL ACCELERATION. It appeared that LONGITUDINAL
ACCELERATION and PITCH do not follow a pattern typical enough around touchdown to be used for its detection. However and as shown in Figure 5, there are several peaks of NORMALACCELERATION
around and prior to the moment theAIR/GROUND STATUSswitches toGROUND. The first peak is due to ground reaction force when touching the ground for the first time while the following ones might be due to bounces or variation in the force of contact with ground. In order to find the instant when the aircraft touches the ground for the first time with a high accuracy, the JERK is considered and plotted in the same Figure. TheJERKis the first time derivative of theNORMALACCELERATION. The touchdown instant (ie first ground contact) then corresponds to the first peak of jerk. It can also be seen in Figure 5 that in this particular case, the AIR/GROUND STATUS switches to GROUND with a delay of 1.5 seconds compared to this instant.
STATE 0 STATE 1 STATE 3
STATE 2
Figure 5: NORMALACCELERATIONandJERKparameters around touchdown instant.
In order to identify the first jerk peak, the detection algorithm uses the state machine presented in Figure 6. Throughout flight time, the algorithm enters one or another state and pursue some corresponding actions. Transitions between states are ruled by conditions, represented with arrows in Figure 6. Figure 5 also shows in which state the aircraft is at each instant. The state machine in question works as follows:
• action: By default, the aircraft is in state 0 when the flight starts and waits for monitoring to start.
• transition: When aircraft descends below 50 feet, aircraft enters state 1.
• action: While in state 1, to identify jerk peak, the algorithm searches for the maximum value of jerk above a preset threshold and stores the corresponding instant.
• transition: For the jerk peak to be considered found, 2 or more of these 3 criteria have to be fulfilled: a negative jerk value has been recorded, a negative longitudinal acceleration has been recorded or pitch has started to decrease. If it is the case, aircraft enters state 2. Otherwise and ifAIR/GROUND STATUShas switched toGROUND, aircraft enters directly state 3. If no jerk peak has been identified after 15 seconds, the aircraft goes back to state 0.
• action: While in state 2, the algorithm waits for monitoring to end.
• transition: If AIR/GROUND STATUS switches toGROUND, aircraft enters state 3. If not after 3 seconds, it goes back to state 0.
STATE
3
Waiting for monitoring to start
Looking for jerk peak
Waiting for monitoring to end STATE
0
STATE
1
STATE
2
height < 50 feet jerk peak found GROUND status GROUND status
time in state 1 > 15s
time in state 2 > 3s
Figure 6: State machine used in touchdown instant detection.
This method improves the accuracy of the touchdown instant and fixes the delay induced by the use of theAIR/GROUND STATUS. However, such a pattern of theJERKparameter cannot always be identified.
If no peak of jerk is found, the touchdown instant is chosen as it was previously: the instant when AIR/GROUND STATUSswitches toGROUND.
3 Algorithms validation
3.1 Development of the validation tool
The new algorithms presented in the above section have large consequences on flight data analyses as they modify the computation of key instants. Special interest should then be put on their validation before they can be deployed in production. Cassiopée team uses Gitlab tool to manage its Cobalt source code and keep track of changes. This web-based DevOps solution also includes CI/CD pipelines (Continuous Integration/Continuous Delivery). CI pipelines are today used to validate changes in algorithms by testing the creation of an AGS procedure from a Cobalt generic algorithm (this process is called "dumping an anaconf ". This test has appeared to be too limited to check all the consequences some modifications can bring. Therefore a new set of tests is needed to validate the new rotation and touchdown instants algorithms. These CI tests should also be used in the validation of any other algorithm modification. The pipeline of CI tests developed for this Master Thesis work is shown in Figure 7. Each step is called a job and is described below.
Figure 7: CI pipeline for algorithms validation.
A representative dataset of aircraft has been built upstream. It includes a wide variety of aircraft types, airlines, constructors and engine types. The algorithms modifications have been done in a branchwhich is a parallel version of the Cobalt source code. The tests occur when modifications on this branch have all been done and it has to be merged again into the master branch to be deployed to airlines.
Prod dump dataset [1] This job is very similar to what existed before in the CI tests. The branch containing the modifications is dumped for each anaconf in the dataset. If there is no error when dumping, the job status is "pass", otherwise it is "failed".
Anaconf comparison [2] For the anaconf present in the dataset, all the generated parameter computation procedures, event procedures and their associated limits are compared to the procedures generated before the modifications were made. If there is no change, the job status is "pass", otherwise there is a "warning" status, the changes are displayed and the developer in charge of validating the merge of the branch has to verify if they are desired changes.
Anaconf valid check [3] This job first checks with the AGS software if all anaconf are valid (ie there is no syntax error, no missing parameter etc.), its status is "pass" if they are all valid or "failed" if not. Flights are then analysed in the AGS software. The analyses outputs are saved for the following job.
Flight comparison [4] The characteristics of each flight analysed as well as the events triggered during these flights are compared to the flight characteristics and events triggered before the modifications were made. If there is no change, the job status is "pass", otherwise there is a
"warning" status, the changes are displayed and the developer in charge of validating the merge of the branch has to verify if they are desired changes.
New reference [5] Once all jobs are "passed" or if "warning" statuses have been checked by the developer and considered desirable changes, this last job can be run manually. It merges the branch into the master branch and updates the reference for future comparison jobs.
Each of these jobs is executed thanks to a PowerShell script. They are grouped into a single Gitlab CI file that defines their order and properties. This enables them to be run automatically every time a merge request is open (ie after a modification done on a branch). A runner on a dedicated virtual machine is used to run this pipeline. As running the whole pipeline takes a significant amount of time, it is by default run once per day, but can also be run manually if needed.
3.2 Tests of the new algorithms
The CI pipeline developed is used to validate the modifications made in the rotation and touchdown instants detection. To consider them as valid, the jobs Prod dump dataset [1] and Anaconf valid check [3] should have a "pass" status. Moreover, the jobs Anaconf comparison [2] and Flight comparison [4] should have a "pass" status or a "warning" status with acceptable associated changes.
Rotation instant A "pass" status was obtained for jobs [1] and [3]. The other jobs resulted in a
"warning" status. The changes displayed and their validity are the following:
• New procedure found (Rotation start detection): this change is accepted as this procedure has been created to detect the rotation instant with the new method
• Events Duration between rotation and lift off too long and Rotation at too high speed are not triggered anymore for some flights: these occurrences were due to a bad detection of the rotation instant, either too early or too late, the changes are thus accepted
Non expected changes were analysed and resulted in the identification of particular cases not taken into account in the algorithm. An iterative process was followed to correct theses cases and run the CI pipeline again. Once all changes displayed were acceptable, the branch was merged into the master branchand the reference updated thanks to the last job New reference [5].
Touchdown instant A "pass" status was obtained for jobs [1] and [3]. The other jobs resulted in a
"warning" status. The changes displayed and their validity are the following:
• New procedure found (Jerk computation): this change is accepted as this procedure has been created to compute theJERKparameter from theVERTICAL ACCELERATION
• The event Low pitch at touchdown is not triggered anymore for some flights: these occurrences were due to a late detection of the touchdown instant, resulting in a measure of the PITCH
parameter lower than the actual, the changes are thus accepted
• The event High pitch at touchdown is now triggered for some flights for which it was not before:
this is due to the better accuracy of the touchdown instant detection, the PITCH parameter is measured too high at this instant, the changes are thus accepted
Non expected changes were analysed and resulted in the identification of particular cases not taken into account in the algorithm. An iterative process was followed to correct theses cases and run the CI pipeline again. Once all changes displayed were acceptable, the branch was merged into the master branchand the reference updated thanks to the last job New reference [5].
4 Conclusion
This Master Thesis work was done within the Cassiopée team of Safran Electronics & Defense, as a six months internship. The need for a better detection of some key instants had arisen in the team.
The internship thus focused on the following topic: Development of new means of detection for rotation and touchdown instants from algorithmic logic, through solution validation and up to deployment in production.
The same workflow was followed for both instants improvement. The first step consisted in studying the existing algorithms and identifying the problems that can occur with the algorithmic logic adopted. A new logic had then to be found to overcome these problems. New algorithms were developed with this logic. As effects of these changes were expected to be wide, a coherent validation tool was also needed. This was done as CI tests pipeline using Gitlab. The development of these tests had to fulfill several requirements: providing a clear view of the changes induced by the algorithms modifications in question but also be operational for validating any other future algorithm change. Once developed, these CI tests were used to validate the new instants algorithms. An iterative process was followed to fix undesirable changes induced by the new algorithms. In the end, the CI tests showed that the new source code answered to the initial requirements (ie improving the instants detection accuracy while having no effect on non-related parameters and procedures).
Being validated, the changes were included in the source code and are now available to Safran Electronics & Defense customers. The main effects of the algorithms improvements are: (1) a decrease in the number of false positive events detection, which results in a decrease of the workload for Cassiopée analysts who had to manually invalidate these events in the past, but also for customers analysts (2) a higher accuracy in the instants detection, which enables high-precision measurements at these instants and therefore avoids both false positive events and missed events, improving flight safety.
References
[1] Airbus, “Getting to grips with aircraft performance,” Flight Operations Support & Line Assistance, 2002.
[2] FAA, “Advisory circular: Flight operational quality assurance,” U.S. Department of Transportation, 2004.
[3] “Safran group,” www.safran-group.com, accessed: 2019-10-24.
[4] “Skybrary,” www.skybrary.aero, accessed: 2019-10-28.
[5] “Cassiopée services,” www.cassiopee.aero, accessed: 2019-10-28.
[6] “EOFDM,” www.easa.europa.eu, accessed: 2019-11-19.
