故障信息标准化描述及网络传输方法研究
2020-11-03陈希祥申宇皓
陈希祥，申宇皓
(湖南信息学院 电子信息学院,长沙 410007)
0 引言
随着科学技术发展，现代工业系统的模块化、网络化、数字化、智能化水平有了很大提升，设备结构也越来越复杂，系统内部存在着复杂关系。系统功能单元故障原因复杂，故障表现出多样性、渐变性、耦合性等特点[1-3]。传统的现场检测与诊断模式已不能满足快速性、实时性等实际需要，开发网络化、信息化故障诊断系统是工业系统故障诊断的发展趋势[4]。网络化故障诊断系统通过传输和处理现场故障信息，将现场人员与远程专家相结合，利用不同的领域知识处理系统，提高故障诊断的准确性和效率。
网络化故障诊断系统的实现包括跨平台、故障信息标准描述、网络传输等关键基础技术。跨平台技术可提高诊断系统在不同操作系统中的部署能力及针对不同开发平台的适应能力，提高检测诊断系统的通用性；故障信息标准描述增强了不同开发平台之间的信息共享能力；网络传输是实现故障检测信息与诊断决策信息远程传输及交互的关键。
在不同研究领域，对诊断方法都进行了大量的研究和讨论[5-7]，然而所开发的系统在跨领域、跨平台和故障信息标准描述方面显得不足，通用性较差，难以实现远程信息分析与故障诊断。通过对比分析，LabVIEW(laboratory virtual instrument engineering workbench)可支持跨平台系统的快速开发[8-10]，而XML(Extensive Markup Language)也支持跨平台信息描述，独立于硬件和软件。将LabVIEW和XML应用于网络化故障诊断系统的开发，可以使系统具有很强的灵活性和通用性[8-12]。因此，本文选择XML实现故障信息的标准描述，以LabVIEW作为开发平台实现系统构建及信息网络传输，从而实现跨平台网络化远程故障诊断系统。文献[11]中给出了在LabVIEW中创建和访问XML文件的基本方法。但是，它对不同类型的信息缺乏灵活性。文献[12]中讨论了在LabVIEW中实现远程数据传输的基本方法。然而，它不能避免数据的丢失。
本文首先给出了系统总体规划，详细介绍了设计过程，然后给出了服务器端和客户端程序的详细设计，用XML描述典型故障模式影响分析信息(FMEA，failure mode effect analysis)。利用VI脚本技术实现程序的动态创建和运行，采用TCP协议实现数据传输，采用供应商和客户模式增强了安全性，避免了数据丢失。最后构建了一个演示仿真系统，讨论仿真试验结果，对本文进行总结。
1 总体方案设计
本节从跨平台、故障信息标准描述、网络传输等方面探讨如何选择和优化相关技术，实现总体设计。
1.1 确定开发平台
跨平台是软件开发中一个重要的概念，是指程序设计语言、应用软件或硬件设备可在多个操作系统中工作。由此可见，跨平台既不依赖于操作系统，也不依赖硬件环境，可提高软件的重用性。
JAVA是SUN公司推出的Java面向对象程序设计语言和Java平台的总称，它利用虚拟机技术实现跨平台，但开发效率不高。LabVIEW是由美国国家仪器(NI)公司推出的重要软件产品，它是一种图形化编程语言，完全支持跨平台，其代码无需更改即可运行于3种常见的操作系统：Windows、Mac OS和Linux。同时，LabVIEW也是一种程序开发环境，可实现系统快速的开发。根据大量统计数据发现，开发同一个大型应用程序，LabVIEW程序员只需花费C程序员1/5的时间。因此，本文选择LabVIEW作为开发平台实现网络化故障诊断演示仿真系统。
1.2 信息描述语言及其实现方法
XML是一种基于文本、使电子文件或信息具有结构性的标记语言，它将可理解的标记和结构化格式应用于保存数据。XML是支持跨平台、依赖于内容的技术，提供统一的方法来描述和交换独立于应用程序或供应商的结构化数据，已经成为数据交换标准，非常适合网络传输，是当今处理分布式结构化文档信息的有力工具。
相比于HTML有一个固定的标记集，XML只提供一个标准，用户可按照这个标准来定义自己专用的标记，所以XML的标记是可以无限扩展的，可用于描述各种应用领域的数据信息，人们可以理解并且计算机可以处理它。因此，选择XML来描述故障信息。
在LabVIEW中实现信息的XML描述有两种方法：一种是LabVIEW模式，另一种是XML解析器。LabVIEW模式根据预定义的XML模式转换数据。简单的几个函数可以完成基本的XML操作。XML解析器是Xerces 2.7，它依赖于DOM(文档对象模型)，提供了许多灵活处理XML数据的功能，但它不支持除英语以外的其他语言。因此，选择xerces 2.7模式来实现故障信息的XML描述，同时，采用了一些技术措施来提高Xerces 2.7模式的灵活性。Xerces 2.7模式中FlattedToXML函数给出字符串的XML转换结果如下：
其中
1.3 常见故障信息及其动态描述方法
故障信息的类型和形式是多种多样的。FMEA是诊断中故障信息的重要来源，对典型故障信息FMEA进行描述和传输，实现总体规划设计的演示验证。通常FMEA信息用FMEA表来表示，明确了系统或设备故障的详细信息，包括名称、功能、故障模式、故障原因、故障影响(局部、进一步、最终影响)、故障检测方法等。
在设计程序时，要能够对标准的FMEA信息进行处理，并使其具有可扩展性。通常FMEA表信息的字段名和内容不是固定的，本文采用动态的方式实现了LabVIEW中常用的表信息的XML描述，将VI脚本技术应用于创建VI、控件、函数、运行程序以及结果输出。VI脚本依赖于本地LabVIEW VI服务器所提供的的服务，客户端则是本地LabVIEW 程序。
1.4 网络通信协议选择
TCP和UDP是两种重要的网络通信协议。TCP定义了两台计算机之间可靠的数据传输格式和方法，其重要特性是提供面向连接的可靠字节流服务。UDP是一种简单的面向数据包的协议虽然UDP的传输速度较高，但其提供的传输服务并非面向连接且是不可靠的。因此，选择TCP作为演示仿真系统的通信协议实现故障信息的传输需要高可靠性，由服务器描述并发送信息，客户机接收和处理信息。
如果客户机以顺序循环的方式接收和处理信息，数据将不能被及时接收，且由于处理数据花费了大量时间，会发生数据丢失。该模式采用队列的数据存储方式，按先进先出(FIFO)方式工作，新元素总是加载队列的末端，而最先取出的数据则是最先进入队列、位于队列首段的数据。因此以该方式进行数据的存取可避免数据遗失。供应商和客户模式利用多个环路并行实现供应商和客户的不同功能，可提高数据传输的安全性。
1.5 总体规划设计
通过以上分析，对演示仿真系统进行规划设计。该仿真系统由服务器端和客户端组成，服务器实现故障信息FMEA的XML描述，并将描述结果传送到网络；而客户端与服务器连接，用于接收服务器传送的网络数据，提取并显示故障信息。
图1 服务器工作流
图2 客户端工作流
图3 服务器与客户端的交互工作流
服务器端和客户端的工作流程分别如图1、图2所示。在服务器中，首先创建一个网络连接，利用XML对故障信息进行描述，并发送到网络中，直到信息全部发送完毕。然后服务器等待，直到客户端接收到最后一组数据信息为止，并关闭网络连接。在客户端，首先打开网络连接，接收网络数据、提取并显示故障信息。服务器和客户端按一定时序同时工作，确保数据信息的发送与接收同步进行，交互的工作流情况如图3所示。
仿真系统技术框架如图4所示。如前所述，整个系统采用LabVIEW开发，支持跨平台。服务器通过XML-LABVIEW模式和VI脚本技术，利用XML实现典型故障信息FMEA的描述，客户端根据供应商和客户模式技术接收网络数据，提取并显示传输的故障信息，两者之间通过TCP协议进行通信。
图4 仿真系统技术框架
2 具体实现方法
本节对总体方案中的关键技术及其实现方法进行探讨。
2.1 服务器
服务器控制面板如图5所示。“FMEA”表显示将要发送的故障信息，“Sending XML”文本框显示FMEA表中数据信息的XML描述结果，“Port”端口控制用于输入TCP通信的端口号，“Sending”指示器用于显示发送状态，“Start”启动按钮用于运行程序。服务器利用XML来描述FMEA的数据信息，并逐条将描述结果发送到网络。
图5 服务器面板
服务器框图如图6所示。框图的外部是响应启动按钮“Start”动作的循环事件结构。图的内部由5个模块组成：1)创建TCP连接;2)XML描述和发送数据;3)发送“发送结束”字符串;4)等待“接收完成”字符串;5)关闭TCP连接。
图6 服务器框图
在第一个模块中，程序创建一个侦听器，等待来自客户端端口上的TCP连接，等待时间为1分钟。在第二个模块中，FMEA表是数据源，由XML逐条记录、逐个字段分别描述，在一条记录被描述并发送到网络之后，开始描述下一条记录。
为满足不同故障信息描述的需要，在LabVIEW中采用VI脚本技术描述FMEA记录中的某一字段。此时，需要创建一个新的VI，如图7所示，以便每个字段的描述结果与第1.2节LabVIEW模式中的示例格式保持一致。面板由两个文本框组成，一个用于输入字段名和字段内容，另一个显示该字段的描述结果。相应的框图由输入文本框的局部变量和Flatted to XML函数组成。
图7 通过VI脚本创建VI
为创建上述VI，采用VI脚本技术设计一个新的VI: Field-XML描述。Field-XML描述框图由“创建VI”、“创建输入控制及局部变量”、“创建函数和连线”、“创建输出控制和连线”、“运行VI及获取结果”等5个模块组成，如图8所示。“创建VI”即创建一个新的面板和一个新的框图。“创建输入控制及局部变量”是为了创建一个文本框，包含面板中的字段名和字段内容，以及框图中的局部变量。“创建函数和连线”用于创建Flatted to XML函数，并将该函数与输入文本框的局部变量连接。“创建输出控制和连线”用于在面板中创建输出文本框，并将输出文本框与Flatted to XML函数连接。“运行VI及获取结果”为了使创建的VI运行并得到最终结果。
图8 VI字段XML描述框图vi
通过VI脚本设计VI是很复杂的。在2 GHz Intel i5 CPU、2 G内存、Windows XP、LabVIEW 2012环境下运行VI将花费更多的时间(约80 ms)。而VI脚本实现了VI设计的自动化，提高了软件的灵活性，可满足不同需求。Field-XML描述VI使用了许多关于VI脚本的属性和方法。鉴于篇幅有限，本文对这些性质和方法未进行详细讨论。
服务器框图中的模块2～4包括发送网络数据和读取网络数据。为方便起见，创建两个VI分别实现上述两个功能，一个是TCP W(Write)，另一个是TCP R(Read)。在这两个VI中，读写的字符串长度需要输入。
在FMEA信息的XML描述全部发送后，在第3个模块中，通过发送“发送结束”字符串帮助客户端识别发送端。在第四个模块中，客户端收到所有数据后，服务器等待从客户机发来的“接收结束”字符串。最后，关闭TCP连接。
2.2 客户端
客户端从网络逐条接收XML记录，提取并显示该记录所包含的故障信息，客户端面板如图9所示。“Receiving XML”文本框用于显示接收到的XML描述记录；“XML File”文本框用于显示保存记录的XML文件；“FMEA”表用于显示从XML描述中提取的故障信息；“Port”端口控制用于输入TCP通信的端口号；“Address”地址控制用于确定网络连接地址，其内容是连接客户端的本地计算机名称。由于客户机使用包含队列的供应商和客户模式，因此“No. of Elements in Queue”一栏显示队列中的元素数；接收指示器“Receiving”显示接收状态；启动按钮“Start”用于运行程序。
图9 客户端面板
客户端如图10～11所示，包括供应商和客户两个独立的循环。供应商循环负责接收网络数据并将数据放入队列，客户循环则负责从队列中提取数据及故障信息。当接收和处理数据的工作是按顺序周期性进行时，由于数据处理时间很长，因此，在供应商和客户模式下数据不完全接收的情况是一般不会发生的。
图10 供应商循环
图11 客户循环
供应商循环的外部是响应开始按钮“Start”动作的循环事件结构。该结构运行之前，需要为后续队列操作创建队列引用，队列名称是XML数据，队列中的元素类型为字符串。循环事件结构框图包括3个模块：1)打开TCP连接；2)接收XML；3)关闭TCP连接。要打开TCP连接，需要端口号和地址，随后，开始接收来自网络的数据。如果接收的数据没有发送完，则数据将显示在接收XML文本框“Receiving XML”中，并插入到队列，以便客户循环从队列中提取故障信息。当数据接收完毕时，表明服务器已将所有数据发送完毕，客户端将项服务器发送“Receiving Over”信号。同时，该字符串将被插入到队列，使用者退出程序，关闭TCP连接。若服务器接收到“Receiving Over”信号时，服务器退出程序，而不必等待客户端处理数据。
在客户循环中，队列中的元素被逐一提取。如果提取的数据未接收完毕，则持续提取故障信息。首先，XML数据被保存为一个“*.xml”文件，以供客户读取。所读取的数据为数组，元素格式与第2.2节中示例相同，这样通过数组操作即可提取故障信息。然而，从“Receiving XML”文本框所示的原始数据中提取信息并不容易，因此可创建一个临时文件“temp.xml”来保存数据。由于需要保存和读取文件，客户的一个循环周期很长，如果采用更复杂的方法来处理数据，循环周期将更长。当数据提取结束时，程序退出客户循环，释放队列引用，并删除临时文件。
2.3 仿真结果
假设在服务器中需要传输20条故障信息记录。服务器和客户端程序在本地计算机上运行，端口号为2055。首先运行服务器，客户端随后运行，工作正常，其工作流如图5和图9所示。当程序运行一次时，客户端队列中的元素数量如图12所示。开始时数据量是0，接收到的数据可被及时处理。随后，数据量逐渐增加。在18 s后达到最大值7，此时服务器上的所有数据都已完全发送，然后对队列的元素逐个进行处理，数据量逐渐减少。在2 GHz Intel i5 CPU、2 G内存、Windows XP、LabVIEW 2012环境下，整个程序大约运行花费约32.5 s。
图12 信息传输队列中的元素数
由仿真过程可以看出，采用XML进行故障信息标准化描述，为实现故障信息跨平台远距离传输与共享奠定了基础；采用客户端-服务器的网络架构可有效实现信息传输，有助于设备故障的远程监控与诊断，增强故障诊断的实时性与灵活性。仿真结果与预期一致，进一步验证了总体方案与技术的可行性。
3 结束语
为满足网络故障诊断中跨平台、故障信息标准化描述、网络传输的需要，基于LabVIEW给出了设备故障信息标准化描述及网络传输总体设计方案和实现方式。通过采用多种技术，验证了总体技术的可行性。本文研究成果有助于进一步实现机电一体化设备远程跨平台网络化故障诊断系统和LabVIEW的相关开发工作，为开展复杂故障信息的描述与传输研究工作提供了思路。
