1 Introduction
Aircraft structural health monitoring has gained significance for military and civil aircraft development and operation over the last decades. The monitoring addresses fatigue loads during normal aircraft operation as well as rare high-load events on ground and in flight. Significant in-flight events requiring further attention are, e.g., severe turbulence encounter, extreme manoeuvres, exceedance of speed limitations, and heavy stall buffet [6]. The consequences of such events are unscheduled extensive inspections and potentially also maintenance actions following the aircraft maintenance manual. As a result the aircraft is kept on ground for a longer period of time, which may cause a disruption in the flight schedule and reduced profitability of the aircraft operation. Hence, loads monitoring aims at reducing the number of unnecessary inspections while increasing the safety of aircraft operation by timely and detailed event assessment.
The first two steps in the event assessment prior to inspections are the robust but often imprecise identification of a relevant high loads event and the evaluation of its severity. Traditionally, the pilot – subjectively – performs the initial assessment. As an improvement, it is recommended to derive objective criteria using flight data to assist in the evaluation of events [4]. A possible solution is the development of a structural loads monitoring algorithm which addresses the combination of manoeuvre and gust events as outlined in the next section and presented in detail in [2]. The key feature of this algorithm is the estimation and the assessment of experienced loads magnitude at aircraft component level. This enables the introduction of targeted inspections, focusing the relevant aircraft components potentially affected by the event.
Primary objective in the design of the algorithm is the safety of the aircraft. Hence, the assessment of the estimated loads needs to be conservative to guarantee the detection of all loads-relevant events and to avoid any missed alerts (Figure 1).
Figure 1: Alert categories
On the other hand, the number of false alerts (unnecessary inspections) is to be minimized to reduce associated costs. Both objectives are addressed within the assessment of the estimated loads. It is performed by comparing the estimated loads to thresholds linked to the structural capability of the different aircraft components. The thresholds are determined under consideration of so-called uncertainties that represent differences between estimated and true loads so that the first objective is accounted for. The second objective (minimum number of false alerts) is addressed by minimizing these uncertainties. Consequently, the accuracy of the loads estimation for the different aircraft components and loads quantities has to be determined with respect to reference loads for the entire operational range of the aircraft. Therefore, hundreds of reference data sets need to be considered. These are extracted from flight test data as well as from design loads simulations with sophisticated tools. As each reference set contains several dozen loads quantities, the resulting amount of data to be assessed requires an automated processing with dedicated software tools for the evaluation. This process and the related tools are presented in the core part of the paper.
2 Structural Loads Monitoring Algorithm
The structural loads monitoring algorithm is implemented on the aircraft and is executed during aircraft operation. The entire algorithm is separated into three modules: The ‘Trigger’ module, which is computed in real time, and the subsequent modules ‘Loads Estimation’ and ‘Loads Assessment’ (Figure 2).
Figure 2: Loads monitoring algorithm modules
The ‘Loads Estimation’ module is the most time consuming and with respect to computational resources most demanding. A lean algorithm inside the ‘Trigger’ module monitors selected signals to find indications for a high loads occurrence. This safes computational resources on the aircraft since subsequent modules are not executed continuously. Only in case of an occurrence of a defined condition (event) a set of measurement signals is recorded for a given time range. This signal set – called time slice – covers a time frame of several seconds before and after the trigger event to account for dynamic effects. It is stored in a buffer that is processed by the ‘Loads Estimation’ module subsequently.
The ‘Loads Estimation’ module uses the recorded input signals to estimate structural loads, i.e. forces and moments in the airframe. These result from aerodynamics, thrust, drag and inertia. They are excited by piloted aircraft motion or by external disturbances, i.e. gust and turbulence. With an appropriate model the loads resulting from manoeuvres can be computed with sufficient accuracy, since the aircraft motion and control surface deflections are available as measured signals. The estimation of gust loads or combined manoeuvre and gust loads is more challenging, since the external excitation by gusts is unknown. Therefore, an observer-based concept was implemented to estimate gusts acting on the aircraft. It consists of an aircraft model, which is computed in parallel to the real aircraft and is augmented by disturbance models to reconstruct the gusts (Figure 3).
Figure 3: Observer structure
This parallel model comprises non-linear equations of motion for a rigid body with all six degrees of freedom and a set of linear differential equations for the elastic motion of the aircraft structure. Aerodynamic loads acting on the aircraft structure are computed on the basis of a steady-state vortex lattice model (VLM). The entire aircraft model is implemented in MATLAB/Simulink. Due to the implementation in the time domain, both, dynamic behaviour and non-linear effects can be considered. A detailed description of this aircraft model can be found in [1].
The model receives the same control inputs (control surface deflections and thrust) as the real aircraft and provides estimated loads and motions. Differences in measured and estimated motions – so-called residuals – are fed back via gains to track the flight path of the real aircraft and to reconstruct gusts. Hence, this concept allows estimation of combined manoeuvre and gust loads at almost every point of the airframe by using only standard measurements available on every modern transport aircraft.
The feedback gains are determined in the development process by means of an optimization algorithm to achieve optimal loads estimation and insensitivity against parameter variations. This optimization minimizes a quadratic cost function representing the auto-covariance of the estimation error. The observer based approach and the optimization process are described in detail in [2].
The ‘Loads Assessment’ module compares the estimated loads against thresholds under consideration of the uncertainties as described in section 1 to detect loads exceedances. Afterwards, the module compiles a report containing meta data like aircraft type, flight number and trigger cause(s), and – in the core part – loads exceedance data. Latter ones consist of the threshold exceedance for each loads quantity and the link to the related chapter of the aircraft maintenance manual.
3 Validation Environment
The estimation accuracy of the algorithm in general and the load uncertainties required for the parameterization of the ‘Loads Assessment’ module are determined by comparing the estimated loads to reference loads. To achieve reliable results, the validation is based on an extensive amount of reference data. It comprises results from manoeuvre and gust design loads simulations and measured data from flight test.
The load quantities to be monitored and estimated during aircraft operation are specified for particular spots of the airframe called analysis points (APs). Each AP comprises up to six single load quantities (three forces and three moments) and additionally some combinations of these, e.g. shear force and torsion. Taking into account that for each reference data set with several APs many dozens of load quantities need to be assessed – while having an extensive range of reference data sets – the need of automated data processing is obvious.
3.1 Automated data processing
The main steps of the MESA-based validation process from preparation of reference data, covering estimated loads computation, through to quality assessment, are depicted in Figure 4.
Figure 2: Main steps of validation process
With the ‘Import Data’ module the reference data sets are catalogued in a relational database. Additionally some meta information like origin of the data (aircraft type, flight number or simulation tool), time range or certain signal properties are stored.
Reference data coming from design simulations contain more or less high loads, since the airframe is dimensioned by means of these data. In contrast to this, the vast majority of flight test data, e.g. recorded during aircraft handling tests, are not of interest from a loads point of view. Therefore, an ‘Event Detection’ module was implemented. It searches the flight test data for sections with high loads and adds this event information to the database. This module is similar to the ‘Trigger’ module of the loads algorithm but is more advanced. Apart from aircraft motion and other signals the reference loads itself can be taken into account. This allows finer selection of relevant time slices and thus reduces computational effort during validation.
For each or a selected subset of these events (e.g. for a specific manoeuvre type) a time slice with the input signals for the loads monitoring algorithm is extracted along with a second time slice containing the reference loads. The algorithm is started with this input data, as it would be in service. The estimated output data is added to the database and – together with the reference data – transferred to the module ‘Quality Assessment’. This module computes the accuracy of the loads estimation automatically and adds the results to the database.
To invoke this automated processing, the user specifies an experiment file. Here is defined what data and how it should be processed. This definition is pre-processed and transferred into a detailed task list including the desired
...