航电系统并行检测过程与检测设备解耦方法

刘艳芳，吕江花,*，马世龙，黎涛

1.北京航空航天大学 计算机学院，北京 100083 2.北京航空航天大学 软件开发环境国家重点实验室，北京 100083

航空电子系统(简称航电系统)是飞机为完成正常的飞行任务或其他特定任务(如预警、气象探测、通信导航识别等)而设计的电子系统[1]。随着航电系统逐渐向数字化、综合化和模块化方向发展，系统中越来越多的硬件功能被软件实现所取代，航电系统正逐渐向软件密集型系统演变[2-4]。从系统结构来说，航电系统是典型的大型复杂分布式系统，由多个分系统组成，各分系统又由多个部署在不同计算机上的计算机软件配置项(Computer Software Configuration Item，CSCI)，是指满足最终使用功能的可进行单独配置管理的软件集合)组成。在研制过程中，系统以软件配置项的形式被外包提供，并最终通过集成各软件配置项形成整个系统。这些软件配置项在使用或升级改造过程中难免会出现因系统软件配置项的相关安装文件、执行文件等被篡改或者软件配置项更新时版本号与版本不匹配引起软件配置项不一致和不完整的问题。这些问题都将使得航电系统相应软件配置项无法正常运行，最终导致系统运行出现问题。

另一方面，航电系统软件安全可靠运行需要适配的软件运行环境资源支撑。根据文献[4]，当前典型的综合模块化航电(Integrated Modular Avionics,IMA)系统体系结构自顶向下可抽象为应用软件层(即航电系统应用软件或软件配置项)、操作系统层、模块支持层和硬件资源层共4层。其中，下面3层(即操作系统层、模块支持层和硬件资源层)共同为应用软件层提供服务支撑，被称为航电系统的软件运行环境。航电系统的软件运行环境为航电系统运行提供各类资源，如操作系统API(Application Program Interface)、内存、CPU、存储空间等。由于航电系统是安全攸关系统，其运行环境的适配性对航电系统安全可靠运行至关重要。

因此，需要对航电系统的软件配置项一致性和软件运行环境适配性进行检测以保证航电系统运行的正确性和可靠性。检测不同于测试，测试侧重于对被测系统功能和性能方面的评估和验证，而检测是对被测系统的健康性检测，是对经测试后的被测系统做进一步验证。检测又分为静态检测和动态检测，其中，动态检测是在航电系统运行时通过采集运行时相关数据进行分析。静态检测则是在航电系统非运行时，对系统(从配置级)进行检测以保证航电系统能正常启动和运行。因此，静态检测是航电系统正确运行的前提保证。本文主要考虑航电系统的静态检测问题。

在当前批量航电系统大量投入使用的背景下，采用自动化检测技术[5-7]已成为这类复杂系统检测的必然趋势。自动化检测过程一般是检测任务发送检测指令给检测设备，检测设备根据检测指令对被测系统执行检测并从被测系统获取所需要的检测数据，然后发送给检测任务进行分析和研判的过程。对于航电系统来说，当前检测面临的问题具体表现为：① 检测过程与检测设备之间耦合，检测设备与被测航电系统之间耦合，检测人员需为每个被测系统配置专用的检测设备，并需要给新配置的检测设备编写驱动程序，检测通用性和易用性受限；② 检测安全性要求高，内置检测软件受限，检测过程中不允许出现对系统的任何更改、驻留和泄露等行为；③ 检测任务繁重，检测周期短，检测频率高，检测人员需要在较短的时间内完成对多个航电系统的检测工作，例如起飞前、降落后都需要进行频繁的日常检测。其中，问题①的解决有助于问题②的解决，也有助于推动问题③的解决。因此，本文聚焦于问题①的解决。

设备协同是检测过程与检测设备解耦的有效方法。特别是当前计算机技术高速发展，航电系统检测逐渐由单机检测模式转变为多被测系统并行检测模式，检测系统需要具有通用性，即独立于具体检测数据、具体被测系统和具体检测设备，这就要求检测系统能够支持各种被测系统和检测设备的动态加入和退出，同时能够动态协同各检测设备对被测系统进行并行检测，因此，检测设备协同的动态性和开放性是航电系统并行检测中检测过程与具体检测设备解耦合的关键问题。

基于上述问题，本文在自动化检测语言[8]的基础上，提出一种航电系统并行检测分层框架，支持检测设备与被测系统解耦合，以提高检测系统的通用性。通过这种分层框架也保证了检测过程的安全性。在此基础上，定义检测设备协同机制，解决检测过程与检测设备耦合的问题，从而支持多个航电系统并行检测。最后通过实际案例应用和实验对比验证本文所提方法的有效性。

1 相关工作

目前，针对航电系统的检测技术主要有自动测试系统(Automatic Test System，ATS)、机内自检(Built-in Test，BIT)、预测与健康管理(Prognostics and Health Management，PHM)等。其中，ATS通过测试系统主任务计算机控制自动地完成各种模式的激励、相应信号的采集、存储和分析，进而实现被测单元(Unit Under Test，UUT)状态的自动监控、性能的自动测试和故障的自动诊断。到目前为止，ATS的发展共经历了专用设备、模块化设计和通用标准化3个阶段，应用领域也正在由最初的海、陆、空军专用向各军通用和军民通用发展。特别是，在下一代ATS(即NxTest)计划被提出之后，自动测试系统的研制都以NxTest计划中的各种规范为参考正在从接口和总线等硬件通用逐渐向软硬件通用发展。在通用自动测试系统发展中，国外尤以美国和法国为代表的自动测试系统技术上最为成熟，如美国洛克希德·马丁公司研制的加固型自动支持系统(Consolidated Automated Support System,CASS)，法国宇航公司推出的ATEC6系列通用测试平台和SESAR3000系列通用测试平台。中国也有一些自主研制的ATS，例如可视化测试程序集成环境软件GTest、自动测试系统软件平台TestCenter等，主要用于自动化测试。在自动化检测方面成果较少，更多的是采用BIT或者PHM技术进行分析和预测。

BIT技术是为了提高检测效率在系统内部设计了硬、软件或利用本身部分功能部件完成对其自身的故障检测、故障定位(对于单一的外场可换单元)、错误诊断等[9]。从20世纪70年代常规BIT被首次提出后，BIT技术的发展又经历了基于人工智能的BIT和针对功能板级、分系统级和系统级的分级BIT两个阶段。PHM技术是对BIT技术和状态(健康)监控能力的进一步拓展，包括“预测”和“健康管理”两个部分，其中预测是根据现在或历史状态记录预测性地诊断部件或系统完成其功能的状态；健康管理是根据诊断/预测信息、可用资源和使用需求对维修活动作出适当决策[10]。目前，这两种技术已被广泛应用于航电系统自动化检测中，但在实际应用中他们存在各自的不足。如BIT技术是内嵌在被测系统内部的，理论上其规模一般被要求不能超过被测系统的10%[11]，工程实践中有所放宽，但一般也不超过20%[12]，这在一定程度上限制其功能，另外，也存在测试和诊断能力差、虚警率较高等问题。PHM则由于数据获取困难，其虚警率一直达不到理想状态，PHM也存在开发周期长、成本高等不足。也正因此，当前对BIT技术和PHM技术的研究以提高其检测和诊断准确率作为发展重点。

近几年本文作者所在研究团队一直致力于航电系统自动化检测方面工作并取得了初步的研究成果[13]，研制了针对单机环境下的自动化检测系统[14]，并已列装。在新的武器装备发展形势下，需要研制分布式自动化检测系统，能够支持对不同型号飞机的航电系统进行并行检测，提高检测效率。在这种情况下，检测系统需要能够独立于具体检测设备，检测设备与具体被测系统之间也需要解耦合。

在设备解耦方面，雷婉琦[15]将每类仪器设备的调用流程封装为DLL并采用虚拟仪器软件结构(Virtual Instrument Software Architecture,VISA)标准调用各仪器设备的DLL，可解决测试系统与主流仪器设备之间的耦合问题，缺乏对专用但非主流仪器设备的调用，另外也无法支持对仪器设备的动态协同。Helms和Tacha[16]将测试系统分层并抽象得到测试设备调用层，通过在测试设备调用层提出一种用户灵活自定义和裁剪策略解决测试系统和陈旧测试设备之间的耦合问题。另有一些研究采用设备协同的方法解决设备耦合问题。比如，Mcmullen和Reichherzer提出一种基于本体的统一设备模型[17]，采用本体抽象描述不同类型设备，与具体设备类型解耦，但是缺乏对设备能力的描述。在信息设备资源共享协同服务(Intelligent Grouping and Resource Sharing,IGRS)标准[18]中，将每种设备根据其拥有的共享资源被抽象为一个IGRS设备类型，各IGRS设备通过通用的IGRS设备交互协议实现设备间协同交互，解决了应用和资源与具体设备类型耦合的问题，但缺乏对设备的统一描述。Hamadache和Lancieri提出一种适用于计算机支持的协同工作(Computer Supported Cooperative Work,CSCW)系统的协同模型[19-20]，将设备看作资源，通过设备在协同工作中可扮演的角色及其能力抽象描述不同类型设备资源，并给出设备协同规则，但缺乏对设备交互能力的描述。在设备协同建模语言方面，典型的有WS-BPEL[21]、YAWL[22]、BPMN[23]等，但大多是将设备服务封装为Web服务，通过扩展已有工作流建模语言实现设备协同，缺乏对设备操作和设备协同执行机制的描述，故难以实现设备间的直接协同，基于这类设备协同建模语言的应用系统与设备间的耦合度高、灵活性和开放性差。本文作者所在研究团队通过总结现有设备协同系统及其关键技术，针对大规模设备协同应用的特点，提出了适用于大规模设备协同应用领域的流程建模语言[24]，通过抽象设备操作和定义设备操作的解释执行机制实现设备协同过程的自动化[25]，研制了航天器自动化测试系统[26]。然而，面向航天器自动化测试的设备协同语句并不能直接应用于航电系统自动化检测。一方面，因为航电系统与航天器本身不同，航天器主要由电子元器件和硬件设备构成，而航电系统逐渐向软件密集型系统发展；另一方面，执行的任务不同，航天器测试是面向系统或组成部件功能和性能的测试，而本文中航电系统检测是对系统的健康性检测。这些使得其检测模式不同，对应的设备协同机制不同，检测安全性需求也不完全一样。

2 检测系统框架

航电系统是典型的安全攸关系统，因其检测安全性要求高，对航电系统(特别是投入使用的航电系统)进行检测一般需要借助外置检测设备通过其指定接口进行检测。为此，本文在不影响被测系统正常运行的情况下部署检测跳转机(以下简称跳转机)作为外置检测设备。一方面，为检测任务端访问被测系统提供安全访问接口，对被测系统子网上的任何设备进行检测都必须通过跳转机操作子网上被测主机完成；另一方面，从被测系统获取的检测数据(如软件配置项文件数据)在跳转机完成计算后才反馈给检测任务端，以保证被测系统的数据不直接传输到检测任务端。

另外，被测航电系统组织结构复杂，规模庞大，且运行平台异构多样，例如，操作系统有VxWorks、Linux、Windows等3种，处理器有单核、多核等多种，而不同型号飞机的航电系统差异性更大，航电系统的这些特征使得检测任务复杂性增加。在当前批量航电系统并行检测需求背景下，为屏蔽被测系统的差异性和检测任务的复杂性，本文在检测任务端和跳转机之间增加一个逻辑检测设备，用于将复杂检测任务转换为对被测系统检测的基本操作序列，并激励检测设备执行检测。

基于此，本文设计航电系统并行检测系统分层框架，如图1所示，由检测任务端、逻辑检测设备、跳转机和被测系统4层组成。整个检测系统框架又可按照图中虚线分为前后端两部分，前端由检测任务端和部分逻辑检测设备功能组成，主要完成检测任务分解、并行调度与管理等；后端由逻辑检测设备的另外部分功能、跳转机和被测系统组成，主要通过逻辑检测设备、跳转机和被测主机之间协同交互完成检测工作，以及采样结果收集和研判。后端为前端的并行调度提供支持，本文重点关注后端。下面对后端各设备之间的交互过程作进一步介绍。

图1 航电系统并行检测系统分层框架Fig.1 Layered test system framework for parallel testing of avionics systems

被测系统即为被测航电系统软件及其软件运行环境，软件运行环境实际为被测航电系统所在被测主机。被测系统为一个航电系统的多个分系统或者多个航电系统。对被测系统的检测是通过跳转机与被测系统中的被测主机交互完成。被测主机开放指定的接口供检测使用，称为被测主机的检测API。被测主机与跳转机之间的交互主要包括：从跳转机接收文件一致性检测请求和资源状态适配性检测激励，执行自身相应的检测API，并响应被测文件数据和资源状态数据给相应的跳转机。

跳转机通过对外提供检测API来支持检测，在检测过程中从逻辑检测设备接收文件一致性检测请求或软件运行环境资源状态适配性检测请求，对于文件一致性检测请求，跳转机执行文件一致性检测相关检测API，首先与被测文件(软件配置项文件和操作系统关键文件)所在的被测主机建立SSH-2(Secure SHell version 2)连接，然后从相应被测主机下载被测文件到本地进行特征计算；对于软件运行环境资源状态适配性检测请求，跳转机执行另一类检测API继续向被测主机转发该类请求。同时，也接收从被测主机发送来的被测文件数据和资源状态数据，以及将采样数据或者特征数据发送给逻辑检测设备。

逻辑检测设备也通过检测API与跳转机进行交互，对于检测任务中不同的被测项目(如软件配置项检测、操作系统关键文件检测或主机系统资源状态检测等)，逻辑检测设备调用不同的检测API。若进行文件一致性检测，逻辑检测设备发送文件一致性检测相关的检测API激励跳转机执行一致性检测API；若对其他软件运行环境进行资源状态适配性检测，逻辑检测设备发送资源状态检测相关的检测API激励跳转机执行另一类检测API。

上述检测系统分层框架可为航电系统并行检测建立设备协同交互与统一访问机制，进而支持检测过程与检测设备解耦合。

3 检测数据表征与检测设备协同

在以上检测系统分层框架下的设备交互过程中，各设备既要根据交互信息选择执行不同的操作，又要运行着其内部常规程序以维护自身的状态，他们之间需要协同工作才能确保整个系统安全可靠运行。另外，检测过程涉及的设备类型和功能各不相同，设备数目众多。为使得基于上述检测系统框架的检测过程与检测设备解耦合，能够更好地支持并行检测，后端对应的检测过程中需要能够动态协同各设备执行检测。下面首先抽象定义检测数据类型，在此基础上，给出设备协同语句及其解释执行机制。

3.1 检测数据类型

在设备协同执行检测过程中需要输入被测系统相关参数和输出检测结果数据等，为使得检测具有通用性，本文将这些数据类型进行封装得到设备类型、被测系统参数类型、采样结果类型和检测标准类型等抽象数据类型。下面给出这些数据类型的形式定义。

3.1.1 设备类型

基于上述检测系统分层框架抽象定义设备类型DT，由设备类别标识DCla、设备标识Dname、设备基本操作Dopers、设备所属网关Dgt组成，形式为

DT=(DCla,Dname,Dopers,Dgt)

其中：DCla取值可为“逻辑检测设备”、“跳转机”或“被测主机”；Dname为具体设备的标识；Dgt的取值根据上述检测系统分层架构来确定，逻辑检测设备无设备所属网关，跳转机的设备所属网关是其上层的逻辑检测设备，被测主机的设备所属网关是其上层的跳转机；Dopers是Dname所指设备支持的检测基本操作的集合。本文将一个检测基本操作定义为一个检测API，设备在被激励下通过调用自身的检测API实现对被测系统的检测。检测API的形式定义为

定义1检测API(TAPI)。将TAPI定义为一个五元组(Nametapi,Itin,Itout,Btin,Btout)。其中：Nametapi为TAPI的名称；Itin为TAPI的输入接口，定义为输入参数序列，即{IP1,IP2,……,IPm}；Itout为TAPI的输出接口，定义为输出参数序列，即{OP1,OP2,……,OPn}；Btin为输入接口Itin的约束集合；Btout为输出接口Itout的约束集合。

针对航电系统软件配置项一致性检测和软件运行环境资源状态适配性检测，本文设计了被测主机检测API、跳转机检测API和逻辑检测设备检测API共3类，部分检测API如表1所示。

在检测系统的扩展应用中，可根据所要进行的检测项目增加跳转机和被测主机的检测API，从而支持更多检测项目。

3.1.2 被测系统参数类型

被测系统参数类型抽象定义检测过程中所需要的描述被测航电系统及其软件运行环境的相关参数的类型，用TestedAS表示被测系统、TestedSubsys表示组成被测系统的分系统、TestedHost表示包含的被测主机、TestedCSCI表示被测软件配置项、TestedOSKeyFile表示被测主机的操作系统关键文件、TestedSysRes表示被测软件运行环境资源，则被测系统参数TPT的相关形式定义为

TPT：:= TestedAS | TestedSubsys | TestedHost | TestedCSCI | TestedOSKFile | TestedSysRes

TestedAS：:= (ASID,ASModel,ASPlaneID,TestedSubsys+)

TestedSubsys：:= (SubsysID,ASID,TestedHost+)

TestedHost：:= (HostID,ASID,SubsysID,HostDetail)

TestedCSCI：:= (CSCIID,ASID,SubsysID,HostID,CSCIConf+)

CSCIConf：:= (ConfID,ConfType,ConfFilePath,ConfExcludePath)

TestedSysRes：:= (ASID,SubsysID,HostID,SysRes*)

SysRes：:= (CpuRes,MemRes,DiskRes,NetIntRes,ProcessRes,LogRes)

其中：HostDetail可根据实际系统具体定义，比如可为主机访问用户名、密码、操作系统类型等；TestedOSKeyFile的定义同TestedCSCI。

表1 部分逻辑检测设备、跳转机和被测主机检测APITable 1 Part of test API for tested host,test gateway devices,and logic test device

3.1.3 采样结果类型

采样结果数据主要指跳转机采样获得的软件配置项文件或操作系统关键文件的特征数据，以及软件运行环境资源状态数据。不同的检测项目获得的采样结果数据类别和含义不同。本文定义采样结果类型TRT为由结果类别标识TRstc、采样结果名称Trstname和采样数据内容TrstData组成的三元组，形式为

TRT = (TRstc,Trstname,TrstData)

式中：TRstc为文件采样结果或资源状态采样结果类别；Trstname为具体的采样结果文件名称；TrstData的类型因TRstc的不同而不同。当TRstc取值为文件采样结果类别时，TrstData为CSCIAS类型；当TRstc取值为环境资源状态采样结果类别时，TrstData是Status-SCR类型。这里，

1)CSCIAS为航电系统软件配置项或操作系统关键文件特征类型，定义为由文件名称NameCSCI、文件特征集合CONF和对外提供的应用程序接口集合CAPI组成的三元组，形式化定义为

CSCIAS= (NameCSCI,CONF,CAPI)

式中：CONF由软件配置项或操作系统关键文件名称NameCONF和文件属性指标集合PVCONF组成，即CONF=(NameCONF,PVCONF)，PVCONF是PVconf的集合，PVconf又由文件属性Pconf和文件属性值Vconf共同定义，即PVconf = (Pconf,Vconf)；CAPI定义类似TAPI。

2)Status-SCR为软件运行环境资源状态类型，由软件运行环境资源名称NameSCR、资源属性状态集合PVSCR和资源对外提供的应用程序接口集合RAPI组成，其形式化定义为

Status-SCR = (NameSCR,PVSCR,RAPI)

式中：PVSCR为PVscr的集合，PVscr由环境资源属性Pscr和资源属性值Vscr共同定义，即PVscr = (Pscr,Vscr)；RAPI的定义也与TAPI类似。

3.1.4 检测标准类型

检测标准类型抽象定义被检测文件的标准特征数据集和被测软件运行环境资源状态的标准值或取值范围。检测标准类型TST定义为由检测标准类别标识TStdc、检测标准名称TStdname、标准创建时间TStdCDate和检测标准数据TStdData组成的四元组，形式为

TST=(TStdc,TStdname,TStdCDate,

TStdData)

式中：TStdc为字符串类型，取值可为文件标准类别或软件运行环境资源状态标准类别；TStdname为字符串类型，指具体检测标准的名称；TStdCDate的格式为“YY-MM-DD:hh-mm-ss”；TStdData的定义与TStdc的取值有关，若TStdc取值为文件特征标准类别，TStdData为CSCIAS类型；若TStdc取值为运行环境资源状态标准，TStdData则是Status-SCR类型。

3.2 设备协同语句

根据上述检测系统分层框架及设备交互过程，基于前述检测数据类型设计如下设备协同语句。

1)跳转机设备检测API请求语句JumpTAPIReq

该语句用于请求合适的跳转机执行检测API以获取软件配置项文件和操作系统关键文件采样数据。JumpTAPIReq可定义为函数JTAPIReq(被请求跳转机检测API,被请求检测API参数列表,执行返回)，其中，执行返回又表示为二元组<被请求跳转机,执行回令>。例如，逻辑检测设备请求跳转机执行检测操作Jtapi，Jtparas为Jtapi所需的参数，请求结果返回给Rt，则JumpTAPIReq可形式化表示为

JumpTAPIReq：:= JTAPIReq(Jtapi,Jtparas,Rt)

这里，请求成功时Rt值为被请求到的跳转机标识和执行回令值1；否则，返回的被请求跳转机值为空，执行回令值为0或其他初始值(为区分设备协同请求不成功原因，可设置一个非1和0的初始值)，具体见3.3节中语句执行过程。

2)跳转机设备数据请求语句JumpDataReq

该语句用于获取跳转机设备上的文件采样数据的特征数据。JumpDataReq可定义为函数JDataReq(被请求跳转机,被请求数据参数,执行返回)，其中，执行返回为二元组<被请求数据,执行回令>。例如，逻辑检测设备向被请求跳转机Jdn请求参数Jsparas对应文件的特征值，请求结果返回给Rt，则JumpDataReq可形式化表示为

JumpDataReq：:= JDataReq (Jdn,Jsparas,Rt)

该请求语句执行成功时Rt值为返回的参数Jsparas对应数据和执行回令值1；否则，被请求参数Jsparas的返回值为空，执行回令值为0或者不变，详见3.3节。

3)设备检测API与数据交互语句DevTAPICol

该语句用于请求合适的跳转机激励被测主机执行被请求设备检测API从而获得该主机的环境资源状态数据。DevTAPICol可定义为函数DTAPICol(被测主机,被请求Tapi,Tapi参数列表,执行返回)，其中，执行返回定义为二元组<被请求资源数据,执行回令>。例如，逻辑检测设备请求合适的跳转机向被测主机Thost发送激励,请求Thost执行检测操作Htapi，Htapi所需参数为Htparas，请求结果返回给Rt，则DevTAPICol可形式化表示为

DevTAPICol::=DTAPICol(Thost,Htapi,

Htparas,Rt)

交互成功时，Rt的值为返回的被请求资源状态数据和回令值1；交互不成功时，资源请求结果为空，执行回令值为0或者不变。

4)结果研判语句TresultJdg

该语句用于请求逻辑检测设备对采样结果数据与检测标准进行比较。TresultJdg可定义为函数TRJdg(采样结果数据,被测项目标准,执行返回)，其中，执行返回又表示为二元组<研判结果,执行回执>。例如，逻辑检测设备将采样结果数据Td与相应的被测文件或资源标准Ts进行比较研判，将执行返回赋给Rt，则TresultJdg可形式化表示为

TresultJdg：:= TRJdg(Td,Ts,Rt)

式中：研判结果的取值可根据被测项目具体情况而定，如可为“软件配置项正常”、“软件配置项缺失”、“主机磁盘空间不足”、“异常”等。

本文的面向航电系统并行检测的设备协同语句DAPICol可表示为

DAPICol：:= JumpTAPIReq | JumpDataReq |

DevTAPICol | TresultJdg

上述设备协同语句将逻辑检测设备、跳转机和被测主机的检测API封装为基本检测单元，这些基本检测单元可独立执行，在功能上是完整的，且在检测实施过程中具有高复用性，可被看作是检测执行过程中的最小可执行检测单元，在本文中定义为检测原子。检测原子封装了基本的检测设备协同行为，因此，检测原子ASTAtom可表示为

ASTAtom：:= ASTAname[DAPICol]

这样，复杂的检测任务就可通过使用常用程序设计语言中的串行、并行、循环、条件等语句复合调用不同的检测原子来自动实现。

3.3 设备协同语句的执行过程

设备协同语句的执行是由逻辑检测设备发起，激励跳转机、被测主机执行其自身的检测API实现相应检测功能的过程，因此，下文从逻辑检测设备、跳转机和被测主机3层阐述各设备协同语句的执行过程。

3.3.1 逻辑检测设备层设备协同语句的执行

在协同跳转机和被测主机执行检测过程中，逻辑检测设备主要完成以下功能：① 向合适跳转机发送检测请求；② 接收来自跳转机的检测数据；③ 将采样结果数据与检测标准进行比对研判。针对上述各设备协同语句，下面给出逻辑检测设备层的执行过程：

1)若执行的语句为JTAPIReq(njtapi,pjtapi,r)，逻辑检测设备选择合适的跳转机建立SSH-2连接，将被请求检测操作njtapi及所需参数pjtapi发送给所选跳转机执行被请求检测操作。跳转机执行完该TAPI后，逻辑检测设备从跳转机接收执行返回r，包括执行该TAPI的跳转机标识和执行回令。

2)若执行的语句为JDataReq(dj,pjsamp,r)，逻辑检测设备向指定跳转机dj发送pjsamp数据的请求，然后接收执行返回r，即被请求数据和执行回令。

3)若执行的语句为DTAPICol(dthost,nhtapi,phtapi,r)，逻辑检测设备选择合适的跳转机，通过该跳转机将被请求检测操作nhtapi及所需参数phtapi发送给被测主机dthost，请求dthost执行检测操作，然后接收执行返回r，即采样结果和执行回令。

4)若执行的语句为TRJdg(ptd,pts,r)，逻辑检测设备将ptd对应的采样结果数据和pts对应的标准进行比对，完成研判并返回r。

3.3.2 跳转机层设备协同语句的执行

跳转机在与其他设备协同执行检测过程中主要完成以下功能：① 从逻辑检测设备接收检测请求，② 对被请求的设备检测API进行安全性检查，③ 调用自身的检测API执行检测，④ 激励被测主机执行检测API，⑤ 从被测主机接收采样数据，⑥ 向逻辑检测设备返回请求结果和执行回令。跳转机层的各设备协同语句的执行过程如下：

1)若从逻辑检测设备接收到的是跳转机检测API请求(njtapi,pjtapi,r)，首先对被请求的检测操作njtapi进行安全性检查，然后根据参数pjtapi与被测主机建立SSH-2连接，并调用njtapi下载相应的被测文件数据到本机，最后向逻辑检测设备发送执行返回r。

2)若接收到的是跳转机数据请求(dj,pjsamp,r)，读取被请求跳转机dj上的文件采样数据pjsamp并调用跳转机检测API计算其特征，然后删除跳转机上的被测系统文件数据，最后返回r。

3)若接收到的是设备检测API和数据交互请求(dthost,nhtapi,phtapi,r)，首先对被请求的设备nhtapi进行安全性检查，然后通过SSH-2连接向被测主机dthost请求执行检测操作nhtapi并发送参数phtapi，最后从被测主机接收采样获得的资源状态数据，并返回r。

3.3.3 被测主机层设备协同语句的执行

在本文的检测执行过程中，被测主机主要协同跳转机完成检测，被测主机需要向检测系统开放相应接口，一方面，支持检测系统下载被测系统文件；另一方面，支持执行部分被测主机操作命令以读取其资源状态数据。本文将读取被测主机资源状态数据的操作封装为被测主机检测API。在设备协同过程中，被测主机在跳转机的激励下执行被请求的检测API采样获取自身的资源状态数据，并返回给跳转机。

本文设备协同语句中，逻辑检测设备动态协同跳转机执行检测的协同机制是在保证检测任务正确运行的前提下，对其中的检测API序列的执行顺序进行合理安排，并不会改变检测任务。因此，应用本文方法执行检测仍然能够保证整个检测任务的完备性。

4 系统实现与实验分析

本文将所提方法应用到某型预警机任务电子系统的并行检测中，设计并实现了一个通用预警机任务电子系统并行检测系统，系统架构如图2所示，由检测配置子系统、检测执行子系统和检测评估子系统构成。

检测配置子系统通过图形化界面为检测人员提供检测任务编制和生成环境，检测任务按照实际检测需求可分为不同的检测模式，例如一键检测模式或定制化检测模式。一键检测又称为快速检测，是对被测系统所有检测项目进行检测；定制化检测则是根据检测人员需要对指定的检测项目进行检测。

检测执行子系统调用本文的检测设备协同语句并行执行检测任务，同时对检测任务的执行过程进行监控。

检测评估子系统则是通过对检测过程中生成的采样结果数据进行研判并生成检测报告，方便检测人员维护保障航电系统，以及追溯问题。

图3为本文实现的通用预警机任务电子系统并行检测系统的检测执行界面示例。

图2 通用预警机任务电子系统并行检测系统架构Fig.2 Architecture of parallel test system for early warning mission electronic system

最后，应用本文的并行检测系统和文献[14]中的自动化检测系统(单机检测系统)对某预警机任务电子系统进行检测验证本文方法的应用效果。该被检测系统由显控分系统、指挥控制分系统、雷达分系统等7个分系统组成，总共包含75个软件配置项节点，组成系统的所有软件配置项部署在17台被测主机上，被测主机中，显控分系统中的主任务计算机运行Red Hat Linux操作系统，显控分系统中的操作员工作站和电子侦查分系统中的主控计算机运行Windows 2000操作系统，其他设备运行VxWorks操作系统。为此，设计如下3种检测方案进行实验：

1)单机-串行-耦合：应用1套单机检测系统串行检测被测系统中的每个被测主机，检测系统中的跳转机与被测主机耦合，检测人员需为运行不同操作系统的被测主机选择不同的检测接口，由1位检测人员操作。

2)单机-并行-耦合：应用3套单机检测系统并行执行检测，跳转机与被测主机耦合，1套用于检测运行Linux操作系统的被测主机，1套用于检测运行Windows操作系统的被测主机，另1套用于检测运行VxWorks操作系统的被测主机，相同操作系统的多台主机被串行检测，每套单机检测系统由1位检测人员操作。

3)本文-并行-解耦：应用1套本文实现的系统执行相同检测任务，通过逻辑检测设备协同3台跳转机的不同检测API对所有被测主机执行并行检测，由1位检测人员操作。

在以上3种检测方案中，通过相同配置的跳转机对被测主机执行检测，跳转机的软硬件环境均为：Intel®CoreTMi5-3337U处理器，1.80 GHz主频，4 GB内存和Linux操作系统。

实验过程中，统计3种检测方案的检测花费时间和检测任务执行结果并进行比较分析。

4.1 检测时间对比

采用上述3种检测方案分别执行检测，方案1在各阶段花费时间为串行检测17个被测主机在相应阶段的花费时间之和；方案2在各阶段花费时间为3套单机检测系统在每组的相应阶段花费时间的最大值；方案3在各阶段花费时间为执行整个检测任务在各阶段实际花费时间。表2为每种检测方案执行5次检测在检测配置、检测执行和检测评估3个阶段的平均检测花费时间。

如表2所示，同样执行上述检测任务，采用方案2通过3套单机检测系统并行执行检测比1套单机检测系统串行检测所花费平均总时间减少20分钟，检测效率提升30%；而采用本文系统通过3台跳转机并行执行检测所花费平均总时间比1套单机检测系统减少39分钟，检测效率提升59%。由此可见，同样通过3台跳转机并行执行相同检测任务，应用本文方法解耦后执行并行检测所花费平均总时间比未解耦的情况下执行并行检测所花费平均总时间又减少了19分钟，检测效率又提升了29%，而且，检测人员减少了2/3。进一步比较相同检测阶段3种方案的平均检测时间不难发现，检测时间减少最为明显的是检测执行阶段。这是因为，本文实现的检测系统应用检测设备协同机制实现了检测过程与跳转机的解耦合，可以动态协同跳转机对被测主机执行并行检测，提高了跳转机的利用率和设备协同的自动化程度。

表2 应用3种检测方案执行检测任务平均花费时间对比Table 2 Comparison of average test time of executing test task by three test schemes mm

为了进一步验证本文方法的有效性，从上述被测系统中随机抽取1、3、6、9、12和15台被测主机，并保证被测主机为3台以上时运行各操作系统的被测主机至少包含1台。然后采用上述3种检测方案对被测主机上的软件配置项和软件运行环境资源状态进行检测，每种方案进行6组实验，每组实验重复5次。3种方案的平均检测执行时间变化曲线如图4所示。

从图4可见，随着被测主机数不断增多，3种检测方案在检测执行阶段的平均花费时间都在不断增加。其中，方案1在检测执行阶段的平均花费时间随被测主机数增加最快，方案2的平均检测执行时间增幅比方案1明显下降，而方案3的平均检测执行时间增加又明显比方案2缓慢。由此可见，随着被测主机或者被测系统增多，相对于方案1和方案2来说，应用本文方法将检测过程与检测设备解耦后执行并行检测花费检测执行时间减少的优势更加明显。

综上实验表明，与单机检测系统串行执行检测相比，本文方法支持下的检测系统执行并行检测使得检测时间减少一半以上，检测效率提升一倍以上。在对多被测主机(特别是不同运行平台的被测主机)进行检测时，与应用3套单机检测系统在未解耦的情况下执行并行检测相比，应用本文方法支持下的检测系统执行并行检测，减少检测人员消耗的同时进一步减少了检测时间和提高了检测效率。

图4 3种检测方案的平均检测执行时间变化曲线Fig.4 Average test executing time curves of three test schemes

4.2 检测任务执行结果对比

上述3种检测方案中，由于方案2是方案1中的被测主机按照操作系统不同分为3组进行检测，并未分解检测任务，因此，这里只给出方案1和方案3完成整个检测任务的执行结果对比，如图5所示。每一个软件配置项对应一个采样结果数据文件，每一台被测主机的CPU和内存对应一个采样结果数据文件，硬盘和进程分别对应一个采样结果数据文件，采样结果文件数为以上所有采样结果文件总数。发现异常数包括和标准不一致的软件配置项文件数和不适配的被测主机资源数。连接不成功数是检测系统未连接上的被测主机数。

从图5可知，通过本文方法协同跳转机执行上述检测任务获得的采样结果文件数、发现异常数和连接不成功的被测主机数都与使用单机检测系统执行检测任务获得的结果相等。由此可见，本文的设备协同语句完全执行了被分解后的检测任务，即本文方法将检测过程与检测设备解耦后仍然保证了检测任务执行的完备性。

本文所提检测设备协同方法及实现的并行检测系统已经应用到某电子科学研究院的多型号预警机任务电子系统检测中，可以支持多系统同时检测，能够确保检测过程的安全性。在并行检测应用中，每个被测系统包含软件配置项70～90个，被测主机15～24台，被测主机操作系统3种之多。检测系统通过检测设备协同方法动态协同调用合适的跳转机实现了对多个被测系统(和被测系统中的多个分系统)的并行检测，与传统的检测方法相比，改变了检测工作模式，减少了人员消耗，提高了检测效率。

图5 2种方案的检测任务执行结果对比图Fig.5 Comparison of results of executing test task through two test schemes

5 结 论

针对当前航电系统并行检测面临的检测设备与具体航电系统耦合、检测过程与具体检测设备耦合、检测安全性要求高以及检测任务繁重等问题，本文给出一种适用于航电系统并行检测的检测过程与检测设备解耦方法。

1)给出了一种检测分层框架，支持检测设备与被测航电系统解耦合，提高了检测系统的通用性。通过这种分层框架也可保证检测过程的安全性。

2)给出了设备协同语句及其设备协同机制，实现了航电系统并行检测中检测过程与检测设备解耦合，从而可以更好地支持多个航电系统并行检测。

3)实际应用和对比实验表明，本文方法的引入使得航电系统检测工作模式改变，检测人员消耗减少，检测效率得到提高，同时也保证了检测过程的安全性。