基于专家系统的交互式故障诊断软件研究
引 言
当前自动测试领域所开发和设计的测试诊断软件在功能上已较为完善、能够满足绝大多数测试诊断要求，但在进行测试时多是自动按照预先定义好的测试流程，顺序地完成测试项目。整个测试诊断过程只是一个单向的程序顺序执行过程，用户无法将自身经验和思维与测试软件进行人机交互，例如测试诊断软件不能由用户根据需要任意选取测试位置、步骤等，大大浪费了测试资源和时间，无法实现测试效率的最优化。本文正是在现有自动测试软件的研究基础上，结合人工与自动测试的各自优点，通过研究基于专家系统的交互式故障推理模式以及设计基于该模式的故障诊断软件系统，完成测试系统的优化。
1交互式故障推理模式
交互式故障推理模式以故障诊断专家系统为核心，结合故障现象、测试数据和用户经验、思维进行综合分析，基于专家系统和人工智能获取测试跳转条件，逐步推理、检测、隔离定位具体故障；而且具有学习能力、且预留有故障诊断流程的扩展接口，可以在实际使用过程中不断优化已存在的诊断流程，并可以方便地增加新的诊断流程，实现测试系统的自我丰富与完善。
故障诊断专家系统一般包括知识获取机构、解释机构、推理机构、人机交互接口、知识库及其管理系统、数据库及其管理系统和用户这几部分，结构如图1所示。交互式故障推理模式主要从以下几个方面对故障诊断专家系统进行了改进与优化
1)知识库及其管理系统。
知识库是知识的存储机构，源于熟悉测试对象的装备专家、相关资料以及测试系统的运行实践，是专家系统的核心部分。在知识的表示上，针对现有自动测试领域所采用的基于数据库和基于Windows文本文件的信息知识交换存在的读取速度慢、交互能力不强和结构化描述时序关系不足的缺点，应用可扩展标记语言(eXtensible Markup Language，XML)来描述测试信息。XML具有DTD和Schema两种机制对所建立的文档进行建模和验证，对信息的结构化描述具有良好格式，数据处理便捷，具有完善的解码方式和面向对象的特性，可以方便地确保数据的一致性、完整性和可靠性，简化测试系统内部以及测试系统之间数据交换的工作，并能与现存的系统和标准很好地兼容，如STD标准、IEEE1232标准等。
2)知识获取机构。
对于专家知识获取，系统提供开发一整套方法与工具，建立与维护专家知识库，把用于求解故障诊断问题的知识转换成XML文档的特定计算机表示形式。同时，在每次测试诊断后，系统将对测试诊断结果进行统计及评估，及时反馈、修正、更新专家知识库中的结构与参数。
3)人机交互接口。
人机交互接口是专家系统和用户之间进行交互通信和信息交换的媒介。专家系统的生命力就在于它能同用户一起组成高性能的人机系统，可以人机共存和共同思考。
在人机交互接口方面，系统进行了更多的与用户之间的交互，可以图形化动态引导用户进行测试，并具备详细的测试提示功能，可以不断通过文字或图片提示引导用户进行一步步测试，用户无需太多的专业知识即可进行操作。系统也可以接受用户的指令，反馈测试结果，根据用户经验和思维，从任意测试点开始测试，或人为强制选择系统中的某个测试点，诊断软件随即调整状态，进入该测试点进行测试，并以此为切入点，进行下一步的测试推导过程，从而大大提高测试效率。
4)推理机构。
系统主要采用基于产生式规则和人的因素的混合式模型，吸收各自优点，实现多层次、多深度诊断知识的推理，或在诊断的不同阶段采用不同方法。系统的推理机制主要分为两部分：
(1)系统将规则的前提部分同知识库进行匹配，一旦匹配成功，则执行规则的动作部分。动作部分既可以使用约束变量的任一过程，又可以是某一结论，直至当前的问题被求解或规则库中没有可用规则为止。程序搜索知识库中匹配的规则，按照推理机制，进而得出诊断的结论。
(2)系统设计一系列问题组，问题组中的每个问题之间有一定的逻辑关系，根据用户对上个问题的回答结果，判断、分析、推理，提出下个问题。
系统基于已经获得的测试参数，综合规则推导结果与对话推导结果，提出下一步要测试或判断的步骤，再根据该步测试判断结果，提出下一个要测试或判断的步骤。一次测试判断可以是自动测试自动判断，可以是自动测试人工判断，也可以是提示加人工判断，从而获得较高的故障诊断效率。
2 交互式故障诊断软件的设计与实现
测试主控计算机上运行的交互式故障诊断软件基于构件技术，将系统功能模块化，由测试诊断、用户管理、系统自检、配置工具和测试日志等5个计算机软件配置项(CSCI)组成，将测试程序集(TPS)生成和使用彻底分离，从而保证系统具有较好的通用性和易扩展性，如图2所示。
限于文章篇幅，本文以测试诊断部分为例说明其设计与实现过程。
测试诊断CSCI以Lab Windows/CVI作为软件开发平台，首先需要调用配置工具CSCI中仪器、通道和流程描述构件以生成符合ATML标准的XML文件(其中对于测试诊断步骤是以严格二叉树的结点来直观描述的，如图3所示)，再采用DOM按照定义验证数据格式，解析XML文档或消息，将XML表达的测试信息读入系统，随后可以从二叉树任意结点开始，基于交互式故障推理模式逐步进行测试、推理、隔离定位直至叶结点即具体故障，从而完成测试诊断任务。
在测试诊断CSCI中，对于测试诊断结点即测试诊断步骤，考虑索引的方便，采用链表的数据结构来描述结点，定义如下：
typedef struct FM TNode
{
int ID；//结点ID
int NodeProperty；//结点属性
char*NodeName；//结点名称
int StimulateSignal Number；//激励信号数
SignalInfo*pStimulateSignal；//激励信号
ResponseInfo NodeResponseInfo；//测试信号响应信息
SignalInfo*pResponseSignal；//测试信号
JumpAttribute YesJump；//是跳转
JumpAttribute NoJump；//否跳转
struct FMTNode*pYesNode；//是子结点
struct FMTNode*pNoNode；//否子结点
Rect*NodeRect；//绘图时结点所在矩形框信息
int state；//绘图时结点状态(1为伸展、0为收缩)
}FM TNode，*pFMTNode；
在对任一测试诊断结点进行操作时，按照先激励后响应的原则运行，首先系统将该结点与其父结点的激励信号进行比较，关闭上次父结点激励中不再使用的信号，然后判断当前激
励信号是否是上次父结点使用过的，如果未使用过则输出该信号，最后保存当前结点激励信号信息，为此封装了对应的结点激励操作的功能函数如下：
int StimulateNode(FM TNode*pDiagnosisNode)；//输出结点激励信号，FMTNode＊pDiagnosisNode为当前测试诊断结点
int GetCurrentNodeStimulateSignalInformation(FMTNode*pDiagnosis Node)；//获取当前测试诊断结点的激励信号信息
int bStimulateSignalIs Used(char*StimulateSignalName)；//判断当前激励信号是否是上次使用过的，char*StimulateSignalName为激励信号名称，函数返回值0为否，1为是
int CloseLastStimulateSignalNotUsed(FM TNode*pDiagnosis-Node)；//关闭上一次激励中不再使用的信号
int CloseStimulateSignal(char*StimulateSignalName)；//关闭激励信号
然后基于交互式故障推理模式，根据不同的测试诊断模式，测试结点的响应信号并做出相应判断，获取跳转条件进入下一测试诊断结点或诊断结论，直至叶结点，其中对测试诊断
结点的响应信息进行如下定义：
typedef struct ResponseInfo
{
int Judgement Mode；//测试诊断模式
char*PromptToUser；//提示信息
char*PictureToUser；//引导图片
char*QuestionForUser；//对话提问信息
}ResponseInfo，*pResponseInfo；
其中经实践验证，测试诊断模式可以分为四类：①系统测试、系统判断(即系统根据测试信号的标称值、上下限值等进行自动判断)；②系统连续测试、用户判断(即某些测试量需要不断测试并实时返回测试值，然后用户根据需要判断，如万用表测电阻)；③系统单次测试、用户判断(即某些测试量通过系统测试一次并返回测试值，然后用户根据需要判断，如测频率等较为稳定的物理量)；④用户观察、用户判断(即某些测试内容仅需用户肉眼做出相应观察并判断即可，无须系统仪器资源做出相应测试，如观察元器件是否有损坏等)。
这样测试诊断CSCI可以从根结点开始，逐步进行测试、推理诊断、隔离定位直至叶结点即具体故障；同时用户也可以根据自身经验和思维在测试诊断过程中强制中断某步测试，重新任意选取某一测试诊断结点开始进行故障诊断，从而得出诊断结论。
3 结束语
基于专家系统的交互式故障诊断软件在测试诊断过程中可以根据用户的不同测试方法和测试经验，灵活地完成测试任务，实现了人机交互，提高了测试诊断效率，减少了重复测试。该故障诊断软件现已投入实际应用，成功地应用于某装备自动测试平台，并取得了良好的实际效果。
