机载显控设备测试性设计

刘 江

(中国西南电子技术研究所，成都 610036)

0 引言

测试性是指产品自身能否准确、及时地确定其自身工作状态(可工作、不可工作或性能下降)并隔离出内部故障的一种设计特性[1]。测试性作为机载航空电子设备基本设计特性，产品自身测试性设计的好坏直接决定了该设备感知自身工作状态(正常、故障和降级)并自动隔离出内部故障点的能力[2]。随着航空技术以及电子技术的发展，机载航空电子设备向数字化、自动化、综合化、智能化的方向在快速发展[3]。近年来，测试性设计方式、方法随着用户的要求发生了变化。以往产品的测试性设计理念越来越难以满足用户对现代机载航空电子设备测试性设计的要求[4]。

在飞机交付使用后，机载设备一旦出现故障，能不能快速、正确地检测、隔离出故障从而快速修复，有赖于完善的测试性设计[5]。采用科学、合理的测试性设计方法，通过在产品测试、生产、使用等过程中增加监测手段，对设备内部的工作状态进行自动检测，对故障点进行自动诊断和隔离，可以提高武器装备的故障检测率，有效地提升战备完好性和战时利用率，同时降低维修人力和其它资源的要求，进一步达到精简保障内容的最终目的[6]。

产品的测试性设计通常是指在产品内部嵌入式BIT设计和固有测试性设计[7]。BIT检测主要是设备对自身进行系统BIT检测和故障点隔离，这是作为测试性检测的主要手段。产品的故障检测设计，必须要考虑经费、技术难度、体积及重量等各种综合要素，一般BIT检测率难以达到90%以上的水平，也就是说，至少还有10%的概率要依靠人工辅助检测进行故障检测[8]。人工检测主要是依靠人工介入对设备进行操作或者观察，使设备的故障点暴露出来。因此，发展人工智能辅助监测和故障综合诊断技术是目前开展BIT检测改进、降低故障虚警率的重要途径，也是国内外重点研究领域[9]。测试性设计这一研究领域，将来的研究重点将会向综合性测试诊断方面倾斜[10]。

机载显控设备，作为飞行员与飞机间的人机接口重要设备，负责将飞行员对飞机的相关操作转换为控制数据送至相应设备，并回显交联设备状态参数供飞行员参考。显控设备作为机载设备的终端，在测试性设计与实现方面既有劣势也有优势。

测试性设计所考虑的问题是在设备设计功能的一开始就要把设备的测试性设计一并考虑在内[11]。本文针对显控设备自身固有特性，充分利用BIT检测、人工辅助检测相结合的方式开展测试性设计，有效提高机载显控设备的故障检测率，满足了用户要求。本文测试性设计主要针对故障检测率指标开展，限于篇幅未对故障隔离率设计进行表述。

1 显控设备测试性需求分析

某型机载显控设备，用户要求设备故障检测率≥90%。显控设备的硬件构架，主要由电源模块、I/O模块、CPU模块、键盘、液晶显示屏等硬件模块组成，如图1所示。

图1 某型显控设备模块组成

根据产品的硬件组成以及产品特点可以看出，机载显控设备属于座舱内的人机交互产品，与其他机载电子设备的“黑匣子”工作方式有较大差异性。显控设备的人机交换部件，如液晶显示屏以及键盘，作为设备的末端，直接与人进行信息交互。

根据用户设备故障检测率≥90%要求，在人工不介入操作的情况下，单纯依靠检测电路进行BIT检测，需要引入大量第三方检测电路。如对显示屏的末端显示质量进行回环检测，需要在第三方检测电路增加独立摄像头采集图像，并增加处理器对图象进行算法处理分析，测算出显示屏的显示质量，以判定其是否工作正常。由此引入的开发成本、技术设计难度也极大增加。机载电子设备第三方BIT检测电路本身也会发生故障和虚警，从而降低整个设备的基本可靠性[12]。从大量应用中得出结论，常规BIT检测虽然在提高武器效能方面起着积极作用，但是由于第三方检测电路设计不够完善、成本投入等方面的限制，在产品设计好投入实际使用后，容易出现一系列问题，如实际检测和诊断能力差、故障虚警率较高等问题[13]。因此，在做设备故障检测设计时，我们应当把测试性整体放到首位，并从实际可操作性和长期维修费用的基本观点出发，在机内BIT检测与机外人工辅助检测之间作综合权衡设计[14]。

通过对显控设备的功能组成特征进行分析，产品具有天然的固有测试性特征：

1)产品提供全彩色高分辨率液晶显示窗口可以直接指示产品的工作状态；

2)产品控制键盘上的控制要素(发光部件、操控部件)工作状态直观呈现给使用维护者；

3)产品对外提供多通道HB6096总线接口，支持BIT检测结果上报。

通过制定测试性设计准则，有效结合BIT检测与人工检测方式，完成对设备测试点的总体布局，具体设计准则如下：

1)收集产品设计FMECA数据，开展显控设备测试性建模，并根据模型进行故障检测率数据分析，寻找设备测试性设计薄弱点；

2)针对有处理器的CPU模块、I/O模块、液晶显示屏(电路部分)，重点开展BIT测试性覆盖；

3)针对有人工交互的接触部件，如液晶显示屏、键盘等，重点开展人工辅助检测设计，通过设置自检及维护操作页面，人工辅助检测设备内模块的健康状况并将结果显示在液晶显示屏上或上报中央维护系统；

4)迭代测试性模型，得到完善设计后的测试性指标并与用户设计要求进行对比，如不满足要求进一步改进设计。

2 显控设备测试性设计

2.1 BIT测试性设计

2.1.1 整机BIT测试性设计

显控设备整机BIT测试性架构见图2，设计架构描述如下：

图2 显控设备整机BIT测试性架构设计

1)CPU模块是整机的BIT维护中心；

2)CPU模块通过机内总线控制管理I/O模块，启动I/O模块进入总线收发内部闭环检测；

3)CPU模块通过通信串口，启动液晶显示屏自检，并接受液晶显示屏回传的自检结果；

4)所有的检测结果通过视频信号发送到液晶显示屏上显示。

2.1.2 模块级BIT测试性设计

1)CPU模块BIT测试性设计:

CPU模块的ARM处理器、NVRAM、SDRAM和FLASH器件是保证整个设备操作系统正常运行的必要器件。

根据产品的设计要求，当产品完成测试性检测后，须将检测结果按照用户的软件接口协议要求，通过HB6096总线发送到中央维护系统。若单纯依靠第三方BIT检测电路，必然需要额外增加设计一套CPU最小系统电路才能满足用户要求的总线接口设计。按此设计，产品的设计成本以及电路复杂度将大幅增加，且引入大量第三方检测电路后，产品自身的可靠性指标必然降低，同时产品的虚警率也将上升。因此，BIT设计方案，需要适当地控制第三方测试电路以及元器件的规模，尽可能的采用设备自身的功能硬件、软件来实现，减少专用硬件的设计比例[15]。在提高故障检测率的同时，也要防止引入BIT测试电路导致的虚警问题[16]。

通过对设备整机的设计构架综合评估，可以充分利用产品自身的功能特点，即把ARM处理器作为整个设备检测核心器件，默认处理器工作正常，当处理器自身故障时整个设备直接为故障状态。NVRAM、SDRAM和FLASH器件直接挂接在处理器总线上，故障检测流程如图3所示。

图3 CPU模块BIT检测流程

CPU模块BIT检测设计流程说明如下：

(1)各个功能单元的故障检测结果存储在全局变量BIT_FLAG中；

(2)BIT开始执行后，首先将BIT_FLAG变量清零；

(3)依次执行SDRAM、FLASH、NVRAM、以太网接口及时钟的检测；

(4)若某个硬件单元出现故障，则将BIT_FLAG中对应的位置“1”；若功能正常则BIT_FLAG置为“0”；

(5)完成后自动进入下一个硬件单元的检测。各功能单元检测完成后，将BIT_FLAG的值作为故障判据返回给上层应用软件使用。

2)I/O模块BIT测试性设计：

由于设备对外HB6096 总线协议以及RS422协议均在I/O模块FPGA内部采用IP-CORE方式实现。可通过在FPGA内对各个HB6096总线接收、发送通道，RS422总线接收、发送通道预置寄存器控制指令，当需要进行BIT检测时，将各个总线通道进行闭环检测，并最后输出检测结果上报CPU模块，最终在液晶显示屏显示检测结果。

3)液晶显示屏BIT测试性设计：

利用液晶显示屏与CPU模块之间的RS232串口，实现液晶显示屏的检测控制指令下发以及检测结果回传。液晶显示屏接收到用户主机CPU模块发来的启动自检命令后，进行自检，并向用户主机回传自检结果，检测内容详见表1。

表1 液晶显示屏自检结果状态位

2.2 人工检测设计

2.2.1 不能BIT检测模式分类

通过对显控整机FMECA数据整理以及建模分析结果，得到其不能实现BIT检测，故障危害度为Ⅰ级和Ⅱ级的故障模式，主要分为2大类：

1)键盘按键功能故障，包含以下故障模式：

(1)按键信号连接故障；

(2)按键供电电路故障。

2)液晶屏显示故障，包含以下故障模式：

(1)液晶显示屏供电连接故障；

(2)液晶屏视频处理单元输出视频信号异常；

(3)液晶屏末端显示板工作异常；

(4)液晶屏玻璃损坏。

该两类故障模式均为人机交互类故障。通过对现有设备构架进行分析，可以借助人工检测实现以上故障模式的测试性覆盖。

2.2.2 人工检测启动设计

通过在CMS(中央维护系统)增加对显控设备人工检测启动指令，实现对显控设备键盘、液晶显示屏的测试性覆盖，启动自检流程如图4所示。

图4 启动显控自检流程

启动显控自检流程说明如下：

1)CMS通过HB6096总线向显控设备发送人工检测指令；

2)显控设备响应指令后自动进入人工辅助测试工作模式；

3)显控CPU处理器根据设计程序分别进行键盘按键、液晶显示屏等不能实现BIT检测的故障模式，通过人工介入辅助检测确定是否有故障点；

4)将检测结果在液晶屏显示的同时通过HB6096总线上报CMS系统进行记录。

2.2.3 人工检测流程设计

显控设备通过设计测试维护显示界面以及交互操作响应，以覆盖2.2.1章节不能实现BIT检测的故障模式，人工检测流程设计如图5所示。

图5 人工检测流程

人工检测流程说明如下：

1)在产品进入人工检测模式后，通过键盘提示灯以1 Hz频率的闪烁，提示设备人工辅助检测开始；

2)液晶显示屏设计维护界面，通过人工对液晶显示屏的显示质量进行观察、确认；

3)为避免设备自身液晶屏黑屏的故障模式时不能目视检测的弊端，软件设计时默认5 s未收到人工对液晶显示质量良好的确认数据，CPU模块自动向CMS上报液晶显示屏故障；

4)在液晶显示检测正常后，键盘提示灯以10 Hz频率闪烁，提示设备进入键盘检测模式；

5)在键盘按键维护界面，通过显示屏提示人工对键盘每个按键进行按击、确认；

6)为避免设备自身按键失效不能手动确认按键结果的故障模式，软件设计默认每个按键3 s未收到人工按键良好确认，CPU模块自动向CMS上报键盘模块故障。

2.2.4 人工检测模块实现

人工检测功能主要由CPU模块软件实现。CPU模块接收到CMS系统测试指令后，进入维护模式。

1)液晶显示屏显示故障检测流程如图6所示；

图6 液晶显示屏显示故障检测流程

2)键盘按键故障检测流程如图7所示。

图7 键盘按键故障检测流程

通过人工辅助检测的方式，以较小的代价即可检测出显控产品除BIT故障检测方式覆盖外，设备末端部件液晶屏显示质量及按键操作响应等故障模式。

2.3 故障隔离与虚警

CPU模块是整机测试性中央枢纽。当设备内其他模块或对外交联总线未按时上报CPU模块自检结果或者CPU模块未成功接收对方自检信息，默认采用“主对从错”的判断机制，即默认CPU模块为正常，交联对方为故障状态，以此隔离故障模糊组。

整机检测内部模块故障以及对外总线故障，采用了多次重传机制，当主控CPU检测到某内部模块或某总线通道故障时，先记录此故障状态，随后重复三次检测对方均为故障，才判定此故障为真值，以此避免虚警的产生。

3 测试性建模与分析结果系统软件设计

测试性建模是作为设备测试性分析与评价的一种有效方法[17]。测试性模型是设备组成或故障模式与测试点之间相关逻辑关系的表达示意图，主要用来说明故障点与测试点之间的逻辑关系以及对测试资源的占用关系[18]。通过测试性模型描述整个设备的测试性方案，在此基础上由仿真分析可得到设备测试性方案能否满足用户要求的测试性指标[19]。

根据设备的FMECA数据，通过对设备的各个模块及模块间的功能以及相关性分析，可以建立出设备的故障测试模型[20]。本项目采用北京联合信标公司“TADS测试性建模与分析软件”对某型机载显控设备RTU建立测试性模型如图8所示。

图8 某型显控设备RTU测试性建模部分截图

图8中，RTU设备测试性建模流程说明如下：

1)按照建模软件要求，根据RTU设备的具体功能，在设备左侧的各个输入端口标明流入设备端信号的特征，在设备右侧的各个输出端口标明流出设备端信号的特征，包括信号类型、流入或流出属性等；

2)构建设备SRU级模块组成关系，标明各模块输入输出接口，按照设计信号流关系连接各模块接口；

3)通过模块之间的信号交联传输关系，可以得到整个设备的信号传递路径以及信号转换关系；

4)从FMECA分析得到各模块的故障模式及故障模式失效率数据，将模块所有导入的故障模式与相关输入输出建立关联，并定义这些故障模式影响的输出信号；

5)在模块间或模块内部，根据具体的故障模式以及产品故障检测设计，合理设置故障检测点，标明测试行为及检测的具体信号(注：图8中因故障检测点均在各个模块内部，在图中未能显示出故障检测点标记)；

6)运行整个模型，开展建模分析，得到故障检测率结果。

通过测试性仿真建模，得到某型机载显控设备故障检测率结果如表2所示。

表2 测试性分析表格

4 结束语

通过测试性设计及建模分析结果，可以看出某型机载显控设备在不借助人工介入辅助检测的情况下，单纯依靠BIT检测测试性覆盖不够，产品故障检测率指标较低只有74.72%；通过开展人工辅助检测设计，可以检测出其余18.54%的故障模式。因此，将BIT检测设计与人工辅助检测设计相结合，整机故障检测率可提高到93.26%，满足用户故障检测率≥90%的指标要求。

本研究为机载人机交互类设备测试性设计提供了参考，如航电显示终端、音频控制单元等机载设备。通过人工检测设计与BIT检测设计合理结合，以较小的代价有效提高了设备故障检测率。