A320 Family Aircraft configuration

Field Loadable Software (FLS) associated with Data Loadable Units (DLU), were originally introduced to facilitate the evolution of standards and the management of spares. To do so, these computers provide an upgraded hardware that can accommodate different versions of operational software, i.e. different standards. Updating the standard of a FLS can thus be done without removing the hardware itself from aircraft. Indeed, it simply consists in uploading the new version of the operational software from a media disk to the same hardware, either directly on-board or using a portable data loader.

Field Loadable Software started to be introduced progressively on the A320 Family around six years ago.

In practice, on the existing fleet, some aircraft have it (either from delivery or via Service Bulletin), others don’t.

However, even the non-equipped aircraft can accommodate a DLU hardware without using the aircraft data loading function. In that case, the hardware needs to be fitted upstream in a repair shop, with the adequate operational software version. The DLU loaded with the relevant Field Loadable Software standard then behaves as a non-loadable computer.

If a DLU loaded with the appropriate standard behaves exactly as a non-loadable computer, whether it is installed on an aircraft with the data loading function or not, the use of this new DLU introduces a major change in terms of spares and aircraft configuration management: the emergence of a new, intangible and not immediately visible dimension.

Indeed, with the disconnection between hardware and operational software introduced by Data Loadable Units, the aircraft configuration consists of physical parts PN as well as operational software PN.

In practice, it means that a quick glance at the hardware installed is not sufficient to identify the FLS standard, and in turn, the actual aircraft configuration.

No one would install an incorrect hardware PN on the aircraft as the aircraft would then be in a non-certified condition, with all the potential safety consequences it could have. Flying with incorrect operational software comes to the same thing!

Indeed, uploading an operational software into a hardware which is not supposed to receive it, leads to a non-certified aircraft configuration. This implies that the consequences of operating such configurations, whe-ther immediate or not, could not be studied and tested because exploring them falls de facto outside of the design studies. However, they do exist and can take on a potential significant safety dimension.

The cases that were observed in service are good examples to reveal that consequences are varied and may actually impair safety in very different ways.

Sharklet aircraft include a new Load Alleviation Function (LAF) that allows to limit wing loads. This function is key to ensure that wing loads remain within certification requirements. Fitting a Sharklet aircraft with a pre-Sharklet ELAC (ELevator and Aileron Computer) and/or SEC (Spoiler & Elevator Computer) standard leads to losing this LAF function, thus exposing the wing to non-anticipated and studied loads. If the consequences cannot be detected immediately, such non-certified configuration leads to structural loads and ultimately structural fatigue that have not been studied as such, but could ultimately result in safety concerns.

In order to reduce the likelihood of tail strikes or hard landings, new ELAC standards were developed with an improved transition flare law to ground law. Flying with an aircraft supposed to be fitted with these new computers and actually fitted with an ELAC standard prior to these improvements leads to a situation where pilots believe they benefit from these improvements whereas they actually don’t. It is like driving a car believing it is equipped with ABS system whereas it does not have the function.

Similarly, ROPS (Runway Overrun Protection System) is only available with the latest loadable FAC (Flight Augmentation Computer) standard. Installing an older software on a ROPS-capable aircraft would lead to loose this safety enhancement function and the crew would not be aware of it.

On Sharklet aircraft, in case Sharklet capable and non-Sharklet capable FLS are mistakenly mixed (knowing that this is a non-allowed and non-certified configuration), the behaviour and control of the aircraft might be impaired. Depending on the type of DLU concerned, possible consequences are:

• Mix of Sharklet capable and non-Sharklet capable ELAC/SEC

Spoiler, Aileron and/or Elevator Surface actuator orders and monitoring provided by each ELAC/SEC might be different from one actuator to the other (as controlled by different units).
This may result in:

– Force fighting in case of elevator double pressurisation (might lead to structural defect and/or Aircraft unexpected behaviour)

– Left and right Aileron surfaces synchronisation not properly applied as expected (might lead to Aircraft unexpected behaviour).

• Mix of Sharklet capable and non-Sharklet capable FAC

Installing a non-Sharklet capable FAC on a Sharklet aircraft may lead to erroneous characteristic speeds computation, which, in turn, may affect safety margins against the stall speed.

These cases are not an exhaustive list of the safety related consequences that may result from an erroneous combination of a DLU hardware loaded with the undesirable operational software standard. Some of the effects described are potential effects based on a purely theoretical analysis since these configurations have never been tested. However, unexplored safety related consequences does not mean no safety consequences!

With this in mind, the key question is: how to avoid installing a Data Loadable Unit with an inadequate FLS standard?

Being convinced of having installed the correct FLS standard although not having it, can in turn come from different reasons, such as:

• not having realized that the DLUs consist of two distinct parts, namely a hardware one and a software one, bearing 2 distinct Part Numbers and 2 FINs (Functional Item Number),
• being excessively confident in the shop that delivers the parts to be installed (the DLU received from the shop might not be loaded with the relevant operational software, i.e. the one that matches the actual aircraft configuration),
• relying on the spot on an old habit where a quick external glance at physical parts and their labels was sufficient to tell the computer standard.

As explained earlier, the introduction of Field Loadable Software comes with a change in philosophy and the emergence of a new intangible dimension in aircraft configuration management. In contrast to hardware parts, operational software are always hosted. They are the invisible ones, behind the scene.

Concerning the parts managed by the shop, the disconnection between the hardware and the operational software for DLUs also implied switching from a unique computer FIN integrating both the hardware and software parts, to two distinct FINs corresponding respectively to the hardware PN and the operational software PN. In some airlines though, the spare parts supply chain management tool remained unchanged and does not accommodate two different FINs for a single FLS computer. This limitation induces difficulties to ensure that the computer delivered is loaded with the appropriate operational software version.

In any case, an ultimate safety barrier was developed and included into the AMM to prevent the installation of improper operational software onto the aircraft: operational software identification via LRU IDENTIFICATION action and cross check of that information with the PN displayed on the media disk (fig.1).

Computer removal & installation is
usually performed in line maintenance. In practice, it may for example
mean being under operational pressure to keep the aircraft on schedule.
However, performing this check of the software reference between the one
displayed in the cockpit, on the LRU IDENTIFICATION page, against the
one showed on the media disk is the only way to detect any discrepancy
whatever its origin. Indeed, as mentioned earlier, a quick look at the
DLU hardware can only tell part of the story.

The in-depth analysis of reported events allowed for better understanding where problems originated from, and thus for devising ways forward.

As of today, the available prevention measures include:

• The improvement of the IPC to include explicit content and reinforce awareness on FLS (fig.2).
• The improvement of the ISI (In-Service Information) documentation as a support for your fleet management. This document offers a good overview of existing certified configurations by explicitly explaining the hardware PN & operational software PN combination compatibility with the aircraft configuration. This advice is provided on the understanding that an ISI is not an approved instruction; therefore once a configuration is identified by this means, the IPC must be checked in order to confirm that it is a certified one indeed.
• The introduction in the Field Loadable Software training on A320 Family aircraft, of more details on the recommended uploading procedure, as well as a reminder of these DLUs specificity compared to earlier standards of computers.

Going further, Airbus aims at facilitating the visual distinction of the
hardware between the ones including the data loading function and the
others. To this end, work is already ongoing in order to define and
develop a new label that will be placed onto each DLU. This reinforced
attention getter will aim at improving the visual identification of DLUs
and thus, reminding the need to check the operational software PN.