基于SOA的设备远程监测与故障诊断系统体系结构研究

杨 斌，张卫冬，伍章明，张利欣

(1.北京科技大学 国家材料服役安全科学中心，北京 100083;2.阿斯顿大学 工程与应用科学学院，英国 伯明翰)

设备远程监测与故障诊断系统，即利用现代化通信技术实现异地监测与诊断的行为。通过设备故障诊断技术与分布式计算机技术相结合，一方面在企业内部建立状态监测服务器，在关键设备上安装监测点，将实时采集的数据存入服务器;另一方面在技术力量较强的高校、研究所建立相应的故障诊断中心，设立故障诊断服务器，随时为企业提供远程技术支持等服务，在企业和科研院所之间形成一个跨越地理位置的互联诊断网络。当现场设备运行出现异常，其状态监测服务器便会向远方的诊断分析服务器发出诊断请求，并可通过各种通讯方式向分布在不同区域的专家发出请求，在短时间内启动网内诊断资源，实现对设备故障的早期诊断和及时维修［1，2］。

在设备远程监测与故障诊断系统中，一方面随着各种信息和计算机技术(如CORBA、COM、Web Service、XML、P2P等)的发展，这些技术在设备远程监测与故障诊断系统中得到广泛应用，分布式软件、应用集成平台、各种语言和协议等在应用中的复杂性问题变得日益突出;另一方面目前国内的大型企业(如石化、钢铁冶金、电力等)内部都拥有不同规模、不同平台、面向不同用户、在线或离线的监测系统，每套监测系统都拥有独特的数据存储方式、数据格式、诊断方法和诊断规则。由于运行时间长短不同，每套系统积累的数据和资源也大不相同。这些数据和资源对于企业实现预知维修，减少故障停机次数，提高生产效率和经济效益有着不可估量的价值。但现有的监测系统很少能将这些数据和资源进行充分整合和利用，很多企业甚至不得不将这些数据抛弃而造成了资源和资金的极大浪费。

因此，针对现有的监测与诊断系统，如何进行数据与资源的整合以及解决系统中的异构和复杂性问题，就显得十分重要。本论文提出了一种面向服务(Service-Oriented Architecture，SOA)［3］的平台架构方案，旨在通过利用SOA的架构思想为企业构建一个可扩展、易维护、松耦合的设备远程监测与故障诊断平台，从而实现对各类监测与诊断资源、数据和方法的整合以及对未来新的监测技术、监测手段和诊断方法的持续支持。

1 SOA的核心思想及其服务模型

1.1 核心思想

面向SOA的架构是一种设计方式，指导着业务服务在其生命周期中包括创建和使用的各个方面。SOA也是一种定义和提供信息结构的方式，它允许不同应用相互交换数据、参与业务流程，无论它们使用的是何种操作系统或者采用了何种编程语言。

现代的设备远程监测与故障诊断系统大多是利用计算机网络构成的分布式信息系统。复杂性是信息系统必须面对的一个重要现实，无论是构建新应用、替换现有应用，还是处理各种维护与改进需要，都需要处理各种复杂状况。面向服务的架构和面向服务的开发通过使用公共编程接口及互操作协议，降低了信息系统的复杂性，具有可重用性高的特点。公共编程接口统一了应用(服务和系统)的使用方式，而通过使用公共编程接口，可以很轻松的实现、替换和更新系统。

基于SOA的设备远程监测与故障诊断系统并不是一个全新的事物，事实上在基于CORBA的系统［5］中就有很多部署都是面向服务的架构，其新颖之处在于SOA能够混搭各种执行环境、服务接口与执行技术明确分离，并采用一致的架构方式将它们以“松耦合”的方式结合起来。然而，先前的大多数监测与诊断系统，都是基于单一的执行环境的“紧耦合”系统。

SOA主要是通过文本文件来实现服务与执行环境的分离，而且分离得更明确，传统的接口实现没有考虑这种“松散的”分离，因为它会影响效率。随着计算机的硬件性能不断提高，这种影响已越来越小，而如何在信息系统中获得更强的互操作性远比效率问题更为重要。

因此，构建基于SOA的设备远程监测与故障诊断系统，其本质是如何通过以文本文件方式描述的公共编程接口、服务以及服务间的互操作协议把不同“粒度”的监测与诊断服务进行整合，从而实现、替换和更新系统［4］。

1.2 服务模型

服务是由它所支持的消息交换模式所定义的。消息中包含的数据应具有相应的模式，用于在服务请求者与服务提供者之间建立描述。同时，其它一些元数据则描述了服务的网络地址、所支持的操作，以及对可靠性、安全性及事务性方面的要求。

通常的服务包含服务描述、服务实现和服务映射三个方面。服务的请求者通过服务描述和服务映射层可以获取服务实现，而同时服务实现可能会调用另一个服务的功能。

SOA及服务中的元数据即服务的描述信息，元数据通常包含以下几个部分:①服务的名称，服务的唯一标识;②消息数据，用于定义消息中的数据类型、数据结构以及消息间的交换模式;③地址数据，服务名称的网络地址，用于服务的寻址;④服务质量，包含安全性、可靠性、事务性等服务策略。

任何能够提供服务支持的组件或系统都可以成为服务实现。服务实现负责实现各种Web服务规范中定义的Web服务模型。服务的定义中一个重要方面是服务描述与服务实现是分开的。一个服务描述可以有多个不同的服务实现与之关联，服务描述通过一个服务映射实现与执行环境分离。服务映射负责接受消息、转换数据以及传输数据。

本文所阐述的系统正是以这种服务抽象模型，对监测与诊断系统中各类应用进行不同层次、不同粒度的抽象，从而将整个监测与诊断的系统细分为许多个“松耦合”的服务实现、服务描述和服务映射。这种方式构建的监测与诊断系的优势是:易于访问不同类型的服务和使用各种功能模块，如新开发的服务，整合已有的应用系统以及使用由第三方提供的服务。

2 面向SOA的远程监测与故障诊断系统

2.1 远程监测与故障诊断系统的功能抽象

面向SOA的远程监测与故障诊断系统不同于传统的分布式架构系统［6－8］，其主要区别在于服务的抽象和系统的松耦合性，可以根据业务逻辑和功能需求将系统抽象为不同层次、不同粒度的服务。通过这些服务的组合和互操作构建整个系统，具有更好的可重构性和扩展性。因此，在设计面向SOA的远程监测与故障诊断系统之前必须对业务逻辑和功能需求进行多层次抽象。

远程监测系统主要有两大功能:一方面是负责将现场前端采集系统获取的信号数据，经过处理、抽取和分析实时传向监测客户端，在监测客户端以各种图表方式实时显示设备运行状态;另一方面是将这些信号数据存入数据库，提供数据查询功能，展示设备的历史运行状态。因此远程监测系统可以抽象为以下几个方面:① 信号的获取，即前端采集系统实时获取各类监测信号;② 信号的处理与分析，包括信号的降噪、计算特征值、报警状态判断和频谱分析等;③ 信号的显示，通过波形曲线、棒图和数据表格等多种方式显示信号;④ 信号的存储，将信号分类存入数据库以供查询;⑤信号的查询，通常包含某个时间点的信号细节查询和某个时间段的变化趋势等方面的查询。

故障诊断系统主要是利用实时或历史数据，通过各种诊断方法设备运行状况进行诊断。同时，系统可以根据用户的请求对设备的运行状态信号进行分析，给出诊断结果。在交互式诊断中用户也可以向远程诊断中心提出更高级的诊断请求(如专家诊断)，或将自己的诊断结果提交到诊断中心，作为典型诊断案例。因此远程故障诊断系统可以抽象为以下几个方面:①诊断流程和规则，无论是用户的自助诊断还是交互式诊断都需要基于特定设备的一些诊断流程和规则;②诊断方法，如目前常用的模糊推理和故障树等方法;③知识库，不同的设备其诊断机理通常会有较大差异，需要利用知识库提供多种故障诊断规则、分析规则和故障排除规则;④ 案例库，设备的故障诊断是诊断经验十分重要的实践科学，建立典型案例库的目的就是不断积累实际的诊断经验。

2.2 远程监测与故障诊断系统体系结构

在对监测和诊断的业务逻辑和功能需求分析和抽象的基础上，结合SOA的设计思想，可以将整个体系结构划分为基础数据源层、细粒度的功能模块和粗粒度服务层。基础数据源层主要是系统的数据来源，设备监测和诊断的基础都是对测点信号数据的显示和分析。细粒度功能服务层主要通过监测或诊断的业务逻辑来抽象出通用的细粒度功能模块，以便通过这些模块的组合和集成实现更粗粒度的服务。粗粒度服务层即提供面向用户的功能服务。同时，这些功能服务通过企业服务总线［9］向企业级或远程级的用户发布。远程监测与故障诊断系统的体系结构如图1所示。

图1 状态监测与诊断系统的软件体系结构Fig.1 Software Architecture of conditions monitoring and fault diagnosis

2.3 基础数据源和细粒度功能模块设计

2.3.1 信号采集适配器

信号采集适配器负责现场前端信号采集系统与监测诊断系统中各功能服务之间的数据连接。通常企业中存在多种前端信号采集系统所提供的数据格式、采集方式都不相同。因此，信息采集适配器主要是为了屏蔽这种差异性，为后面的各个服务功能提供统一的信号数据获取接口。信号采集适配器的主要功能只是对通讯协议和数据格式进行统一的转换，并不对信号本身处理。

传统的集中式数据流方式是使用特定的服务器应用程序收集所有前端系统的监测点数据，再通过集中的数据中心向外提供监测数据服务。显然，这种方式的缺陷是集中式数据中心的运行异常或故障将导致整个监测系统的崩溃。与此不同，面向服务的设计使得任何一个数据源本身都可以成为数据服务的提供者和使用者。图2显示了这种既分散又集中的数据流服务方式。

图2 面向服务的监测信号数据流Fig.2 Monitoring signal data stream oriented service

2.3.2 负载均衡与服务调度模块在实时监测系统中，通常会出现有限的计算机资源和大量客户端并发请求之间的矛盾，为了保证这些应用服务的稳定运行，必须在各应用服务中使用负载均衡模块控制客户端的连接和优化计算机的资源分配。权重均衡算法可以根据每个请求(或服务)所需要的不同的处理能力，给每个请求分配不同的权值，当接受相应权值的服务请求时根据服务的权值计算负载状态，可以基本确保服务器和其上服务的稳定运行。因此，权重均衡算法可以作为负载均衡模块的核心算法。

不同于传统的分布式系统客户端程序的请求与服务器程序的相应之间是一一对应的紧耦合联系，在SOA中一个相同的客户端请求在系统中可能存在多个对应的服务的提供者，因此选择一个合适的服务提供者不仅可以加快服务响应速度还可以合理分配计算机资源达到负载均衡的目的。负载均衡与服务调度模块的运行流程如图3所示，负载均衡实际上起到了资源与服务分配的作用，只有分配成功后才能够提交至Web服务，在服务完成后减少当前负载数(释放资源)。

图3 负载均衡模块的运行流程Fig.3 Running flowchart of load balance model

2.3.3 监测系统数据库设计

监测系统数据库的设计原则是便于监测数据的存储和查询，在监测系统中最小的信息单元是测点［10］。因此，本文中根据独立的单一测点作为库表结构的基本单元作为设计和建立数据库的准则。在顶层有一个root数据库，root数据库包含两个表:机组信息表和机组数据库信息表，机组信息表存储了机组的编号、名称、描述、机组简图以及测点分布情况等;机组数据库信息表存储了后续子库(机组数据库)的连接信息和库表结构。root数据库是整个监测系统数据库的入口，设计root数据库可以动态维护后续子库的信息和库表结构，便于扩展。由于各个机组数据库测点及测量值的差异性，因此需要动态创建各个机组数据库。

2.3.4 故障诊断知识库和案例库

故障诊断和推理是一个基于知识与经验的分析过程，因此通常需要根据不同类型的诊断对象(设备)建立完善的知识库与案例库［11］。

故障诊断知识库通常采用多库结构的组织模式:设备信息库、故障征兆库和诊断规则库。这种结构模式可以提高系统工作效率，也便于知识的搜索。各库之间相互独立，某个库的修改不会影响其它库，其结构如图4所示。

图4 诊断知识库层次结构Fig.4 Hierarchical structure of fault diagnosis knowledge base

设备信息库包含设备结构、运行规范和运行参数等信息，是故障诊断重要的背景信息。

对于设备运行中常见的一些故障类型通常会有特定的征兆与之对应，故障征兆库用于存放故障经分类整理后表现出来的征兆，由征兆属性和征兆值组成，对于每个征兆属性通常有若干个征兆值(如振动特性、温度等)。

诊断规则库中的规则分成三组:故障诊断规则组、故障原因分析规则组和故障排除措施规则组，表达形式如下。

故障诊断规则组:［数据，事实］→故障类型;

故障原因分析规则组:［事实，故障类型］→故障原因;

故障消除措施规则组:［事实，故障类型，故障原因］→故障排除指导。

案例库的建立主要是对现有案例的表示、组织与存储［12］。案例的表示必须能够清楚地表达出故障类型、表现形式、因果关系及故障机理，案例组织与存储结构则关系到案例检索的效率。为了使案例库能够方便地进行案例的新增、修改、删除等操作和维护，本文设计了故障案例种类表、故障案例表、故障案例特征表三个关系数据表用于描述案例库的各项信息。故障案例种类表记录了故障案例中的典型案例种类;故障案例表记录了每个案例的详细信息，其中包括故障现象、征兆、解决方法等;故障案例特征表记录对应案例的各特征属性(振动特征量、温度、压力等)的值。

远程监测与故障诊断系统针对上述基础数据源和细粒度功能模块设计，使得整个监测系统具有良好的扩展性，其中信号采集适配器屏蔽了底层数据采集的差异，同时配合灵活的数据库系统设计使得增加新的数据采集模块只需简单配置数据库服务器即可完成。另外，负载均衡与服务调度模块可以灵活应对客户端数量的扩展，均衡系统资源，提高客户端服务的实时性。

2.4 监测系统关键服务设计

2.4.1 测点信息服务

测点信息服务主要包含两类任务，一方面是面向采集适配器为各个测点提供信息的注册与注销，在服务内维护一个所有测点信息的列表，发布的相关接口提供测点信息的添加、删除或更新;另一方面是面向客户端测点信息的各种查询服务。测点信息服务发布的Web Service包含如下6个接口:① 测点注册，注册测点信息，如果测点重合则更新当前测点信息;② 测点注销，删除测点停止同时通知其他服务/模块，停止该测点的相关信息和数据服务;③ 测点更新，更新某个测点的相关信息;④ 单个测点查询，利用测点ID查询相关信息;⑤ 机组测点查询，根据机组名称(或其他唯一标识)查询该机组对应的测点列表;⑥ 全部测点查询，返回系统内所有测点信息。为了方便测点信息的结构本身的扩展与修改，测点信息按照XML规范组织，测点信息文档的根节点是“ROOT”，下一级节点为机组节点，机组节点下一级是该机组拥有测点类型的种类列表(加速度、速度或温度等)。

2.4.2 实时波形数据服务

实时波形数据服务是指向客户端提供信号的实时的原始波形数据和根据对应的原始波形数据计算出的频谱数据。

实时波形数据服务包括两类操作:一类是当实时波形数据服务接收到由监测适配器传来的测点采集数据后，进行缓存并调用信号处理Web Service服务进行频谱计算;另一类是当接收到客户端的实时波形数据请求时，返回缓存的测点采集数据和频谱数据。数据操作流程如图5所示。

图5 实时波形数据服务流程Fig.5 Sevice flowchart of realtime wave data

2.4.3 实时特征值服务

实时特征值服务的实现方式、数据流程与实时波形数据服务完全相同，不同是需要根据接收到的波形数据计算其特征值并传递给客户端。

此外实时特征值服务还有两个附加的功能:①根据计算出的特征值服务判断当前的数据是否超过了预设的报警线，如果超过则需要将对应的数据(原始波形和特征值数据)发送至实时报警数据服务中进行缓存;②将计算出的特征值数据(包含报警状态信息)发送至历史数据库模块进行存储。

2.4.4 测点信号数据存储服务

测点数据存储服务的主要任务是在接收到其它各个服务模块发送来的信号原始数据或特征值数据时调用数据库操作模块进行数据存储。为了能够实现更高效率的数据存储，可以使用存储过程。由于振动信号的波形数据的数据量较大，因此在存储这类数据时需要做特殊的处理。本文引用一种“记录－文件”的方式进行处理，将实际的振动波形数据存储在基于XML规范的数据文件中，同时在数据库中记录该文件的相关信息(即建立文件索引)，便于将来的查询。本文使用XML规范存储数据主要考虑到数据文件格式的可扩展性。

测点数据存储服务属于系统内部服务，因此无需提供外部调用接口，但仍然需要与SOA基础架构有交互服务的操作接口。

2.4.5 历史波形和特征值查询服务

由于历史波形数据存储在特定的数据文件中，因此历史波形查询服务在接收到客户端的查询请求时需要先搜索在数据库中的文件记录，再根据文件的记录信息访问实际的波形数据文件，然后需要调用信号处理Web Service服务计算频谱数据，经过封装后返回给客户端。

在进行历史特征值数据查询时需要提供查询的起始时间和终止时间，即查询的时间跨度。时间跨度短的查询可以直接查询和返回查询结果，但对于时间跨度长的查询，其查询结果和数据将非常庞大，不适合直接使用网络传输。考虑到历史特征值数据查询的应用大多是进行查看数据的历史趋势，因此本文对于大跨度时间的查询进行数据提取，在保证原有数据变化趋势不变的情况下，提取可以表征趋势特征的关键数据点以减少数据量。

趋势数据的提取策略可以有很多种，本文使用定时间段极值提取策略:①首先确定一个定时间段;②然后按照最为重要的特征值(如振动信号的均方根值)将该时间段中的数据描绘为曲线并求出所有的极值点;③最后将得到的极值点作为提取的特征点存储在数据库中。这种提取策略的优势是可以保留所有趋势中的拐点数据，但是需要研究合理的时间段。

2.5 诊断系统关键服务设计

通常对于不同的诊断任务，其诊断难度和故障的严重程度往往差别很大，有的故障可能通过信号频谱分析就可以得到较为准确的结果，而某些较为复杂故障的诊断往往需要领域专家们的协同诊断。因此，在面向服务的监测与诊断系统中分别为不同难度、不同层次的诊断需求提供了三种类型的诊断服务:自助诊断、交互式诊断和专家诊断。

2.5.1 自助诊断服务

自助诊断服务是指用户通过向诊断系统提交故障的描述、故障信号以及其他相关信息后，再选定对应信号分析方法和诊断规则，利用诊断推理机自动获取诊断结果的诊断方式。利用自助诊断服务用户可自主分析、查询设备故障原因，作为诊断参考。自助诊断的流程图如下图6所示。

图6 自助诊断流程图Fig.6 Self-assist diagnosis flowchart

2.5.2 交互式诊断和专家诊断服务

交互式诊断是通过用户和专家交互的方式进行故障诊断。用户提出诊断请求，诊断平台管理员将请求分配给相关的诊断专家，专家做出诊断结论并反馈给用户，用户根据诊断结论对设备做出相应处理，如果处理效果不明显，用户可以进一步将处理结果提供给专家，专家再一次对请求给出诊断结论，此过程可以反复进行，直到用户对诊断结果表示满意为止，完成一次交互式诊断。

专家诊断服务的发起者是请求用户，但用户的请求需要系统管理员验证，只有达到专家诊断的级别的故障案例才能通过验证。管理员根据请求确定参加这次专家会诊的专家列表，将请求发送给这些专家。这些专家根据用户提出的请求信息，通过系统提供的诊断方法，经过分析得出各自的诊断结论。专家会诊的最大优势就是它可以充分利用不同专家的经验，通过相互交流给出结论，避免了交互式诊断中专家独自承担诊断任务带来的片面性，最准确的给出故障的形成原因以及解决方案。

2.5.3 基于SVG的富客户端系统

在普通基于HTML的Web页面上显示实时的数据图表一直是业界的一个难题，除了传统的ActiveX技术和Java Applet技术外，目前成熟的解决方案并不是很多，其中主要的两种解决方法是利用Flash插件和基于SVG的Web矢量图形技术。本课题针对监测系统的功能需求，设计和实现了一套简单的基于SVG技术的Web动态图表组件。

利用SVG技术的实现Web下的动态图表基本原理如下:首先利用 SVG来绘制基本的图表形状，然后通过使用Ajax数据层向Web服务器请求最新的实时数据，当接收到实时数据则再通过JavaScript脚本调用DOM接口动态修改SVG图形，这样就实现了Web下的动态图表。

3 系统实现与验证

为了验证基于SOA的远程监测与故障诊断系统的可行性以及本文所阐述的设计思路和功能模块，设计并实现了基于SOA的远程监测与诊断演示系统。系统开发平台参数如下:Windows XP专业版操作系统，E4300(1.8G)的 CPU，2 G 内存，Web 服务器为 IIS，数据库系统为SQL Server 2005，开发语言为ASP，服务器开发平台为VC 2005。另外，在整个演示系统中模拟了10个监测点的数据，采样频率为2 kHz，整个演示系统的核心部分是SOA运行监测中心，分别包括服务注册中心、服务网关以及消息总线，详见图7部分。下面从SOA运行监测中心、远程监测系统、诊断系统三个方面详细介绍演示系统的运行效果。

图7 SOA运行监测中心的前台界面Fig.7 The front interface of SOA monitoring center

(1)SOA的运行监测中心

SOA的各个功能模块基本上都属于系统“后台”的进程或服务，因此为了使SOA的管理者能够方便地获取这些功能模块的运行状况，这里通过一个SOA的运行监测中心，实时显示SOA的各个功能模块的运行状态。如图7所示，监测中心主要用于显示服务注册中心、服务网关等SOA核心部件的运行状态，同时提供了对系统中各个功能服务进行人工管理的方式。

(2)远程监测系统示例

演示系统中主要提供了基于Web的远程监测系统的客户端，这里以振动信号的实时波形监测(图8)、特征值棒图监测(图9，去掉浏览器部分)为例展示了监测系统运行的效果。可以看出，一方面已经成功地实现了完全基于Web方式的监测界面和操作，另一方面由于和客户端的数据和业务相分离，监测界面的设计与实现十分简单易行，因此将来可以很方便地为实际的应用系统设计更丰富和完善的监测界面。

图8 实时波形监测Fig.8 Realtime wave monitoring

图9 特征值棒图监测Fig.9 Feature bar monitoring

图10 自助诊断前端Web界面Fig.10 The web interface of self-assist diagnosis

(3)诊断系统示例

本文中所述远程故障诊断系统主要提供自助诊断、交互诊断和专家诊断三个模块的服务与功能。以自助诊断为例，其前端界面如图10所示。这些前端界面主要提供了用户与诊断服务的数据交换(用户提交数据，服务结果显示等)。

4 结论

针对目前设备远程监测与故障诊断系统面临着日趋复杂的应用需求和环境，为了在不同的应用平台、不同的开发环境、不同的基础硬件上构建一个分布式部署、松耦合、易扩展的应用平台，本文提出了基于SOA的远程监测与故障系统体系结构。该体系结构利用SOA的设计思想，首先对远程监测与故障诊断系统的业务逻辑和功能需求进行了不同层次、不同粒度的抽象和划分，建立了一个松散耦合的Web服务系统。然后给出了基于SOA的松耦合Web服务的构建方式，使得功能模块的可重用度更高，易于系统的扩展，实现了对分散、异构的监测与诊断系统资源进行有效的整合。最后，本论文开发并实现了一套基于SOA的远程监测与故障诊断系统，验证了整个远程监测与故障诊断系统体系结构的可行性。

［1］韩 捷，张瑞琳.旋转机械故障机理及诊断技术［M］.北京:机械工业出版社，1997.

［2］屈梁生，何正嘉.机械故障诊断学［M］.上海:上海科学技术出版社，1986.

［3］Newcomer E，Lomow G.Understanding SOA with Web Services［M］.Maryland:Addison-Wesley，2005.

［4］郭春燕.基于SOA的企业应用的研究与实现［D］.大连:大连理工大学，2005.

［5］王海峰，徐金梧，杨德斌，等.基于CORBA的分布式远程故障诊断体系［J］.北京科技大学学报，2004，26(2):192－196.

［6］姚宝恒，杨霞菊，佟德纯，等.基于互联网的设备远程监测诊断技术［J］.振动与冲击，2002，21(3):52 －57.

［7］蒋全胜，贾民平.基于Web的连铸旋转塔远程状态监测与诊断系统［J］.东南大学学报，2006，36(3):407 －410.

［8］吴立伟，陈 进，孙卫祥.远程设备监测与诊断系统的DCOM组件设计与实现方法［J］.振动与冲击，2007，26(3):117－120.

［9］Woods D，Mattern T.Enterprise SOA:designing IT for business innovation［M］.Cambridge:O'Reilly，2006.

［10］陈一鸣，陈 进，伍 星，等.基于网络的远程监测和故障诊断系统的数据库系统［J］.振动与冲击，2005，24(6):61－64.

［11］多丽华，杨拥民，陶利民，等.基于层次分析法和与/或树的远程诊断专家系统实现研究［J］.华中科技大学学报，2005，35(4):75 －78.

［12］王 东，刘怀亮，徐国华.案例推理在故障诊断系统中的应用［J］.计算机工程，2003，29(12):10－12.