A320 Family Aircraft configuration

Source: Airbus Safety First URL: https://safetyfirst.airbus.com/a320-family-aircraft-configuration/ Published: 2016-01-28 Magazine Issue: 2016-01 Category: Maintenance, DLU, identification,, identifier, loadable, LRU, mixability, P/N, PN PDF: Original PDF

---

052 Safety First #21 | January 2016 AIRCRAFT

In 2009, a new data loading function was introduced on A320 Family aircraft Flight Control and Auto Flight systems computers. Although the operational improvements brought by Field Loadable Software (FLS) are widely appreciated, experience gained with them highlights a potential for aircraft configuration mismanagement as a result of improper software part number uploading in the computers.

In fact, the use of data loadable computers requires to manage not only hardware Part Numbers (PN), but also software PN and their combinations. This evolution calls for a change in mind sets and practices to properly manage FLS and data loadable computers configurations and in turn, the aircraft configuration.

This article will highlight the underlying safety aspects of an incorrect use of FLS and review how to best prevent it.

FIELD LOADABLE SOFTWARE: WHAT IS IT ABOUT?

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.

Are all A320 Family aircraft concerned?

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.

On the existing A320 Family fleet, some aircraft have FLS, others don’t. Yet, all aircraft can accommodate DLUs.

AIRCRAFT

What does the data loading function change in practice?

A quick glance at the hardware installed cannot tell everything about the FLS standard, and in turn, the actual aircraft configuration.

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

Non-DL ELAC

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.

DL ELAC

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!

operating such configurations, whether 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.

Indeed, uploading an operational software into a hardware which is not supposed to receive it, leads to a noncertified aircraft configuration. This implies that the consequences of

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.

Case 1: Excessive structural loads - unknown structural fatigue

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 preSharklet 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 noncertified configuration leads to structural loads and ultimately structural fatigue that have not been studied as such, but could ultimately result in safety concerns.

Case 2: Falsely relying on a safety enhancement not implemented on the aircraft

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.

AIRCRAFT

Case 3: Improper surfaces control and unexpected aircraft behavior

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:

Unexplored safety related consequences does not mean no safety consequences.

• Mix of Sharklet capable and nonSharklet 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:

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

• Mix of Sharklet capable and nonSharklet 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.

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

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?

DID YOU KNOW

ISI (In-Service Information) Ref. 27.93.00001 “ELAC mixability and interchangeability matrices” details how to manage data loadable units and associated Part Numbers. This document can be found on Airbus World.

PREVENTION: HOW TO AVOID INSTALLING A DATA LOADABLE UNIT WITH AN INADEQUATE OPERATIONAL SOFTWARE STANDARD?

In view of the potential operational consequences described earlier, Operators need to be cautious with FLS and DLUs management in order to ensure their aircraft are operated in a certified

configuration at all time. Prevention starts with a good awareness of the most common factors that can contribute to having a DLU loaded with an undesirable operational software.

The investigation into reported events of improper operational software uploaded into Data Loadable Units highlighted a variety of initial contributing factors. Yet, they all have in common a major step being overlooked in the computer removal/installation AMM procedure: operational software identification through a LRU IDENTIFICATION check (LRU stands for Line Replaceable Unit)!

When operating FLS, strict adherence to all of the steps detailed in the AMM removal/installation tasks, and the LRU IDENTIFICATION step in particular, is the foundation of a good aircraft configuration management.

In more detail, investigation results highlighted that installing a DLU loaded with inappropriate software often results from the combination of being convinced to have the correct computer although not having it, and not taking the time to perform the procedure correctly, especially the operational software identification

step requested in the AMM installation and uploading tasks.

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 configuration management. In contrast Field Loadable Software comes with a to hardware parts, operational software change in philosophy and the emergence are always hosted. They are the invisible of a new intangible dimension in aircraft ones, behind the scene.

A320 Family Aircraft confi guration

AIRCRAFT

(fi g.1)

Preventing the installation of an improper ELAC operational software onto the aircraft thanks to the AMM

induces diffi culties to ensure that the computer delivered is loaded with the appropriate operational software version.

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

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 (fi g.1).

4. Procedure Subtask 27-93-00-280-052-A

• A. Do a check of the reference of the software loaded in the ELAC

NOTE: This procedure is for the ELAC1. For the ELAC2, use the indications between the parentheses.

• (1) Do the procedure to get access to the SYSTEM REPORT/TEST F/CTL page (Ref. AMM TASK 31-32-00-860-006).

ACTION

RESULT

• 1.Push the line key adjacent to the EFCS 1(2) in· The EFCS 1(2) menu page comes into view. dication.

• 2.Push the line key adjacent to the LRU IDENTI· The LRU IDENTIFICATION page comes into FICATION indication. view.

• (2) Make sure that the P/N of the ELAC shown on the LRU IDENTIFICATION page is the same as the P/ N on the media disk.

Operational software identifi cation (LRU IDENTIFICATION) is the ultimate safety barrier to prevent inappropriate FLS and aircraft confi gurations.

• (a) If the P/N of the ELAC shown on the LRU IDENTIFICATION page is different from the P/N on the media disk, replace the ELAC.

• NOTE: If the two ELACs were not loaded with the same software, make sure that the configuration of the ELAC1/ELAC2 is a permitted configuration.

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 (fi g.2).

• The improvement of the ISI (In-Service Information) documentation as a support for your fl eet management. This document offers a good overview of existing certifi ed confi gurations by explicitly explaining the hardware PN & operational software PN combination compatibility with the

aircraft confi guration. This advice is provided on the understanding that an ISI is not an approved instruction; therefore once a confi guration is identifi ed by this means, the IPC must be checked in order to confi rm that it is a certifi ed 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 specifi city compared to earlier standards of computers.

The IPC raises awareness on FLS

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 defi ne and develop a new label that will be placed onto each DLU. This reinforced attention getter will aim at improving the visual identifi cation of DLUs and thus, reminding the need to check the operational software PN.

For those who have already experienced losing one of their favourite functionalities on their computer, smartphone or tablet because a new version of operating system had been developed and not yet updated on it, it is an unpleasant experience. When it comes to a Flight Control or Auto Flight computer loaded with a wrong operational software version, it can be far worse since it can affect safety. No doubt it is worth the very limited time and effort of a LRU IDENTIFICATION!

---

中文译文

052 Safety First #21 | 2016年1月 飞机

2009年，A320系列飞机飞控和自动飞行系统计算机引入了新的数据加载功能。虽然现场可加载软件（Field Loadable Software，FLS）带来的运行改进广受认可，但使用经验表明，由于计算机中软件零件号（Part Number，PN）上传不当，存在飞机构型误管理的潜在风险。

事实上，使用数据可加载计算机不仅需要管理硬件零件号（PN），还需要管理软件零件号及其组合。这种演变要求改变思维方式和实践做法，以正确管理FLS和数据可加载计算机的构型，进而管理飞机的整体构型。

本文将重点阐述不正确使用FLS的潜在安全方面，并回顾如何最好地预防此类问题。

现场可加载软件：它是什么？

与数据可加载单元（Data Loadable Unit，DLU）相关的现场可加载软件（Field Loadable Software，FLS）最初引入是为了方便标准的演进和备件的管理。为此，这些计算机提供了升级的硬件，能够容纳不同版本的操作软件，即不同的标准。因此，更新FLS的标准无需将硬件本身从飞机上拆下。实际上，它只是简单地将操作软件的新版本从介质盘上传到同一硬件上，可以直接在机上进行，也可以使用便携式数据加载器。

所有A320系列飞机都涉及吗？

现场可加载软件大约在六年前开始在A320系列飞机上逐步引入。实际上，在现有机队中，一些飞机有此功能（无论是交付时自带还是通过服务通告改装），另一些则没有。但是，即使是未配备此功能的飞机也可以安装DLU硬件，只是不能使用飞机数据加载功能。在这种情况下，硬件需要在修理厂上游预先安装适当版本的操作软件。装载了相关FLS标准的DLU随后表现得就像一个不可加载的计算机。

在现有A320系列机队中，一些飞机有FLS，另一些则没有。然而，所有飞机都可以使用DLU。

飞机

数据加载功能在实践中改变了什么？

仅凭对已安装硬件的快速查看无法完全了解FLS标准，进而无法了解实际的飞机构型。

如果使用适当标准加载的DLU表现得与不可加载计算机完全一样，无论它是安装在具有数据加载功能的飞机上还是未安装的飞机上，但这种新DLU的使用在备件和飞机构型管理方面引入了一个重大变化：一个新的、无形的且不能立即可见的维度的出现。

事实上，由于数据可加载单元引入的硬件与操作软件之间的分离，飞机构型由物理零件零件号（PN）以及操作软件零件号（PN）组成。

非DL ELAC

在实践中，这意味着仅凭对已安装硬件的快速查看不足以识别FLS标准，进而无法了解实际的飞机构型。

DL ELAC

没有人会在飞机上安装不正确的硬件零件号，因为那样飞机会处于未取证状态，并可能产生所有潜在的安全后果。使用不正确的操作软件飞行与此情况相同！

运行这些构型，无论是即时的还是延后的，都无法被研究和测试，因为探索它们实际上超出了设计研究的范围。然而，这些构型确实存在，并且可能具有潜在的显著安全维度。

事实上，将操作软件上传到不应接收该软件的硬件中，会导致飞机处于未取证构型。这意味着此类构型的后果——无论是即时的还是延后的——都无法被充分研究和测试，因为探索它们超出了设计研究的范围。然而，这些构型确实存在，并且可能具有潜在的显著安全维度。

确实，将操作软件上传到不应接收该软件的硬件中，会导致飞机处于未取证构型。这意味着其后果——无论是即时的还是延后的——都无法被研究或测试，因为探索它们超出了设计研究的范围。然而，这些构型确实存在，并且可能具有重大的安全影响。

实际上，在服务中观察到的案例很好地说明了后果是多样的，并且可能以非常不同的方式损害安全。

案例 1：过度结构载荷——未知结构疲劳

鲨翼小翼（Sharklet）飞机包含一项新的载荷减轻功能（LAF），用于限制机翼载荷。此功能是确保机翼载荷保持在认证要求范围内的关键。在鲨翼小翼飞机上安装鲨翼小翼之前的 ELAC（升降舵和副翼计算机）和/或 SEC（扰流板和升降舵计算机）标准，将导致

失去此 LAF 功能，从而使机翼暴露于未经预期和研究过的载荷之下。如果无法立即检测到后果，这种未经认证的构型将导致结构载荷累积，并最终引发未经研究确认的结构疲劳，极端情况下可能产生安全隐患。

案例 2：错误依赖飞机上未实现的安全增强功能

为了降低尾撬触地或硬着陆的可能性，开发了新的 ELAC 标准，改进了从过渡拉平法则到地面法则的转换逻辑。飞行时飞机本应安装这些新计算机，但实际安装了改进前的 ELAC 标准，会导致飞行员认为他们受益于这些改进，而实际上并未受益。这就如同驾驶一辆自以为配备了

ABS 防抱死制动系统的汽车，而实际上该功能并不存在。

同样，跑道超限保护系统（ROPS）仅在最新的可加载 FAC（飞行增强计算机）标准上可用。在具备 ROPS 能力的飞机上安装旧版软件，将导致失去此安全增强功能，而机组人员对此毫无察觉。

飞机

案例 3：操纵面控制不当和异常飞机行为

在鲨翼小翼飞机上，如果错误地混装了支持鲨翼小翼和不支持鲨翼小翼的 FLS（考虑到这是一种不允许且未经认证的构型），飞机的操控特性和行为可能会受到影响。根据所涉及的 DLU 类型，可能的后果包括：

未经探索的安全相关后果并不意味着没有安全隐患。

• 支持鲨翼小翼和不支持鲨翼小翼的 ELAC/SEC 所提供的扰流板、副翼和/或升降舵操纵面作动指令和监控可能因每个 ELAC/SEC 控制的作动筒不同而存在差异。

• 这可能导致：

  • 左、右副翼同步未能按预期正确执行（可能导致飞机出现异常行为）。

  • 混装支持鲨翼小翼和不支持鲨翼小翼的 FAC 在鲨翼小翼飞机上安装不支持鲨翼小翼的 FAC，可能导致特性速度计算错误，进而影响相对于失速速度的安全裕度。

• 升降舵双重加压情况下的力量对抗（可能导致结构损伤和/或飞机异常行为）

以上案例并非穷举因 DLU 硬件加载了不期望的软件标准而导致的所有安全相关后果。部分所述影响是基于纯理论分析推导的潜在影响，因为这些构型从未经过测试。然而，未经探索的安全相关后果并不意味着没有安全隐患！

基于以上认识，关键问题在于：如何避免安装具有不适当 FLS 标准的数据可加载组件（DLU）？

你知道吗

ISI（服务信息）参考 27.93.00001 “ELAC混装性和互换性矩阵” 详细说明了如何管理数据可装载组件及其相关件号。该文档可在空客World上找到。

预防：如何避免安装数据可装载组件时使用不恰当的运营软件？

鉴于前述潜在的运营后果，运营商在FLS和DLU管理方面需要谨慎，以确保其飞机始终以认证构型运营。预防始于对最常见因素的充分认识，这些因素可能导致DLU装载了不期望的运营软件。

对数据可装载组件中错误运营软件上传事件的调查，突出显示了多种初始致因因素。然而，它们都有一个共同点：在计算机拆/装AMM程序中，一个关键步骤被忽略了：LRU标识检查（LRU指航线可更换件）！

在FLS操作中，严格遵守AMM拆/装任务中详述的所有步骤，尤其是LRU标识步骤，是良好飞机构型管理的基础。

更详细地说，调查结果显示，安装装载了不适当软件的DLU通常源于以下因素的组合：确信已安装正确的计算机（但实际上并非如此），以及没有花时间正确执行程序，特别是AMM安装和上传任务中要求的运营软件识别步骤。

确信已安装正确的FLS标准（但实际上并非如此）可能由以下不同原因造成：

• 未意识到DLU由两个不同的部分组成，即硬件部分和软件部分，各自对应不同的件号和两个FIN（功能件号）；

• 对提供待安装部件的车间过度信任（从车间收到的DLU可能未装载相关的运营软件，即与实际飞机构型相匹配的软件）；

• 依赖旧习惯，即仅凭对物理部件及其标签的快速外观检查就足以判断计算机标准。

如前所述，构型管理的引入带来了哲学观念的转变以及飞机运营软件这一新的无形维度的出现。与硬件部件不同，现场可装载软件总是承载着运营软件。它们是无形的，在幕后运行。

A320系列飞机构型

飞机

（图1）

通过AMM防止将不正确的ELAC运营软件安装到飞机上

会导致确保交付的计算机装载了适当运营软件版本方面存在困难。

关于由车间管理的部件，DLU的硬件与运营软件分离也意味着从集成硬件和软件部分的单一计算机FIN，转变为分别对应硬件件号和运营软件件号的两个不同FIN。然而，在某些航空公司中，备件供应链管理工具保持不变，未能适应单个FLS计算机的两个不同FIN。这一限制

无论如何，最终的安全屏障已被开发并纳入AMM，以防止将不正确的运营软件安装到飞机上：通过LRU标识操作进行运营软件识别，并将该信息与媒体磁盘上显示的件号进行交叉检查 （图1）。

4. 程序子任务 27-93-00-280-052-A

• A. 检查装载到ELAC中的软件参考

注：该程序适用于ELAC1。对于ELAC2，使用括号中的指示。

• (1) 执行进入SYSTEM REPORT/TEST F/CTL页面的程序（参考AMM任务31-32-00-860-006）。

措施

结果

• 1.按下与 EFCS 1(2) 显示相邻的行选择键。· EFCS 1(2) 菜单页面出现。

• 2.按下与 LRU IDENTIFICATION（LRU识别）显示相邻的行选择键。· LRU IDENTIFICATION 页面出现。

• (2) 确认 LRU IDENTIFICATION 页面上显示的 ELAC P/N 与媒体盘上的 P/N 相同。

运行软件识别（LRU IDENTIFICATION）是防止不恰当 FLS 和飞机配置的最后一道安全屏障。

• (a) 如果 LRU IDENTIFICATION 页面上显示的 ELAC P/N 与媒体盘上的 P/N 不同，则更换 ELAC。

• 注：如果两个 ELAC 未加载相同的软件，应确认 ELAC1/ELAC2 的配置是允许的配置。

计算机拆装通常在航线维护中执行。在实践中，例如可能意味着在保持航班正点方面承受着运营压力。然而，将驾驶舱 LRU IDENTIFICATION 页面中显示的软件与媒体盘上显示的软件进行比对检查，是检测任何来源差异的唯一方法。确实，如前所述，仅查看 DLU 硬件只能了解部分情况。

通过对报告事件的深入分析，能够更好地理解问题产生的根源，从而制定解决方案。

目前可用的预防措施包括：

• 改进 IPC，增加明确内容并强化对 FLS 的认识 (图2)。

• 改进 ISI（服务信息）文档以支持机队管理。该文档通过明确说明硬件 P/N 与运行软件 P/N 组合与飞机配置的兼容性，提供了现有认证配置的概览。该建议基于以下理解：ISI 不是批准性指令；因此，通过此方式识别配置后，必须检查 IPC 以确认该配置确实是经认证的。

• 在 A320 系列飞机场加载软件培训中，增加关于推荐上传程序的更多详细信息，以及对这些 DLU 与早期标准计算机相比特殊性的提醒。

IPC 提升对 FLS 的认识

进一步来说，空中客车公司旨在便于区分包含数据加载功能的硬件与其他硬件。为此，正在进行定义和开发新标签的工作，该标签将贴附在每个 DLU 上。这一强化的警示标识将旨在改进 DLUs 的视觉识别，从而提醒需要检查运行软件 P/N。

对于那些曾因新版操作系统发布但尚未在设备上更新而导致电脑、智能手机或平板电脑失去某些常用功能的人来说，这是一段不愉快的经历。当涉及加载了错误运行软件版本的飞行控制或自动飞行计算机时，情况可能更糟，因为这可能影响安全。毫无疑问，LRU IDENTIFICATION 所花费的非常有限的时间和努力是值得的！