曾亮亮，朱江雷，吕欣

(中国航空工业集团有限公司 成都飞机设计研究所， 成都 610073)

0 引 言

测试性是产品能及时、准确地确定其状态(可工作、不可工作或性能下降程度)，并隔离其内部故障的一种设计特性[1]，测试性是飞机重要的通用质量特性之一。军用飞机机载系统的测试性设计水平能够直接影响到其再次出动的效率和使用、维护成本。测试性设计的优劣最终体现为飞机机载系统的故障诊断能力和测试性评估结果。对于故障诊断能力，一方面，在飞行过程中，体现为能够检测系统关键功能的完好性，为飞行员提供判断飞机状态和任务执行所需的信息；另一方面，在地面，体现为能够检测系统关键功能的完好性，为飞机放飞提供依据，并能够将故障隔离到外场可更换单元(LRU)级，方便地勤人员排故。系统和设备的故障诊断能力决定了测试性评估结果的优劣。

飞机的故障诊断能力通过系统级机内自测试(BIT)实现，根据系统级BIT结果，机载系统定义了告警等级和飞行员故障清单(PFL)，将系统用于评估的关键功能故障和异常提示给飞行员。同时，在地面，地勤人员能够通过地面设备查看、分析系统故障和飞参数据，达到排故的目的。然而，由于在机载系统实际设计过程中，测试性设计与功能、性能设计相对孤立，设计过程中缺乏验证环节，也没有从用户的角度充分考虑故障诊断的实际使用需求，导致诊断能力较低、使用效率低，甚至服役前期虚警率较高，飞机的测试性能力提升较缓慢。

当前对测试性设计的研究，更多的体现在专门的测试性设计技术[2]、故障诊断方法/系统[3-4]、试验与评价方法[5]等方面，而从总体层面对测试性设计体系的研究则相对较少。

本文旨在分析导致军用飞机诊断能力不足的根本原因，并结合实际使用需求，在现有测试性设计流程的基础上提出一套涵盖从设计到验证的测试性设计体系。找出机载系统测试性设计体系中的关键设计环节，对关键设计环节在体系中的重要性、技术要点、实现方式和实现程度进行剖析。从工作方法、专业定位和制度保障等方面提出改进建议，以保证将测试性设计有机地融入到机载系统设计过程中，实现机载系统测试性水平的提升。

1 问题分析

机载系统测试性设计通常以测试性工作计划、测试性设计要求和测试性设计准则作为测试性设计的顶层设计文件，用于指导机载系统开展测试性设计。在系统方案设计阶段，进行测试性指标分配、测试性建模优化等；在研制阶段，根据诊断需求和诊断数据流需求，进行机上数据流与接口设计，BIT硬件、软件设计，并对测试性指标进行预计；在设计鉴定/定型阶段，根据外场使用数据并结合部分试验数据，对机载系统进行指标评估。在上述测试性设计流程中，若某些关键环节的设计工作未能很好地贯彻执行，甚至缺乏关键设计环节，则会致使飞机在使用过程中表现出诊断能力差的问题，而导致这一问题的宏观原因可以概况为以下四个维度。

维度1机载系统层和成品层测试性工作衔接与协调问题。成品的测试性能力是影响机载系统测试性能力的关键因素之一，机载系统应根据用户要求对成品提出详细的定量和定性测试性要求，明确产品需BIT检测的功能，尤其对没有BIT能力的成品，应提出能反映成品状态的输出信号需求，在系统层对成品状态进行判断；机载系统和成品故障模式、影响及危害性分析(Failure Mode Effects and Criticality Analysis，简称FMECA)质量较差，且机载系统在进行FMECA分析时没有充分利用成品的FMECA结果，对故障模式认知的不成熟导致测试性设计时无的放矢，在系统层问题尤为突出；系统和成品的协调不到位，导致系统和成品的分工出现偏差，一些本应在系统层实现的检测未能实现；系统顶层测试性设计的缺失，直接利用成品上传的BIT信息作为系统级BIT结果。

维度2测试性专业与系统专业分工与配合关系问题。测试性专业负责测试性顶层规划、指南性文件的编制，具体的测试性设计与分析工作由系统专业负责，机载系统最终的测试性能力取决于系统专业人员的测试性设计水平，而测试性人员不管具体的测试性要求实现，系统专业人员不一定将测试性要求贯彻到系统设计中，这就造成测试性设计的脱节；机载系统的测试性能力以成品测试性设计为基础，成品主管对成品测试性设计结果进行监督和指导，而实际上这部分工作变成测试性专业人员向成品厂提建议的形式来实现；对于机载系统的测试性评估，责任主体应该是系统专业，而实际上测试性评估后果由测试性专业承担。因此，在专业分工和责任划分上不合理。

维度3设计单位与最终用户的需求协调问题。在定义BIT的故障和设计测试系统时，应分别考虑飞行员和地勤人员所需的信息，制定统一的原则，而实际上通常将相关联的故障不加分析地同时显示给用户，增加额外的排故工作；测试性的设计要求与评估，应考虑空中和地面的使用需求，从如何在外场发现故障的角度去规划综合诊断策略，利用BIT、便携式维护设备(PMA)、地面原位检测设备、目视检查等手段实现综合故障检测，而不是一味地只关注BIT故障检测率。

维度4对测试性工作项目本身的认知误差。测试性设计工作不仅仅是编大纲、准则、分配、分析报告、指标预计，这些只是工作结果，且结果形式尚不完善，而完整的测试性工作项目除了上述结果性报告形式的工作外，更应该体现设计工作，包括综合诊断方案、测试点布局方案、测试能力配置、故障定义、状态监控方案、参数定义、告警与故障显示方案、参数判读方案。

上述因素表现在机载系统测试性设计环节的现象如图1所示，具体如下：

(1) 分析某层级故障模式时直接分析到下一级故障模式，无本层级故障模式分析；

(2) LRU级向系统级传递过程中，故障模式定义和数量差异大；

(3) 系统级FMECA迭代缓慢；

(4) 成品LRU级FMECA故障影响表述不当，系统FMECA分析时应对其补充，且根据影响程度重新确定严酷度，而实际上这部分工作存在脱节；

(5) 无统一的功能定义，故障影响描述模糊；

(6) 未将系统方案设计中测试性布置、测试能力配置、状态监控设计、故障定义等关键工作项纳入系统测试性设计范畴，测试性设计基本被缩减为测试性预计；

(7) 未系统地对系统功能和硬件的检测覆盖性进行分析和评估，并且故障隔离能力较弱。

图1 机载系统测试性设计主线与问题

2 测试性设计关键环节剖析

若要解决上述机载系统测试性设计流程中存在的问题，应重点研究系统测试性设计体系，对设计体系中的关键环节进行剖析，识别问题根源，并针对性地进行改进。本文提出的完整机载系统测试性设计体系如图2所示，其中，在机载系统测试性设计过程中容易被轻视、甚至被忽略的关键环节，包括系统级FMECA、故障定义、诊断能力设计、诊断结果显示与使用、测试性试验和使用与评估。

图2 机载系统测试性设计体系

2.1 系统级FMECA

机载系统和成品的FMECA是测试性设计的基础。FMECA的分析结果是对机载系统和成品的所有可能出现的功能和硬件故障及其对输出功能影响的认知。在此基础上，针对故障模式的特征设置测试硬件/传感器结合相应的软件，检测机载系统和成品的故障。

2.1.1 利用下层FMECA结果的方法

在进行系统级FMECA分析时，首先应该对成品厂提供的子系统/LRU级FMECA结果进行处理和完善，包括完善故障模式的影响，在系统级重新评定严酷度，综合考虑并更新外场检测方式，以及对定义不合理的故障模式进行修正，对故障模式进行裁剪与合并等。将处理的结果作为系统级FMECA的内容之一。在进行系统级FMECA分析时应对LRU级FMECA存在的问题进行修正，并以LRU对外输出功能为对象综合定义LRU的故障模式，本文总结LRU级FMECA常见的问题如下：

(1) 从底层硬件故障向上传递，缺乏LRU层对同一故障模式不同传递路径描述不同的故障模式进行综合或合并。

(2) LRU内部故障影响到LRU功能，应对最终影响到的功能输出进行故障模式定义，中间的传递过程无需定义为LRU级的故障模式，而应定义为故障原因。

(3) 故障模式定义模糊，不能以此判断对上一层的影响，应根据控制逻辑、定量性能要求区分故障影响程度，根据系统/产品能否识别或识别区间来分别进行故障模式描述。

(4) 检测方式不统一，对于人工检测应区分为外场人工/外场测试设备及内场测试设备，以此确定是否需定检任务。

(5) 使用补偿措施应重点对不可测的部分进行说明。

2.1.2 系统级FMECA应该具备的特征

目前，系统的FMECA只以LRU作为分析对象，甚至直接以系统组成的LRU作为分析对象，进行故障模式、影响分析，严重缺少站在系统的视角对系统功能层、LRU功能层的深入分析。本文提出系统级FMECA应对两个层次进行分析，分别是系统层和子系统/LRU层，如图3所示。

图3 系统级FMECA组成及关系

子系统/LRU级故障模式对上一层的功能影响，即为系统层的故障模式。在定义系统层的故障模式时应从系统输出功能的角度，综合考虑空中、地面工作模式和系统降级重构状态。故障模式的最终影响为对飞机安全和任务的影响。在定义LRU层的故障模式时，以成品厂传递的LRU级FMECA为基础，并从LRU输出的功能故障、性能下降的角度进行定义。故障模式的检测方式的与综合诊断策略密切相关，检测方式的设计要从避免预防性维修作业的角度去考虑，所有在外场能够通过原位检测而不拆卸设备发现故障的方法，都应纳入进来。对于不可原位检测的，根据严酷度等级和故障率等确定定检和寿命控制需求。

2.2 诊断能力设计

机载系统测试性设计的目的是检测系统功能状态，并将故障隔离到LRU级。

随着传感器技术、微处理技术的发展，系统采集并处理大量的飞行参数，机上故障检测能力也大幅提高，但由于技术能力、机上的空间、重量、带宽等资源限制，不可能做到所有功能和故障都检测。

因此，需要明确机载系统和设备的诊断能力要求，同时优化有限的检测资源，从提高系统功能覆盖和隔离能力的角度，进行诊断能力设计。诊断能力设计包含综合诊断方案、测试点布局方案、测试能力分配、系统和设备诊断能力要求、系统级/设备级BIT规划等工作项目[6-7]。诊断能力设计内容如图4所示。

图4 诊断能力设计

本文提出在制定综合诊断方案时，所有的原位检测方式都应该综合考虑，包括BIT、外场测试设备、外场人工检测、人工飞参判读等。原则上，设备检测硬件设计、测试点布局方案确定之后，系统的检测能力就已在客观上确定。系统测试点布局方案和设备自身诊断能力对系统的检测能力至关重要。

根据战斗机外场维护经验，机载系统应具备通过BIT检测所有关键功能故障并且通过原位检测的方式检测系统功能完整性的能力；系统的设备应具备输出能够反映自身工作状态的信号或自测试能力，对于无信号输出的设备，应确保其故障发生能够通过系统层进行检测。

目前，机载系统的故障诊断主要通过系统级BIT实现，完成状态监测、故障检测、故障隔离以及系统测试管理功能。系统级BIT对已认知故障进行检测，实现故障隔离有以下三种方式。

(1) 对功能通道输出末端设置检测传感器后，在功能通路上设置多个传感器，即能够检测通道上更小硬件范围内的故障；

(2) 设备自身具备BIT能力，向系统报告设备自身的故障状态；

(3) 检测单个设备的信号输出，系统BIT判读该设备的工作状态。

上述系统级BIT进行故障检测和隔离采用传统的基于规则判断的方式，其故障隔离是有针对性地对已认知并可隔离的故障进行BIT软件编程实现，没有从系统层面利用全系统诊断要素进行故障诊断，导致故障隔离能力明显不足。

在进行诊断能力设计的过程中，引入测试性建模的方法，能够方便、有效地实现系统测试点布局方案及其设备诊断能力的优化，能够快速地分析出当前方案下系统的故障检测与隔离能力[8-9]。

在诊断能力实现时，在系统层、设备层引入先进的综合诊断方法，在机载或地面进行实施，能够有效提高机上数据利用效率，提升故障诊断能力。

2.3 故障定义

在设计系统/设备BIT时须对系统故障进行定义。故障定义的范畴为通过外场原位检测的故障，对于不能通过外场原位检测发现的故障不做定义，纳入预防性维修和大修需求管理。机载系统的故障定义表现形式为系统工作单元故障代码或健康代码，并以此为依据在对BIT报出的故障进行定义。本文总结实际工程经验，飞机故障分为系统/设备功能故障、设备硬件故障和设备内部故障。功能故障定义以机载系统FMECA为基础，描述系统功能丧失、异常、降级状态。在系统层，对能够隔离到设备级的故障，在设备上报的BIT结果基础上进行综合，明确定义出故障的设备名称，对于能精确的到设备功能和下层硬件故障的，在设备名称基础上增加设备功能失效和下层硬件故障描述，下层硬件故障一般定义到SRU级。飞机故障定义及使用如图5所示。

图5 飞机故障定义及使用

其中，系统功能故障主要有以下五种类型：

(1) 单个控制功能通道失效，例如热路超温、座舱压力低；

(2) 多个控制功能通道失效组合，例如环控气冷关闭、28 V直流失效；

(3) 偏离预期状态的异常，例如座舱盖未到位、座舱盖前移超限；

(4) 系统功能、性能降级；

(5) 通讯失效，例如飞管电源控制盒1394通讯故障。

由于未指代故障源的系统功能故障将给排故带来较大困难，在实际工程实施中可以通过基于模型或基于案例等方法进行综合诊断，提高排故效率。

2.4 测试性设计结果与使用分析

机载系统测试性设计结果最主要表现为BIT所报出的故障、记录的飞行参数及其存储、显示方式。在飞机飞行中，通过BIT生成的告警、PFL清单等信息，提供给飞行员飞机各系统状态，支持飞行员进行任务评估。因此，向飞行员提供的告警、故障清单，必须能够反应影响飞行安全、重要任务设备的关键功能失效，同时应该提供反映系统功能降级的故障。

在飞机降落后，地勤人员需详细了解飞机状态，以确定飞机是否能再次出动，是否需要即时排故并快速确定故障件。对于飞机的快速再次出动判读，关键在于系统BIT报故能否检测覆盖机载系统关键功能失效和降级，对于不能通过BIT报故结果覆盖的关键功能应该有飞参判读或人工检查等补充措施，以保证机载系统关键功能的完整性。

目前，不论是飞参地面软件显示还是无人机地面站故障显示，对故障本身并未加以区分和分析，给排故造成麻烦。故障的显示应综合考虑故障间的隶属关系、关联关系和故障-硬件对应关系，根据使用对象的不同设计显示界面和内容。

2.4.1 故障隶属关系

同一系统内下级故障发生必然使上一级故障报故，这些故障指向同一个故障源，称这些故障具有隶属关系。导致故障间隶属关系的原因有：

(1) 系统BIT将设备上报的多个故障结果进行合并命名，多个故障中的任一个故障报故，将导致系统层故障同时报故；

(2) 告警和上报飞行员故障清单的需要，将系统BIT报告的多个故障合并命名；

(3) 告警和上报飞行员故障清单的需要，将系统BIT的报告的故障转换名称。

在进行系统的故障定义时，应该同步对故障间的隶属关系进行清理，对于飞行员和地勤人员放飞只需要能反映关键功能的上级故障，对于地勤人员的排故需要下级的与硬件相关联的故障。故障隶属关系示意图如图6所示。

图6 故障隶属关系示意图

2.4.2 从属故障

由另一产品故障引起的故障，称为从属故障，亦称诱发故障[10]。一个系统报故，引起功能通路上的系统内或其他系统报故，所导致的并发报故属于虚警。导致从属故障的情况如下：

(1) 综合处理计算机某个处理通道，承载多个系统的飞行参数处理与BIT结果判断，该计算机处理通道故障时，会导致所承载的所有系统相关BIT报故；

(2) 供电通道失效，导致相关的供电负载报故；

(3) 集中输入输出设备数据采集功能故障，使该设备采集的相关数据无输入，导致其他设备报故；

(4) 集中输入输出设备控制、功率输出功能故障，使该设备无法输出控制、功率信号，导致其他设备报故。

飞机的从属故障属于虚警，需要通过跨系统的判断逻辑进行消除。清理系统间的从属故障，通过机载或地面的跨系统判读逻辑，理清从属故障的报故逻辑关系，找出原发故障，对于减少地勤人员排故工作非常有必要。

2.4.3 显示界面和内容

机上有一套相对成熟的告警等级划分、故障显示、提示的要求和措施，本文只探讨地勤人员所需的故障判读显示界面。地勤人员既要查看表征系统功能完好性的故障，又要查看排故所需的具体硬件故障，同时需要辅助必要的飞行参数。因此，本文提出地面判读软件显示要素应包含以下七方面：

(1) 故障代码与名称。

(2) 故障间的关系，表明故障隶属关系，自动屏蔽从属故障。

(3) 故障类型，分为系统功能故障、设备硬件故障、设备内部故障。

(4) 故障发生次数，每次出现、消失和持续时间。

(5) 故障发生时飞机的基本状态，含轮载状态、发动机N2转速、高度、速度等。

(6) 故障所对应的故障件。对于无下层故障的系统功能故障，提示出该功能通道所涉及的硬件，按故障率、拆装难易程度、发生频次等排序；对于有下层硬件故障的系统功能故障，只提示设备硬件故障所对应的故障件；对于设备内部故障，提示出该故障对应的LRU级故障件，同时若有条件可提示SRU级故障件。

(7) 故障判断依据参数及逻辑，并提供确认虚警所关联的飞行参数的快速打开链接。

2.5 测试性试验

以往的飞机设计历程中，没有规划测试性试验，常规的台架试验、环境试验、可靠性试验和软件测评，更侧重于系统/设备正常的功能、逻辑和性能测试。甚至在进行系统/设备故障逻辑相关的软件开发测试时，只是对单个的软件逻辑分支进行测试，严重缺乏从整体角度，通过故障注入的方式系统性地对故障逻辑和BIT功能进行验证。使得系统和成品的故障检测能力与故障隔离能力的验证的环节，后移至试飞阶段，甚至是正式服役阶段，外场故障的发生存在随机性，而且飞行时间有限，测试性问题暴露很缓慢，导致测试性能力的验证周期极长，很大程度上限制了测试性改进和能力的提高。同时，由于飞行时间较短，样本量少，也导致飞机在鉴定或定型评估时，测试性指标往往不能达标，而且也缺乏足够的说服力来评价指标达标情况。测试性试验与其他研制试验的关系如图7所示。

图7 测试性试验与其他研制试验的关系

根据装备研制与使用过程的暴露出的问题，本文提出完整的测试性试验应包含机载系统级和成品级(含子系统和设备)试验。目前，成品级的测试性试验注入层级为功能电路和元器件级，其技术和方法相对成熟；系统级测试性试验注入层级主要为LRU级和SRU级，尚处于探索阶段。不同层级测试性试验对比如表1所示。

表1 不同层级测试性试验对比

2.5.1 成品测试性试验

成品的测试性试验作为一种对测试性设计结果的验证手段，针对自身具有BIT能力的成品，以FMECA分析结果作为基础和依据，选取故障样本，采用专门的故障注入设备进行故障注入，发现测试性设计问题，并根据试验统计结果评估故障检测率、故障隔离率指标[11-12]。

在成品研制阶段进行测试性试验是测试性设计工作的重要组成部分，能够促进测试性设计的改进、重视程度和设计水平的提高，对提高成品测试性能力具有重要意义。本文提出成品测试性试验应实现如下目的：

(1) 验证FMECA分析的正确性；

(2) 验证故障检测和故障隔离设计的有效性，并能够发现BIT硬件和软件设计缺陷；

(3) 能够评估成品故障检测率、隔离率指标；

(4) 验证产品功能检测能力，尤其是关键输出功能的检测能力；

(5) 测试产品故障后功能输出表征，尤其是Ⅰ、Ⅱ类故障模式的输出表征。

目前实施的成品级测试性试验能够实现前4项用途，而对于测试产品故障后的功能输出表征，尚未引起足够的重视。同时，成品测试性试验目前不能评估LRU的故障隔离率，因为在试验时，故障检测判据是成品向上位机报出的BIT结果，由于总线带宽的研制，这些BIT结果往往是经过综合后的较高层级的故障判读结果，因此，不能通过这些上报的颗粒度较粗的信息去评估LRU的故障隔离率。在进行成品测试性试验时，应同时关注设备底层的BIT结果和上报的高层级的BIT结果，同时纳入故障检测判据，在试验时进行验证，底层的BIT结果作为评估故障隔离率的依据[13]。

2.5.2 系统测试性试验

目前，从利用内场试验补充外场测试性评估数据的角度，笔者已经探索性地实施了某型无人机的系统测试性试验。系统测试性试验相对成品测试性试验，试验理论和方法是可共用的，但在实施时区别较大：

(1) 系统级FMECA分析水平尚有待提高；

(2) 系统级故障模式涉及大量机电设备，其故障注入较困难；

(3) 系统级测试性试验通常由主机所实施，而成品测试性试验为第三方试验单位实施；

(4) 系统级测试性试验故障注入级别一般为LRU层或SRU层，而成品测试性试验一般为功能电路层或元器件层；

(5) 系统级测试性试验一般在主机所的系统实验室进行，由于条件限制，对电子设备的故障注入级别一般为LRU层或SRU层，导致一些本可通过专业注入设备注入的故障在系统试验室无法注入；

(6) 对涉及机电类设备的系统功能控制通道进行故障注入时，需要使设备在特定运动状态下才能进行。

已实施的某型无人机系统测试性试验是在成品测试性试验技术积累的基础上实施的首例系统级测试性试验，是测试性试验技术在系统级应用领域的探索和延伸。试验过程中，发现了多起设计缺陷，总结了试验方法和经验，取得良好的效果，并且对其他有人机、无人机实施同类试验有重要的参考价值。试验表明，系统级测试性试验应在成品测试性试验实施基础之上，验证系统的测试性设计水平，主要内容有：

(1) 系统级BIT整体故障检测和隔离能力；

(2) 系统级BIT对Ⅰ、Ⅱ类故障的检测能力；

(3) 系统级BIT对功能控制通道的故障检测能力；

(4) 对于具备BIT能力，但部分故障不能通过自身BIT检测的设备，其故障需要系统级BIT进行检测，这部分检测能力需在系统级进行分析和验证；

(5) 对于不具备BIT能力但有信号输出，且其输出信号反映设备主要功能故障的设备，在系统级编制故障判断算法，实现对该设备的故障检测，其测试性能力需在系统级进行分析和验证；

(6) 对于不具备信号输出能力的设备，应结合其故障对系统功能通道影响的表征，验证系统级BIT、外场测试设备、外场人工检测手段对该类设备的原位检测能力。

2.6 测试性指标评估

在飞机设计鉴定或设计定型时，需评估系统和成品的测试性定量指标，作为设计鉴定或定型的依据。由于目前的飞机型号在系统和成品的设计阶段普遍缺乏验证环节，不能将测试性设计缺陷在设计阶段发现并解决，且系统和成品的测试性指标预计存在很大的缺陷，不能真实反映系统和成品实际的测试性能力，导致在试飞和使用初期测试性定量指标往往不能达标。通过外场试飞的方式验证测试性能力，本身又存在故障不能充分暴露、验证周期长等问题，使得测试性能力提高缓慢。同时，现行的测试性指标评估缺乏专门的标准，导致在评估过程中存在如下问题[14-16]：

(1) 评估方法只关注定量指标是否达标，而没有站在装备使用效能评估的角度去整体评价；

(2) 测试性评估数据与可靠性评估数据不同源；

(3) 测试性评估最少样本数量的要求依据的是GJB2072-94《维修性试验与评定》，严重不满足测试性指标评估的要求，也不符合测试性能力随装备使用时间增长而提高的现状，导致小样本情况下的评估结果与飞机真实测试性水平存在较大偏差；

(4) 故障认定没有统一原则；

(5) 测试性评估故障样本的认定没有统一原则。

本文提出测试性指标评估的对象应为设计鉴定或定型状态的整机、发动机、机载系统和设备。测试性指标评估的目标值为用户提出的测试性定量要求，因此，测试性指标评估和测试性定量要求的目标导向，应从飞机使用的角度来综合评价测试性设计水平，关注飞机在使用时，测试能力是否能让飞机满足使用需求，并形成完整的要求体系。具体表现为BIT检测关键功能的能力，BIT的故障检测和隔离能力，BIT难以设计或设计代价大的检测对象采用原位检测方式(如外场测试设备、目视、外场人工检查等)的检测能力，以及不可原位检测的故障是否经过充分的分析并根据影响程度提高可靠性设计或规划预防性维修作为使用补充措施。

3 改进建议

造成机载系统和设备的测试能力欠缺的结果，既有技术因素，也有专业定位、工作方式、职责划分与制度保障等因素。

3.1 工作方法的改变

飞机测试性工作是相对孤立的。表现为专业职责划分、测试性工作与系统设计工作的工作界面等方面。

从测试性专业与机载系统专业的分工来看，测试性专业负责全机测试性设计的顶层规划，机载系统负责具体的实施。在飞机研制过程中，测试性专业与机载系统专业围绕各自的分工开展承担的工作，主要在机载系统、成品的报告和成品技术协议审签时测试性专业才参与了机载系统的测试性工作，其他环节几乎不参与。因此，总体来看，测试性专业与机载系统专业的工作是相对孤立的。

从测试性专业内部分工来看，测试性专业人员审查机载系统相关工作结果时，机载系统FMECA审查与测试性工作结果审查，全机故障定义与飞参定义，外场故障问题处理，这些任务都由不同人完成，各自例行公事，以完成任务为导向，可靠性专业人员与测试性专业人员相对孤立，测试性各项工作相对孤立。

从机载系统专业分工来看，机载系统专业内有负责系统级方案设计的专家承担了传感器布置、状态监控方案、BIT方案和设备测试性要求等规划，这些测试性相关的设计工作纳入了系统方案设计的过程中。然而，FMECA分析、测试性设计报告等专门文件则往往由系统其他人员编制，同样的例行公事，真正的测试性设计与结果相对孤立，机载系统的FMECA分析与测试性分析相对孤立。

造成测试性工作的孤立状态，有人员的专业素养的问题，但更多的是观念和工作方式的问题。要突破这个困境，本文提出应从如下三方面入手：

(1) 应加强测试性专业人员、机载系统设计人员测试性相关知识和技能的培训，加深人员对测试性工作的认知；

(2) 建立、健全系统测试性设计技术体系和设计流程，才能将测试性设计融入到系统设计中去，使系统设计人员的对测试性的认知，从写报告即完成测试性工作转变为将系统测试性能力作为一项技术指标的设计思维；

(3) 应在专业内赋予专门人员作为测试性总体负责人，从面向使用的角度，统一协调管理测试性相关工作，同时，将分布在各个机载系统的飞机的测试能力视为一个整体，并将其当作类似机载系统进行设计与管理，把测试性工作当成系统设计工作来抓。从而，将孤立的工作作业，形成有机结合的测试性系统工程。

3.2 专业定位的转变

目前，测试性专业作为飞机测试性总体性专业，负责型号测试性顶层文件、要求、指南的编制与发布，指导机载系统和设备的测试性设计工作，会签机载系统测试性相关报告，汇总机载系统飞行参数，以及抓总测试性试验和测试性评估协调。机载系统专业负责具体的系统测试性设计和机载设备测试性要求制定与审核，是飞机测试性设计实现水平高低的关键之一。同时，地面设备专业负责飞机地面判读软件的设计，该软件是否满足外场使用需求也是体现飞机测试性设计水平的关键之一。从当前的专业组织划分来看，职责较为清晰。但再好的组织都需要人来执行，只有明晰人员权利和责任，才能发挥出应有的效能。从权利与责任的角度来看，当前的责任划分并不合理。机载系统和设备的测试性设计由机载系统专业和成品厂家具体实施，而在测试性评审和测试性评估阶段，所表现出的测试能力较差的后果，则往往会归结为测试性专业的工作没有做好，这更造成测试性专业及人员的弱势。因此，通常说的四性设计“两张皮”，其内涵不仅包括在设计阶段四性专业人员与机载系统专业人员在工作配合上的不协调，也包括在承担设计责任上与相应职责的不匹配。

从专业分工的角度来看待，测试性专业应该作为全机测试性设计的主要责任单位，牵头设计全机测试性能力，从机载系统方案制定之初的关键阶段开始，共同进行系统FMECA分析，并共同制定机载系统综合诊断方案、系统监控方案、故障隔离方案和设备测试性要求，采取内部评审的方式，组织专家对机载系统测试性设计方案进行审核。这样才能将综合诊断方案、测试点布局方案、状态监控方案、故障隔离方案、设备测试性要求这些测试性设计关键项目纳入测试性设计范畴，从而将测试性能力要求贯彻到系统设计过程中，而不是将测试性工作仅局限于写测试性相关报告。

由于飞机的测试能力直接影响到用户使用体验，测试性设计贯穿设计和使用全过程，因此，在机载系统设计过程中，测试性专业应该定位于全机测试系统总体，对全机、机载系统和设备的测试能力进行统一规划。

3.3 职责与制度保障

基于目前测试性设计认识水平和技术能力，实现测试性设计水平的提高应经历两个阶段：

(1) 指令性工作分配阶段，测试性专业人员与机载系统专业人员共同分析与设计；

(2) 原则性工作分配阶段，机载系统专业人员自然而然地在系统设计过程中贯彻测试性设计思想。

3.3.1 测试性设计工作接口

机载系统测试性设计的结果包括综合诊断方案、测试点布局方案、检测能力配置、地面检测设备规划、故障诊断策略、BIT设计、故障与参数定义、告警与显示策略等。设计结果的载体包括设计与分析报告、测试性模型、BIT软硬件、参数判断软硬件、排故手册等。本文总结机载系统测试性设计的接口如图8所示。

图8 测试性设计工作接口

3.3.2 测试性工作职责

测试性总体与机载系统测试性设计密切相关，要实现将测试性设计融入系统设计中，也需加强这两方面的配合程度，具体应从人员职责和制度两方面来作出改进。在系统设计中，测试性设计应纳入“四性”工作统一规划和管理。

在人员方面，“四性”专业作为总体性专业，每个型号应该指定专人作为型号“四性”设计主管，对型号“四性”设计结果负责，其主要设计职责为：

(1) 统一进行型号“四性”总体要求管理；

(2) 总体协调专业内有输入输出关系的各项工作；

(3) 参与系统诊断方案设计；

(4) 组织协调机载系统“四性”工作；

(5) 组织审查机载系统“四性”工作结果；

(6) 型号“四性”设计工作总结。

机载系统专业，是型号“四性”工作的具体实施者，是“四性”要求实现的关键要素。机载系统专业同样应制定专人作为机载系统“四性”设计主管，对机载系统“四性”设计结果负责，而且应同样是参与系统级设计的人员，其主要设计职责为：

(1) 统一进行机载系统和成品“四性”要求管理；

(2) 总体协调系统内“四性”工作的衔接与数据接口关系；

(3) 配合各阶段四性专业组织的“四性”设计工作审查，并积极改进。

3.3.3 测试性设计制度保障

在制度保证方面，要保证“四性”专业人员参与到系统测试方案的关键设计环节，并对设计结果有效监督。主要措施如下：

(1) 共同设计，机载系统的综合诊断方案、测试点布局方案、参数定义、BIT判断逻辑设计等关键设计环节，由测试性人员与机载系统专业人员共同配合完成，其结果纳入系统设计方案；

(2) 内部审查，在机载系统测试性方案确定后组织内部专家进行审查，并督促改进。

在形成较稳定的人员队伍和长效的工作制度后，机载系统的测试性设计人员能够对测试性设计要求、技术和流程能够有深刻的理解，并具备较丰富的经验，深入体会系统测试能力对飞机使用带来的便利，将逐渐形成自发的工作习惯，在系统设计时，自然而然地考虑测试性的设计要求，将测试性设计融入到系统设计中，从而提升系统的整体能力。

4 结束语

本文结合飞机实际使用需求，总结机载系统测试性设计中存在的问题，提出了一套贴合使用需求的机载系统测试性设计体系，并对其中的关键设计环节进行了剖析。

军用飞机使用过程中表现出诊断能力弱的根本原因是机载系统测试性设计各项设计工作是相对孤立的，通过构建机载系统设计体系，能够形成完整的需求、目标、设计、验证的研制框架，从而提升装备测试性水平；通过机载系统测试性设计体系的建立，结合工作方法、专业定位和制度保障的改进，能够将“写报告即完成工作任务”的传统思维转变为将全机测试性能力作为整体的总体设计思维，促使测试性设计融入机载系统设计过程中，最大程度地解决测试性系统工程中存在的“四性”与设计“两张皮”的问题，提高装备测试与诊断能力。