0 引言

随着大型运输类飞机的电子化程度越来越高，飞机机载软件越来越多的安装和应用在飞机各系统涉及的功能部件中。ARINC 667-3作为机载软件使用管理的指导标准，规定了机载软件的分类以及各项使用要求。客户化软件是航空公司可以直接修改的机载软件，这类软件虽然不会直接影响飞机的适航性和安全，但对航空公司的运行却起着关键的作用。

本文结合某航空公司编制和安装客户化软件的实际案例，对航空公司客户化软件的工程管理问题进行了研究和分析，并给出了航空公司对于客户化软件的管控思路和建议。

1 机载软件定义和分类

1.1 机载软件的定义

机载软件（飞机可装载软件）是指所有在飞机上或修理车间无需拆除目标硬件就可被装载的软件。这类软件都有自己的部件号或版本号，并且软件的构型管理是基于飞机整体而独立于其目标硬件的。机载软件的其他主要特性包括：

1）与硬件部件不同，机载软件不通过序列号控制。

2）机载软件的装载不影响目标硬件的部件号。

3）飞机上可识别和验证机载软件的部件号或版本号。

4）取决于机载软件的目标硬件及其功能，其可能需要适航或运行的批准。

值得注意的是，随着行业的发展，描述机载软件的术语也在发生改变。这些术语都可用于描述机载软件，但其侧重点各有不同，以下是机载软件术语的演变过程：

1）现场可装载软件（field loadable software，简称FLS），其关注的是机载软件的可加载属性。

2）可装载软件部件（loadable software part，简称LSP），其关注的是机载软件是飞机部件的一种以及其可装载的属性。

3）飞机控制可装载软件部件（aircraft controlled loadable software part，简称ACLSP），其更关注的是机载软件是如何控制的，而非是如何装载的。ACLSP是目前行业内对机载软件最准确的描述术语。

1.2 机载软件的分类

1.2.1 适航批准类机载软件（loadable software approved part，简称LSAP）

LSAP是须经各国局方（CAAC、FAA、EASA）所发布的适航规章批准生产或更改的ACLSP，在中国相关适航管理的具体要求体现在CCAR 21部和CCAR 25部规章中，且包括以下两类：

1）供应商控制机载软件（supplier controlled software，简称SCS）：由型号合格证/补充型号合格证（简称TC/STC）持证人或软件开发者提供的LSAP，多为飞机关键系统软件，例如：运行程序软件（OPS）、选项选择软件（OSS）和航空公司运行控制软件（AOC）等。

2）用户控制机载软件（user controlled software，简称UCS）：由运营人制作或修改且需要局方批准的LSAP，例如客舱灯光控制软件，烟雾/客舱座椅安全带警告软件等。

1.2.2 运行批准类机载软件

运行批准类机载软件是指无须CCAR 25部适航规章批准、由运营人批准的ACLSP软件，运营人应向局方确认运行批准类机载软件的适用范围。若局方法规无相关要求，运营人可自行定义此类软件的种类，包括以下四类：

1）用户可更改机载软件（user modifiable software，简称UMS）

UMS包含预先批准和验证的功能，运营人对这类软件在预先认证修改范围内进行的修改无需经过局方、型号合格证持有人或部件制造商的审核。此类软件不影响飞机的适航和安全，修改范围包括数据及运行代码。TC/STC持证人有责任告知运营人UMS的适用范围并提供相应的技术支持资料，运营人有权咨询制造商其提供的软件是否是UMS。

2）飞行运行机载软件（flight operations software，简称FOS）

FOS是经运营人批准的支持飞机飞行运行的相关机载软件，如大部分电子飞行包软件和数据库，包括飞行操作电子手册、导航图、机场地图数据库等。FOS应遵照EASA AIE-OPS、FAA AC 120-76A、14 CFR 121等法律规章要求进行管理。FOS是UMS的一种。

3）维护操作机载软件（maintenance operations software，简称MOS）

MOS是经运营人批准的飞机维护类机载软件，包括技术出版物应用及其相关电子文档，MOS应遵照EASA Part M、14 CFR Part 121等法律规章要求管理。MOS是UMS的一种。

4）飞机数据库机载软件（aeronautical database，简称ADB）

ADB是经过运行批准的数据库类软件，通常需要特别的构型管理流程和满足相应的监管要求，此类软件应用于飞行管理系统（FMS）和地形警告系统等，并需要定期更新，例如导航数据、飞行计划、近地警告等。FOS是UMS的一种。

1.2.3 飞机支持类软件（aircraft support data，简称ASD）

ASD是指既无须CCAR 25部适航规章批准，也无须运营人批准的ACLSP，运营人可对其进行自定义分类，例如IFE系统软件、旅客联网软件等。

硬件控制机载软件（HCLSP）是指数据加载不会改变硬件内存物理属性，可独立于硬件管控，但其构型信息与硬件件号绑定（如HCLSP更改，其所在硬件的件号必须随之改变）的机载软件，通常由经授权的修理站安装及批准放行。

典型的飞机软件与机载软件的关系以及机载软件的分类及定义，如图1所示。

结合上述的研究和分析不难发现，飞机各级软件的关系和分类比较复杂，因此给各类软件的管理控制和风险防范带来一定的挑战。部分软件经过适航法律规章体系框架的严格审核和批准，其管理模式比较规范；部分软件是在航空公司运行体系下由内部的流程标准进行管理和控制，特别是UMS类机载软件无须经过其他机构审查，可自行制定和修改其软件数据，因此在缺少适航体系审查监管环节的情况下，如果航空公司自身对此类机载软件管控不到位，也会带来影响运行的风险。

2 UMS机载软件编制和修改案例分析

卫星通讯电话本（owner requirement table，简称ORT）是典型的UMS，由航空公司根据自身运行控制系统确定的电话号码进行编制和修改。卫星通讯电话本装载于飞机的航线可更换件—卫星数据组件（satellite data unit，简称SDU）内，用于飞行人员在飞机上快捷选号拨打电话，实现与相关运行控制、保障部门的快速通讯联络。

某航空公司在为其运营的某型号飞机编制和修改客户化软件卫星通讯电话本的时候，曾发生如下案例：

在2022年4月之前，该公司一直使用A版本的卫星通讯工具软件（satcom software tool，简称SST）制作和修订其飞机卫星通讯电话本，且能够保证卫星通讯系统正常使用。在5月时，由于运行需求变化（地面保障部门联系电话发生变更），需要修订机上卫星通讯电话本。在使用“A”版本SST修改机上卫星通讯电话本之后，制作产生了“a”件号（包括版本标识）的ORT软件且经过了相关校验环节，其完整度和兼容性均正确可用。之后，将“a”件号的ORT软件在飞机上装载时，安装顺利且正常。

经过一段时间运行与使用，在6月飞机执行某次航班时，机组报告卫星通讯系统电话号码本存在部分号码缺失问题。后续对该飞机的SDU进行了更换，并且为新装机的SDU重新升级装载“a”件号的ORT软件后，飞机显示ORT软件版本正确、电话号码表完整且地面测试正常。但在后续拨打电话进行操作测试时，卫星通讯系统一直显示“系统不可用”。

进一步调查研究发现，制作卫星通讯ORT软件的SST工具软件有更高的“B”版本。因此，使用“B”版本的SST工具重新制作和修改了卫星通讯ORT软件，仍定义为“a”件号，重新装机和测试，并且拨打电话进行实际操作测试，进而确认卫星通讯系统可用，故障彻底排除，飞机恢复正常使用。

工程技术部门对上述典型案例进行的全过程调查发现：

1）该架飞机在5月安装了“a”件号的ORT软件之后，曾由于卫星通讯系统故障进行了SDU更换工作。排故后装机使用的SDU中已经装载的ORT为“a”件号之前的旧版本，没有进行“a”件号ORT软件的升级装载工作。因此没有体现5月卫星通讯电话本的变更内容，造成部分电话号码缺失。即，在航线针对卫星通讯系统排故更换SDU时，没有按照构型标准和管理要求为新装机使用的SDU装载最新有效版本的ORT软件。

2）在与卫星通讯系统的机载设备制造商联络后，获悉制作卫星通讯ORT软件的SST工具软件有更高的“B”版本，且在“B”版本SST发布后，终端用户并没有及时获知此变更信息，一直使用旧的“A”版本SST编制和修改ORT软件。

3）“A”和“B”两个版本的SST工具软件的“SATCOM FUNCTION”功能模块中包括一项关键信息变化，即各个卫星区域信息存在差异：

（a）“A”版本的SST匹配的卫星数量为5颗（编号分别为00、01、02、03、04），“B”版本的SST匹配的卫星数量为8颗（编号为00、01、02、03、04、05、06、07）。

（b）2018年，上游系统服务商进行了卫星换代工作，将部分第三代卫星退役并切换至第四代卫星来提供卫星通讯服务。编号为00、02、03、04的卫星在2018年底均已停止提供服务。

（c）使用“A”版本SST制作的ORT，仅有匹配的编号01卫星提供服务。因01号卫星在空间的分布位置限制，飞机机载卫星通讯系统不能与该卫星建立有效连接，进而卫星通讯系统显示“不可用”。

（d）使用“B”版本SST制作的ORT，匹配的卫星有8颗，包括正在提供服务的01、05、06、07号卫星，且能够覆盖全球范围。因此使用“B”版本的SST制作的ORT，机载卫星通讯系统可完成自动搜星工作，卫星通讯系统正常可用。

4）在使用“A”和“B”两个不同版本的SST编辑ORT时，虽然电话号码内容本身没有差异，但由于两个版本SST内置关键参数存在变化，制作的ORT软件存在实质性的功能差异，应当进一步完善ORT构型标识，如：将使用“A”版本SST制作的ORT软件定义为“a”件号（包含版本号），将使用“B”版本SST制作的ORT软件定义为“b”件号（包含版本号），避免造成后续软件构型管理的混淆与混乱。

5）经过与飞机及设备制造厂家进一步充分沟通并且全面回顾，发现飞机及设备制造厂家曾在2018年初通过信息类服务文件等形式在行业内对卫星迭代、相关通讯服务转换和影响进行了通报。因此，未能及时追踪和捕捉此类重大明显影响运行的信息类文件并及时评估和采取针对性的工程技术措施，也是导致本次卫星通讯系统不可用的重要原因。

3 UMS管控思路与建议

虽然UMS的修改对飞机适航安全不会造成影响，但通过对上述案例的分析可以得知，对UMS错误的修改可能会对航空公司运行有比较严重的影响。因此航空公司需要建立必要的制度体系对UMS进行有效的管控。结合本文的具体案例分析和调查研究结论，对UMS编制和修改的管控提出如下思路和建议。

3.1 UMS变更管理

在变更UMS前，航空公司应与飞机制造厂家或UMS供应商确认所有必须提供的技术支持文档和UMS修改工具，必要时可签署UMS技术服务协议以规定双方需要承担的责任和履行的义务。

1）需求评估

通常UMS的制作由航空公司的维修工程管理部门负责，但变更需求可能来自航空公司内部各部门。航空公司维修工程管理部门应将所有UMS变更需求纳入自身工程评估体系，由有资质的技术人员进行评估并实施。

2）制作工具管理

飞机制造商或UMS供应商负责提供用于制作和修改UMS的工具，这些工具应具备开发和发布UMS所需的功能，如：软件编辑器、软件编译器、软件部件号生成器和媒体集创建工具等。航空公司应与飞机制造商或UMS供应商明确UMS制作工具的获取途径。当制作工具版本更新时，航空公司应进行适用性评估，保证使用适用本机队构型的制作工具制作UMS。

3）件号管理

航空公司应制定UMS的部件号生成规则。部件号规则的制定原则应可区分不同UMS的种类、版本和构型并保证唯一性。

4）测试

航空公司应建立UMS测试必要性的评估方法。如有必要，应制定UMS测试方法并进行测试，测试的目的是保证UMS功能正常并满足修改的功能预期。

3.2 UMS的质量保证管理

1）人员培训与授权

UMS的变更评估、制作、分部和批准应由具备资质的人员完成。航空公司应建立UMS制作人员资质评估和授权方法，并将其纳入自身的质量管控体系。授权人员应接受过其授权制作的UMS的完整培训以及必要的复训。

2）变更记录

航空公司应对每次UMS的变更内容进行记录，记录内容应包括但不限于：制作人员、制作日期、软件部件号、软件制作工具、变更原因、变更内容、飞机适用性和批准方式等。

3）UMS的批准

航空公司对UMS在预先取证变更范围内进行的变更无需经过局方、型号合格证持有人或部件制造商的审核和批准，但需要建立内部批准流程。UMS应由具备资质的人员完成评估、变更、发布和批准等工作。批准方式可以是符合性声明（statement of conformity）或合格证明（certification of conformance）等。

4 结论

随着民用飞机航电系统的发展，机载软件在飞机系统中承担越来越重要的作用，其中客户化软件对飞机的正常运行有着重要的影响。本文对机载软件分类和定义进行了研究，通过对某航空公司UMS制作原因导致飞机故障的案例进行分析，总结得出了对UMS变更和质量保证管理的注意事项，为航空公司提供了对UMS管控思路与建议。

参考文献