基于XAF框架的盾构机故障诊断系统设计与开发

2013-11-06屈剑平潘舒眉

机械设计与制造工程 2013年6期

赵炯，屈剑平，周杰，潘舒眉

(同济大学机械电子工程研究所，上海 201804)

随着计算机在社会各个领域的广泛应用，对计算机各类软件的需求也越来越大，开发人员为了开发合适的软件废寝忘食地工作，但往往却在重复的编码工作中消耗了精力。尽管各个领域需要的软件差别很大，但基本都包括了数据库操作和用户界面的设计，而这两部分的开发很可能就是降低开发效率的原因。

地铁盾构是一种挖掘地铁隧道的专用典型复杂机电液一体化设备。它本身结构十分复杂，故障频率较高，所以为它开发的故障诊断系统也很复杂，需要的开发周期也较长，为了提高盾构机故障诊断系统的开发效率和软件性能，必须选用一种开发框架来减少重复开发。

1 盾构机故障诊断系统介绍

本盾构机故障诊断与维护系统以盾构关键部件及其施工行为作为研究对象，根据各工作机构的功能、原理以及历史故障统计记录，分析其危害性与分布状况，剖析故障发生的原因和机理，研究状态信息的实时获取技术，建立嵌入式盾构施工状态信息监测单元。同时，结合故障情况，有针对性地制定合理有效的维修计划，并及时指导未来施工。

盾构机故障诊断系统结构分为6个部分，如图1所示。

a.数据采集:实时监测各测点的测量值和数据状态。本系统的原始数据来源是经PLC采集并处理后的数据，经UDP的方式接收。系统所得数据与盾构上原有的监测系统显示数据同步，为最终显示数据，因此不需再进行数据处理。

b.状态监测:将数据根据上下限等方法进行实时判断，实现对设备工作状态的实时监测;当发生警告或报警时，记录数据。

c.健康评估:利用不同的诊断方法对设备进行诊断，判断设备故障原因及严重程度，并记录诊断结果。

d.预测:通过曲线拟合、时间序列分析等方法，预测盾构或某零部件的剩余有效工作时间与其未来可能发生的故障时间、故障发生位置、故障类型。

e.决策支持:对盾构进行基本工况统计，并根据不同的故障形式选取维修策略，合理安排设备未来的维修时间。

f.人机界面:为用户提供图形化操作界面。

图1 盾构机故障诊断系统结构

2 基于XAF框架的盾构机故障诊断系统数据库设计

建立基于状态维护的盾构故障诊断系统是一个复杂的系统工程，因此必须构建工作性能良好的系统数据库，以保证整个系统的正常工作，从而使盾构故障诊断系统能准确、快速地对各种故障状态做出诊断，预防或消除故障，合理地指导设备的运行，提高设备的可靠性和安全性。

2.1 数据库设计构思

根据系统结构，数据库的主要任务需求为:

a.PLC将采集到的数据打包成400字节大小的UDP数据包，每3s传送一次给故障诊断系统。因此，系统需接收每3s传输的UDP数据包并按PLC地址顺序存储。

b.在线实时监测盾构各部件的状态，实现对超过阈值数据的报警。

c.实现对盾构整体或某零部件在某一特定的时间段内的健康诊断与评估。

d.实现对盾构整体或某零部件的未来状态的预测。

e.根据盾构或某零部件健康诊断与预测的结果，提出合理的维护计划。

f.查看目前盾构上的零部件、传感器、位置等信息以及对各参数的及时调整。

g.查询相关操作人员的信息。

针对数据库的需求分析，需要对数据库进行相应的设计。本系统采用E－R图(实体－联系图)进行设计，如图2所示。

图2 盾构机故障诊断系统E－R图

根据盾构机故障诊断系统的设计构思，数据表的设计可以分成三大部分:盾构公共信息、诊断与维护信息、人员信息。其中，公共信息是盾构的固定信息，包含盾构机信息、零部件信息、传感器信息、设备位置信息和分析方法信息等;诊断与维护信息是系统进行故障诊断各阶段的相关内容，包括数据采集信息及状态监测、健康评估、预测与决策支持的结果信息;人员信息包括对系统进行操作的人员的个人信息、权限信息及登录情况。表1是盾构机故障诊断数据库的主要数据表。

2.2 eXpressApp Framework应用程序开发框架

在按照数据库设计构思实现盾构机故障诊断系统的数据库时使用了DevExpress eXpressApp Framework(以下简称 XAF)[1]开发框架，XAF 是DEV公司开发的商业应用程序快速开发框架。它基于MVC设计模式[2]，能帮助开发人员在短期内完成高质量的项目程序。

表1 数据库主要数据表

图3所示是XAF的框架结构图，其数据持久层位于结构的底端，它隐藏了数据管理细节。不需要处理任何数据库管理系统或使用ADO.NET来访问数据。XAF提供了eXpress Persistent Object(简称XPO)[3]工具来进行数据管理。XPO是基于对象关系模型的工具，它能够在流行的数据库管理系统中轻松地访问或存储数据，使得操作者不用关心数据的存取具体是怎样进行的。

图3 XAF框架结构

在XAF结构的顶层是用户界面层，在快速开发用户界面方面，XAF使用Data－to－UI算法，根据创建的数据类，即XPO类自动生成用户界面，这意味着一旦完成了故障诊断系统的数据库设计，整个系统的大部分界面都已经自动生成。

而XAF结构的中间是逻辑控制层，盾构机故障诊断的所有业务逻辑都位于该层中。

2.3 使用XAF框架建立数据表

在XAF框架下实现数据库时，脱离了具体的数据库引擎，直接进行业务类的定义，在具体的数据库中生成对应的数据表就交给XAF的映射工具去完成。以盾构机表为例，盾构机表(Shield表)用于存储盾构机相关的信息，主要字段包括序号Shield_ID，盾构机型号Shield_Model，盾构机名称Shield_Name和盾构机掘进工作所处的地理位置信息Shield_Location，见表2。另外，由于一台盾构机

表2 盾构机表定义

包含多个零部件，故盾构机和零部件表(Part)是1∶n的关系。

利用XAF定义的盾构机类的定义如图4所示。

图4 盾构机表、零件表定义

盾构机类继承了XPLiteObject类，它会自动持久化到数据库。类中定义的属性或成员会在数据表中映射为对应的数据表字段，如盾构机类的Shiled_Name映射数据表中为nvarchar(50)类型的Shiled_Name字段。而类中以AssociationAttribute修饰的特性会映射为数据表间的关系，如盾构机和零部件表被映射为1对多关系，1的一边如盾构机表中含有零部件表的集合(XPCollection)，n的一边如零部件表持有所属盾构机的唯一对象。图5所示是XAF在MS SQL SERVER2008数据库中自动生成的数据库的关系图。

图5 盾构机表和零部件表1∶n关系

在完成全部类定义后，系统就在数据库中创建整个数据库架构，其中的数据表的定义和关系与设计的E－R图完全重合。

2.4 基于零件树的故障诊断

盾构机属于大型复杂机械，总共包含了数百个零部件，对盾构机进行故障诊断也就是对所有零部件的一个遍历，对零部件应用合适的算法，得出分析结果并组织成报表。所以在故障诊断系统中必须对所有零部件选择合适的组织形式，才能保证故障诊断系统的性能。在本系统中，模仿盾构机零部件从属结构，以零件树的形式组织所有零部件，如图6所示。

图6 盾构机零件树

从图6中可以看出，整个盾构机的零部件按照从属结构组成以盾构机为树根的倒立树结构，从盾构机分支出刀盘、推进、铰接等子零部件系统，这些子零部件系统又可以拆分成更小一级的零部件，从大到小将盾构机众多的零部件有机地组织起来。

在传统系统设计中，如果要在系统中表示这种零件树结构只能手动将数据库的记录不断转化为需要的零件树节点。但使用XAF工具将数据库进行抽象后，零部件以Part对象的方式直接存在于系统中，而零件树之间的从属关系也直接表现为对象间的引用。从代码1可以看出，一个零部件包含的所有子级部件以对象集合(Parts)的形式被引用，经过这样的抽象后，系统的逻辑和设计完全贴合，没有冗余的逻辑转换。

在盾构机故障诊断系统中，不论是状态监测还是健康评估，都是以零部件为核心进行分析。在盾构机故障诊断系统中，主要使用了从上往下和从下往上两种零部件检索方式。

在进行状态监测时，根据传感器数据，如果监测到千斤顶1出现故障，那么利用盾构机零部件树上千斤顶1的上下从属关系，就可以得到千斤顶1的子部件集合，进行下级部件的仔细排查，逐级往下检查引发故障的具体零部件。

在对盾构机进行寿命预测分析时，采用了从下往上的寿命预测，取下级子部件集合的最短寿命，根据零部件树进行上溯，不断分析计算盾构机上级零部件的寿命，从而可以对盾构机不同级别的系统进行寿命的预测，甚至预测出整台盾构机的寿命。

3 性能分析

基于XAF框架进行盾构机故障诊断系统的设计有设计逻辑清晰、系统结构分层明确等优点，但是对于盾构机这种大型设备进行的诊断，必须要考虑系统的运行性能。盾构机故障诊断系统会频繁地访问数据库零部件数据，并且会由零部件衍生访问其他如传感器数据配置数据等等，在诊断的同时还会对数据库做出一定更改，整个过程中涉及到的数据量非常大，所以需要对系统性能进行一个对比评估以决定系统的适用性。

在Windows732位系统上，系统的内存是4GB，主频3GHz。使用的数据库是Microsofot SQL Server2008，数据库服务器内含有XAF创建的盾构机故障诊断数据表。为了进行测试，在该数据库中添加了10万条盾构机记录及100万条零部件记录。在相同的查询条件下，使用 ADO.NET[4]、LinqtoEntity、XAF三种技术分别访问数据库，然后比较它们的访问时间，从而判断每种技术的时间性能。分析结果如图7所示。

图7所示横坐标是三种技术的三类查询情况:简单查找、复杂查找遍历、查找并修改。纵坐标是查找得出相同结果的时间，以ms为单位，并且为了清楚显示结果选取了不均匀刻度。

由图7可以看出，LinqtoEntity[5]框架尽管也提供了面向对象的访问数据库方法，提高了开发速度，但它在进行大量数据的复杂查找时，性能降低得很严重。而在三种查询情况中基于XAF开发的诊断系统的性能是最好的。