一种基于知识库的软件远程故障诊断与修复方法

摘要

提供一种基于知识库的软件远程故障诊断与修复方法，包括：将被诊断软件系统中各软件构件的运行条件、依赖关系、故障表现特征和修复策略进行建模和入库以形成故障诊断与修复知识库，将该知识库存储在独立于被诊断软件系统的服务终端上；在被诊断软件系统中安装客户端代理程序，在服务终端上安装服务端程序，利用客户端代理程序实时获取被诊断软件系统的诊断信息并通过网络将其传递给服务端程序；服务端程序依据获取的诊断信息和该知识库，产生决策命令并将决策命令通过网络传递给客户端代理程序；客户端代理程序执行决策命令，实现软件故障的诊断与修复。采用本发明，实现软件故障的智能诊断与修复，提升软件故障诊断与修复的效率和自动化程度。

说明书

技术领域

本发明涉及软件故障诊断与修复领域，具体涉及一种基于知识库的软件远 程故障诊断与修复方法。

背景技术

在工业过程中，硬件故障诊断的含义是根据特定传感器的测量值，确定引 起系统异常或失效的原因、部位及严重程度。硬件故障诊断专家系统的功能是 根据测量信息和计算机化的诊断知识，自动完成系统异常或失效的诊断。软件 故障诊断还是一个较新的事物，软件故障同硬件故障在故障机理方面就具有较 大的差异，这必然会导致两者的诊断方法会存在一定的差异。软件系统的数学 模型是离散的，故障的形成无物理原因，失效的发展取决于输入值和运行状态 的组合。软件输入值和运行状态的组合在合理范围内的微小变化可能引起输出 的巨大变化，软件故障的出现通常无前兆，硬件系统在正常工作条件下其行为 是渐变的，故障的形成和失效的发生一般都有物理原因，硬件故障的出现通常 有前兆。软件故障难以定位，失效现象往往不在失效部件显现，硬件故障较易 定位，失效部件的物理参数常常发生明显变化。如果发现一个软件出现了某个 故障，那么该版本的所有软件都会可能发生该故障。

软件故障可分为因开发过程中引入的设计及编码缺陷造成的软件故障和因 软件运行外部依赖环境配置不正确造成的软件故障。前类故障可视作由于软件 的内在原因造成，后类故障可视作由于软件的外在原因造成。前类故障的修复 需要修改软件的源程序并重新发布和安装新版软件，而后一类故障的修复并不 需要修改源码，只是对配置文件、运行环境进行适当的调整。当前的大型软件 系统特别是分布式软件系统广泛采用基于构件的体系结构，构件复用是一种产 品复用，构件库中的构件作为产品都经过了严格的测试，许多构件甚至已在其 它系统中历经了多年使用，因此构件出现内部故障的概率很小，在实际使用过 程中出现的许多故障是由于构件的少装、多装、错装、错配、服务未启动等外 在原因造成的。对于由外在原因引起的软件故障来说，它的诊断和修复主要依 靠被诊断软件系统的外部依赖环境配置领域知识进行。

因此，在现有技术中，需要一种对于软件故障的有效、方便、准确的诊断 和修复方法。

发明内容

有鉴于此，本发明的主要目的在于提供一种基于知识库的软件远程故障诊 断与修复方法及系统，解决现有技术中存在的问题，能够实现软件故障的智能 诊断与修复，提升软件故障诊断与修复的效率和自动化程度。

本发明人，通过创造性的劳动，设计了软件故障诊断知识库，即是将软件 故障诊断领域的专家知识表示为计算机内部格式，加以合理的描述存储，以便 于故障诊断时进行有效的检索和利用，从而提高软件故障诊断与修复的效率和 自动化程度。基于知识库软件故障诊断的问题可以描述为以下四元式的形式：

P＝(M,F,K,OBS)

式中，M为系统可观测到的症状集合，F为系统的故障集合，为系 统症状集与故障之间的映射关系（即诊断知识），对于不同的系统K取决于被 诊断软件系统的结构和行为，OBS为当前观察到的症状。

为实现发明目的，本发明的技术方案是这样实现的：

A、将被诊断软件系统中各软件构件的运行条件、依赖关系、故障表现特 征和修复策略进行建模和入库以形成故障诊断与修复知识库，将故障诊断与修 复知识库存储在独立于被诊断软件系统的服务终端上；

B、在被诊断软件系统中安装客户端代理程序，在服务终端上安装服务端 程序，利用客户端代理程序实时获取被诊断软件系统的诊断信息并通过网络将 诊断信息传递给服务端程序；

C、服务端程序依据获取的诊断信息和故障诊断与修复知识库，进行故障 诊断与修复决策以产生决策命令并将决策命令通过网络传递给客户端代理程 序；

D、客户端代理程序执行决策命令，实现软件故障的诊断与修复。

优选地，上述技术方案中，步骤A包括：

A1、将已解决故障的故障特征、故障原因、故障维修方法表示为计算机内 部格式，形成故障案例库录入故障诊断与修复知识库中；

A2、将被诊断软件系统的软件故障领域专家经验知识以产生式规则的形式 进行描述，形成故障诊断规则库录入故障诊断与修复知识库中。

优选地，上述技术方案中，步骤A1包括：

A1.1、采用数据库表作为案例的计算机内部存储格式，包括案例信息表、 故障信息表、故障构件表、征兆信息表、案例解释表、维修步骤表和附件表；

A1.2、案例信息表由案例名称、案例编号和案例说明组成；

A1.3、故障信息表由故障编号、故障名称、故障类别和故障等级组成；

A1.4、故障构件表由序号、构件类型、构件名称、构件前缀和构件描述组 成；

A1.5、征兆信息表由征兆描述、征兆类别、征兆值和征兆权重组成；

A1.6、案例解释表由故障现象、故障原因、解决措施和维修建议组成；

A1.7、维修步骤表由操作类别、操作序号、操作参数和操作时间组成；

A1.8、附件表由资源编号、资源类别和资源数据组成。

优选地，上述技术方案中，步骤A2包括：

A2.1、将被诊断软件系统的软件故障领域专家经验知识抽象为一系列的因 果链；

A2.2、将因果链描述为直观的IF-THEN产生式形式。

优选地，上述技术方案中，服务端程序、客户端代理程序和故障诊断与修 复知识库构成一软件故障诊断与修复系统，其中：

服务端程序用于完成被诊断软件系统软件构件的状态监控、诊断决策、维 修决策、知识库管理以及人机交互功能；

客户端代理程序以开机自动运行的后台程序形式部署在被诊断软件系统的 每台计算机上，用于完成本机软件构件的诊断信息收集和故障修复功能。

优选地，上述技术方案中，步骤B包括：

B1、客户端代理程序获取本机软件构件的安装部署信息，将安装部署信息 保存为xml格式文件，然后通过TCP协议将包含安装部署信息的xml格式文件 发送给服务端程序；

B2、客户端代理程序获取本机服务运行信息，将服务运行信息保存为xml 格式文件，然后通过TCP协议将包含服务运行信息的xml格式文件发送给服务 端程序；

B3、客户端代理程序获取本机进程运行信息，将进程运行信息保存为xml 格式文件，然后通过TCP协议将包含进程运行信息的xml格式文件发送给服务 端程序；

B4、客户端代理程序获取本机数据库信息，然后通过UDP协议将数据库 信息发送给服务端程序；

B5、客户端代理程序获取本机CPU和内存使用信息，然后通过UDP协议 将CPU和内存使用信息发送给服务端程序；

优选地，上述技术方案中，步骤C包括：

C1、在故障诊断与修复知识库中进行案例检索，判断是否存在匹配的案例， 如果判断的结果为是，则基于故障诊断与修复知识库中的维修步骤表产生决策 命令以进行故障修复，否则执行步骤C2；

C2、激活基于规则的软件故障诊断与修复。

优选地，上述技术方案中，步骤C1包括：

C1.1、等待用户输入待检故障的案例检索条件；

C1.2、计算用户输入的案例检索条件和故障诊断与修复知识库中所有案例 的相似性；

C1.3、将相似性从高到低进行排序；

C1.4、判断是否存在相似性大于预先设定的输出阈值的案例，如果判断的 结果为是，则执行步骤C1.5，否则返回案例匹配失败；

C1.5、依据与具有最大相似性的案例相对应的维修步骤表产生决策命令以 进行故障修复。

优选地，上述技术方案中，步骤C1.5包括：

C1.5.1、创建基于案例的故障维修线程；

C1.5.2、将具有最大相似性的案例相对应的维修步骤表中与案例故障编号 相关的维修步骤依据操作序号进行排序；

C1.5.3、依据排序而依次取出每个维修步骤的详细信息，并根据操作类别 和操作参数产生决策命令，将决策命令通过网络发送至客户端代理程序，决策 命令即相应的维修动作命令；

C1.5.4、使用维修步骤中的操作时间作为维修动作处理的最大等待时间， 等待客户端代理程序返回维修结果；

C1.5.5、判断是否维修结果已获取或超时，如果判断的结果为是，则执行 步骤C1.5.6，否则执行步骤C1.5.4；

C1.5.6、判断是否所有的维修步骤都已处理完成，如果判断的结果为是， 则执行步骤C1.5.7，否则执行步骤C1.5.3；

C1.5.7、结束基于案例的故障维修线程。

优选地，上述技术方案中，步骤C2包括：

C2.1、进行基于规则的故障诊断；

C2.2、收集基于规则的故障诊断过程中产生的维修步骤；

C2.3、依据C2.2中的维修步骤产生决策命令以进行故障修复。

优选地，上述技术方案中，步骤C2.1包括：

C2.1.1、创建基于规则的故障诊断线程；

C2.1.2、载入软件故障诊断规则描述文件；

C2.1.3、依据规则描述文件创建并显示用户交互界面，并在用户交互界面 上显示用户交互提示信息；

C2.1.4、等待用户输入交互信息；

C2.1.5、判断交互信息是否已经输入，如果判断的结果为是，则执行步骤 C2.1.6，否者执行步骤C2.1.4；

C2.1.6、依据规则描述文件执行诊断操作，通过网络向客户端代理程序发 送相应的诊断命令；

C2.1.7、等待客户端代理程序返回诊断结果；

C2.1.8、判断是否诊断结果已获取或超时，如果判断的结果为是，则执行 步骤C2.1.9，否则执行步骤C2.1.7；

C2.1.9、依据诊断结果和规则描述文件产生维修步骤；

C2.1.10、判断是否还存在可执行的规则，如果判断的结果为是，则执行步 骤C2.1.3，否则执行步骤C2.1.11；

C2.1.11、结束基于规则的故障诊断线程。

优选地，上述技术方案中，步骤C2.3包括：

C2.3.1、创建故障维修线程；

C2.3.2、取出C2.2中的维修步骤中的每个维修步骤的详细信息，并根据操 作类别和操作参数通过网络向客户端代理程序发送决策命令，即，相应的维修 动作命令；

C2.3.3、使用维修步骤中的操作时间作为维修动作处理的最大等待时间， 等待客户端代理程序返回维修结果；

C2.3.4、判断是否维修结果已获取或超时，如果判断的结果为是，则执行 步骤C2.3.5，否则执行步骤C2.3.3；

C2.3.5、判断是否所有的维修步骤都已处理完成，如果判断的结果为是， 则执行步骤C2.3.6，否则执行步骤C2.3.2；

C2.3.6、结束故障维修线程。

本发明提供的基于知识库的软件故障诊断与修复方法及系统，通过将被诊 断软件系统中各软件构件的运行条件、依赖关系、故障表现特征和修复策略进 行建模和入库，形成故障诊断与修复知识库，将软件故障诊断与修复系统划分 为服务端程序和客户端代理程序，客户端代理程序实时获取被诊断软件系统的 诊断信息并通过网络传递给服务端程序，服务端程序依据获取的诊断信息和故 障诊断与修复知识库进行故障诊断与修复决策，并将决策命令通过网络传递给 客户端代理程序，客户端代理程序执行故障诊断与修复决策命令。如此，实现 了软件故障的智能诊断与修复，大大提高了软件故障诊断与修复的效率和自动 化程度。

附图说明

图1为本发明基于知识库的软件故障诊断与修复方法流程示意图；

图2为本发明中客户端代理程序获取诊断信息流程示意图；

图3为本发明中服务端程序故障诊断决策流程示意图；

图4为本发明中案例检索流程示意图；

图5为本发明中基于案例的故障修复流程示意图；

图6为本发明中基于规则的故障诊断流程示意图；

图7为本发明中基于规则的故障修复流程示意图。

具体实施方式

本发明的基本思想是：将被诊断软件系统中各软件构件的运行条件、依赖 关系、故障表现特征和修复策略进行建模和入库，形成故障诊断与修复知识库， 故障诊断与修复知识库包括案例库和规则库，该故障诊断与修复知识库存储在 独立于被诊断软件系统的服务终端上；利用故障诊断与修复知识库、服务端程 序和客户端代理程序构成软件故障诊断与修复系统，服务端程序安装在服务终 端上而客户端代理程序安装在该被诊断软件系统中，服务端程序和客户端代理 程序通过网络通信互相协作实现软件故障的诊断与修复；客户端代理程序实时 获取被诊断软件系统的诊断信息并将其通过网络传递给服务端程序；服务端程 序依据获取的诊断信息和故障诊断与修复知识库进行故障诊断与修复决策产生 决策命令，并将该决策命令通过网络传递给客户端代理程序；客户端代理程序 执行故障诊断与修复决策命令，实现软件故障的诊断与修复。

下面结合附图及具体实施例对本发明做进一步详细的说明。

图1为本发明基于知识库的软件故障诊断与修复方法的总体流程示意图， 如图1所示，包括以下步骤：

步骤1、将被诊断软件系统中各软件构件的运行条件、依赖关系、故障表 现特征和修复策略进行建模和入库以形成故障诊断与修复知识库，将故障诊断 与修复知识库存储在独立于被诊断软件系统的服务终端上；

步骤2、在被诊断软件系统中安装客户端代理程序，在服务终端上安装服 务端程序，利用客户端代理程序实时获取被诊断软件系统的诊断信息并通过网 络将诊断信息传递给服务端程序；

步骤3、服务端程序依据获取的诊断信息和故障诊断与修复知识库，进行 故障诊断与修复决策以产生决策命令并将决策命令通过网络传递给客户端代理 程序；

步骤4、客户端代理程序执行决策命令，实现软件故障的诊断与修复。

步骤1具体包括以下步骤：

步骤1.1、将已解决故障的故障特征、故障原因、故障维修方法表示为计算 机内部格式，形成故障案例库录入故障诊断与修复知识库中；

故障诊断与修复知识库中包含两类知识：采用案例表示的用户经验知识和 采用规则表示的领域专家经验知识。基于案例的故障诊断借鉴人类处理问题的 方式，运用以前积累的用户经验直接求解问题。首先总结已解决的故障形成案 例并按照一定的格式存储于案例库，当有新的诊断任务时，检索案例库，若能 匹配相关案例，则输出诊断结果，否则对该故障采取基于规则的诊断方法进行 处理，通过基于规则的诊断方法得到的诊断结果经规范化处理后又可作为新的 案例添加到案例库中。

步骤1.2、将被诊断软件系统的软件故障领域专家经验知识以产生式规则的 形式进行描述，形成故障诊断规则库录入故障诊断与修复知识库中。

步骤1.1具体包括以下步骤：

步骤1.1.1、采用数据库表作为案例的计算机内部存储格式，包括案例信息 表、故障信息表、故障构件表、征兆信息表、案例解释表、维修步骤表和附件 表；

步骤1.1.2、案例信息表由案例名称、案例编号和案例说明组成；

步骤1.1.3、故障信息表由故障编号、故障名称、故障类别和故障等级组成；

步骤1.1.4、故障构件表由序号、构件类型、构件名称、构件前缀和构件描 述组成；

步骤1.1.5、征兆信息表由征兆描述、征兆类别、征兆值和征兆权重组成；

步骤1.1.6、案例解释表由故障现象、故障原因、解决措施和维修建议组成；

步骤1.1.7、维修步骤表由操作类别、操作序号、操作参数和操作时间组成；

步骤1.1.8、附件表由资源编号、资源类别和资源数据组成。

步骤1.2具体包括以下步骤：

步骤1.2.1、将被诊断软件系统的软件故障领域专家经验知识抽象为一系列 的因果链；

因果链是指有序的事件序列，因果链之中的任何一个事件都将引起下一事 件的发生。软件故障诊断领域的因果链是由基本故障节点、基本故障的直接影 响节点，以及后续的一系列间接影响节点组成的一条链。对应有关探寻故障原 因的过程，成语“顺藤摸瓜”中的“藤”指的就是因果链，而“瓜”则指的是 根本原因，即基本故障节点。以某格式化数据通信软件的故障诊断为例，其某 一故障诊断因果链描述如下：

“Oracle监听服务没有正常启动”引起“数据库服务没有正常启动”；

“数据库服务没有正常启动”引起“格式化数据通信软件不能正常连接数 据库”；

“格式化数据通信软件不能正常连接数据库”引起“格式化数据通信软件 不能正常启动”。

步骤1.2.2、将因果链描述为直观的IF-THEN产生式形式。

产生式规则是一种被广泛使用的知识表示方法，主要用于描述有关问题的 状态转移、性质变化以及因果关系等过程性知识。每一条产生式规则表示一个 因果关系，用直观的IF-THEN方式可表达为：

IF<条件1>AND（OR）<条件2>AND（OR）<条件N>THEN<结论>

规则的前提部分对应因果关系的原因，既可以是单一原因，也可以是原因 的组合形式，结论对应因果关系的结果。

优选地，服务端程序完成被诊断软件系统软件构件的状态监控、诊断决策、 维修决策、知识库管理以及人机交互等功能。

为了尽量减少软件故障诊断系统对被测软件系统的影响，软件故障诊断服 务端程序部署在一台独立于被测软件系统的计算机上，该计算机通过局域网接 入被测软件系统网络。服务端程序完成的各项具体功能包括：

状态监控：服务端程序通过客户端代理程序收集被诊断软件系统每台计算 机上的软件构件运行信息，分析被诊断软件系统中构件间的依赖关系，并将软 件构件运行信息以图形和表格的形式实时进行显示。

诊断决策：服务端程序通过分析收集到的软件故障诊断信息，对被诊断软 件系统的故障模式进行分类识别，并根据现有的知识和一定的推理机制推断出 其故障所在。

维修决策：服务端程序根据故障诊断决策过程中分析得到的故障位置、可 能的原因解释以及所需要的维修保障资源进行维修决策控制。

知识库管理：完成对故障诊断知识库的编辑、检索、更新、导入和导出等 功能，包括案例库的管理和规则库的管理。

人机交互：提供案例录入编辑、规则录入编辑、依赖分析、被诊断软件系 统状态监控、诊断和修复信息显示等功能的人机交互界面。

优选地，客户端代理程序以开机自动运行的后台程序形式部署在被诊断软 件系统的每台计算机上，完成本机软件构件的诊断信息收集和故障修复功能。

客户端代理程序获取的诊断信息包括软件安装部署信息、服务程序运行信 息、进程运行信息、数据库信息、CPU和内存使用信息以及其他各种资源使用 信息等。客户端代理程序启动时创建一个网络监听运行线程，并在该线程中接 收处理来自服务端程序的各种故障修复命令，包括：文件修复命令、服务修复 命令、进程修复命令、构件修复命令、控件修复命令和系统重启命令等。

步骤2具体如图2，包括以下步骤：

步骤2.1、客户端代理程序获取本机软件构件的安装部署信息，将安装部署 信息保存为xml格式文件，然后通过TCP协议将包含安装部署信息的xml格式 文件发送给服务端程序；

客户端代理程序获取的本机软件构件安装部署信息由ip地址、机器名、是 否为服务器和安装的软件构件信息组成，其中软件构件信息包括：构件名称、 版本、制作时间、构件类型、作者、本机依赖的构件列表、网络依赖的构件列 表、可能产生冲突的构件列表以及描述等。考虑到同一台计算机上可能安装的 软件构件较多，本机软件构件安装部署信息获取后首先被保存为xml文件，然 后通过TCP协议将该xml文件发送给服务端程序，服务端程序综合各客户端代 理获取的本机软件构件安装部署信息，形成整个被诊断软件系统的软件构件安 装部署信息和依赖模型。

步骤2.2、客户端代理程序获取本机服务运行信息，将服务运行信息保存为 xml格式文件，然后通过TCP协议将包含服务运行信息的xml格式文件发送给 服务端程序；

“服务”是一些运行在操作系统下用户环境以外的程序，它不同于一般的 可执行程序，它不需要系统登录便可以运行，以完成某些特定功能。对于某些 复杂软件系统来说，许多构件都以服务的形式运行，服务信息获取是诊断信息 获取的重要内容之一。服务信息获取即服务信息的枚举，获取的服务信息包括： 服务名称、显示名称、服务程序的路径、服务描述信息、服务类型、启动类型、 出错控制、服务的当前运行状态等。服务的可能运行状态包括：“已停止”、“正 在启动”、“正在停止”、“已启动”、“正在继续”、“正在暂停”、“暂停”等。考 虑到同一台计算机上运行的服务程序较多，服务运行信息获取后首先被保存为 xml文件，然后通过TCP协议将该xml文件发送给服务端程序。

步骤2.3、客户端代理程序获取本机进程运行信息，将进程运行信息保存为 xml格式文件，然后通过TCP协议将包含进程运行信息的xml格式文件发送给 服务端程序；

进程是计算机程序运行的基本单位，是操作系统中的一个核心概念，它是 对正在运行程序的一个抽象，一个进程就是一个正在运行的程序。为了区分各 个不同的进程，操作系统给每一个进程分配一个ID以便识别。进程信息获取就 是通过一定的方法获得当前系统运行的所有进程的ID，进而根据进程ID获得 和进程相关的其他信息，包括进程的CPU和内存占用率、进程加载的DLL模 块、进程所创建的线程数以及进程所对应的映像名称等。考虑到同一台计算机 上运行的进程较多，进程运行信息获取后首先被保存为xml文件，然后通过TCP 协议将该xml文件发送给服务端程序。

步骤2.4、客户端代理程序获取本机数据库信息，然后通过UDP协议将数 据库信息发送给服务端程序；

客户端代理程序获取的本机数据库信息包括：数据库的最大连接数、当前 连接数、数据库空间使用情况、数据库各项配置参数以及执行指定SQL语句的 结果等。获取到的数据库信息通过UDP协议发送给服务端程序。

步骤2.5、客户端代理程序获取本机CPU和内存使用信息，然后通过UDP 协议将CPU和内存使用信息发送给服务端程序；

客户端代理程序获取的本机CPU和内存使用信息包括：总体CPU使用率、 总体内存使用率、客户端代理CPU使用率和客户端代理内存使用率。获取到的 CPU和内存使用信息通过UDP协议发送给服务端程序。

步骤3具体如图3，包括以下步骤：

步骤3.1、在所述故障诊断与修复知识库中进行案例检索，判断是否存在匹 配的案例，如果判断的结果为是，则基于所述故障诊断与修复知识库中的维修 步骤表产生所述决策命令以进行故障修复，否则执行步骤3.2；

步骤3.2、激活基于规则的软件故障诊断与修复。

步骤3.1具体如图4，包括以下步骤：

步骤3.1.1、等待用户输入待检故障的案例检索条件；

步骤3.1.2、计算案例检索条件用户输入值（即，用户输入的案例检索条件） 和案例库中所有案例的相似性；

案例检索主要通过比较待检故障与案例之间的相似性来实现的，因此案例 检索即故障条件（故障征兆）的相似性比较。假设待检故障的故障征兆向量为X， X＝(x₁,x₂,...x_n)^t，其中x₁,x₂,...x_n为各故障征兆分量，案例库第j个案例的故障征兆向 量为Y_j＝(y_j1,y_j2,...y_jn)^t，则当待检故障和案例的征兆向量的元素数量相等时可采用 如下公式计算相似性：

${\delta }_h(A,B)=1-\underset{i=1}{\overset{n}{\Sigma }}{w}_i|A\left(x_i\right)-B\left(x_i\right)|.$

其中，w_i为第i个征兆的权值，重要性越大其值越大，A(x_i)、B(x_i)分别为A、 B的第i个征兆分量。当待检故障和案例的征兆向量的元素数量不等采用如下公 式计算相似性：

${\delta }_h(X,Y)=1-\underset{i=1}{\overset{p=\min (n,m)}{\Sigma }}{w}_i|X\left(i\right)-Y_j\left(i\right)|$

式中X(i)表示待检故障征兆向量的第i个元素，Y_j(i)表示案例库第j个案例的 征兆向量的第i个元素，n为向量X元素的个数，m为向量Y元素的个数， p＝min(n,m)取n、m两者之最小值。在案例检索时可首先采用上述两个公式计算 故障征兆向量X和案例征兆向量Y的相似性，只要其相似度大于某一设定阈值， 则认为案例已匹配。

步骤3.1.3、将相似性从高到低进行排序；

步骤3.1.4、判断是否存在相似性大于输出阈值的案例，如果判断的结果为 是，则执行步骤3.1.6，否则执行步骤3.1.5；

步骤3.1.5、返回案例匹配失败；

步骤3.1.6、案例匹配成功，依据具有最大相似性的案例的维修步骤表进行 故障修复。

步骤3.1.6具体如图5，包括以下步骤：

步骤3.1.6.1、创建基于案例的故障维修线程；

步骤3.1.6.2、将案例库维修步骤表中与案例故障编号相关的维修步骤依据 操作序号进行排序；

步骤3.1.6.3、依据顺序依次取出每个维修步骤的详细信息，并根据操作类 别和操作参数通过网络向客户端代理程序发送相应的维修动作命令；

每个维修步骤的详细信息包括操作类别、操作参数、操作时间和相应的资 源。维修步骤详细信息存放在案例库的维修步骤表和附件表中，维修步骤可根 据被诊断软件系统的特点在服务端程序中进行增加和编辑。系统支持的基本维 修步骤包括：文件拷贝、文件修改、停止服务、启动服务、重启服务、启动进 程、停止进程、重启进程、构件卸载、构件安装、构件重装、控件注册、控件 注消、SQL脚本执行和系统重启等。

步骤3.1.6.4、使用维修步骤中的操作时间作为维修动作处理的最大等待时 间，等待客户端代理程序返回维修结果；

步骤3.1.6.5、判断是否维修结果已获取或超时，如果判断的结果为是，则 执行步骤3.1.6.6，否则执行步骤3.1.6.4；

步骤3.1.6.6、判断是否所有的维修步骤都已处理完成，如果判断的结果为 是，则执行步骤3.1.6.7，否则执行步骤3.1.6.3；

步骤3.1.6.7、结束基于案例的故障维修线程。

步骤3.2包括以下步骤：

步骤3.2.1、进行基于规则的故障诊断；

步骤3.2.2、收集基于规则的故障诊断过程中产生的维修步骤；

步骤3.2.3、依据维修步骤进行故障修复。

步骤3.2.1具体如图6，包括以下步骤：

步骤3.2.1.1、创建基于规则的故障诊断线程；

步骤3.2.1.2、载入软件故障诊断规则描述文件；

软件故障诊断规则的具体格式如下：

(defrule<规则名>[<说明>]

<模式1><模式2>…<模式i>；左部，等价于IF后的内容

=>

<行为1><行为2>…<行为j>)；右部，等价于THEN后的内容

<规则名>用符号字段代替，如果输入的规则名与一个已存在的规则同名， 则新的规则会代替旧的规则；<模式>用一个或多个约束代替。

步骤3.2.1.3、依据规则文件创建并显示用户交互界面，并在用户交互界面 上显示用户交互提示信息；

步骤3.2.1.4、等待用户输入交互信息；

步骤3.2.1.5、判断交互信息是否已经输入，如果判断的结果为是，则执行 步骤3.2.1.6，否者执行步骤3.2.1.4；

步骤3.2.1.6、依据规则文件执行诊断操作，通过网络向客户端代理程序发 送相应的诊断命令；

依据规则文件执行诊断操作过程可分为4个循环的阶段：模式匹配、冲突 消解、激活规则、动作。具体为：以用户提供的已知故障现象作为初始事实， 搜索规则库中前件与之匹配的规则；激活匹配到的规则并执行规则后件中的诊 断动作产生新的事实；基于新的事实重新寻匹配规则库并激活规则，如此反复 直至搜寻完毕。所谓的冲突消解指的是：当某一时刻出现了激活多条规则时， 选择优先级最高规则进行触发。

步骤3.2.1.7、等待客户端代理程序返回诊断结果；

步骤3.2.1.8、判断是否诊断结果已获取或超时，如果判断的结果为是，则 执行步骤3.2.1.9，否则执行步骤3.2.1.7；

步骤3.2.1.9、依据诊断结果和规则文件产生维修步骤；

步骤3.2.1.10、判断是否还存在可执行的规则，如果判断的结果为是，则执 行步骤3.2.1.3，否则执行步骤3.2.1.11；

步骤3.2.1.11、结束基于规则的故障诊断线程。

步骤3.2.3具体如图7，包括以下步骤：

步骤3.2.3.1、创建故障维修线程；

步骤3.2.3.2、取出每个维修步骤的详细信息，并根据操作类别和操作参数 通过网络向客户端代理程序发送相应的维修动作命令；

步骤3.2.3.3、使用维修步骤中的操作时间作为维修动作处理的最大等待时 间，等待客户端代理程序返回维修结果；

步骤3.2.3.4、判断是否维修结果已获取或超时，如果判断的结果为是，则 执行步骤3.2.3.5，否则执行步骤3.2.3.3；

步骤3.2.3.5、判断是否所有的维修步骤都已处理完成，如果判断的结果为 是，则执行步骤3.2.3.6，否则执行步骤3.2.3.2；

步骤3.2.3.6、结束故障维修线程。