首页 > 论文范文 > 工程工业论文 > 工程综合论文 > 工程设计论文 > OPC技术基础上运载火箭地面设备测控系统架构探究

OPC技术基础上运载火箭地面设备测控系统架构探究

2020-11-13 176 上传者：管理员

摘要：我国运载火箭高密度发射的常态化对地面设备测控系统提出了设计通用化、流程自动化和数据处理智能化的要求。提出一种基于OPC技术的运载火箭地面设备测控系统架构。利用OPC规范将地面设备测控系统的各分系统进行整合,其设计通用性、数据处理能力、容错能力等均有明显提升,有一定的工程实践意义,且在实际应用过程中已取得良好效果。

关键词：
OPC技术
测控系统
系统架构
运载火箭
高密度
加入收藏

运载火箭地面设备(以下简称地面设备)在运载火箭测试发射过程中,主要完成加注、供气、瞄准、垂直度调整、加泄连接器脱落和摆杆控制等各个功能的射前准备工作。目前地面设备各分系统均已实现测控流程的电气化,但各分系统仅在内部形成了测控流程的自动化体系,系统的交互少,各分系统间的测控系统技术水平参差不齐、标准不一,接口匹配设计复杂、兼容性差;各分系统测试数据分散,难以全面了解各系统测试状态,上级指挥自动化程度低、发射决策效率低下,导致了测试发射准备周期长;各分系统测试设备重复配套,不利于研制成本的控制。

地面设备在运载火箭系统中属于可重复使用的系统,随着我国航天器高密度发射的常态化,对地面设备也提出了新的要求:1)提升地面设备测控系统的通用性,避免各分系统单独设计测控系统带来的差异性问题以及各分系统内部接口不一致导致的兼容性问题;2)提升地面设备测试的自动化程度,地面设备历来是火箭系统中自动化程度相对低下的部分,靠人工完成的测试项目较多,实现测试流程自动化和判读数据实时化,对节约人力,实现无人值守,缩短发射准备周期有重要意义,以避免高密度发射带来的周期被迫缩短问题;3)提高数据处理能力,实现试验数据现场分析处理归档入库,方便测试人员进行数据判读、历史数据查询等。

在传统的控制系统中,不同硬件控制设备之间的数据交互一般依靠不同的驱动程序实现,但硬件设备厂商提供的驱动程序功能相对固定,不满足软件设计人员的不同需求,当系统功能需求超过硬件设备厂商提供的驱动程序功能范围时,软件设计中就必须进行设备驱动程序设计环节,大大增加了软件的复杂度,降低了系统的可维护性和可靠性。

OPC(ObjectLinkingandEmbeddingforProcessControl)技术的出现为此问题的解决提供了契机。OPC是基于过程控制的对象链接和嵌入(ObjectLinkingandEmbedding,OLE)技术[1],是基于微软公司的COM(部件对象模型)和DCOM(分布式部件对象模型)技术制定的自动化领域信息通信接口应用技术。基于OPC技术,可使硬件设备厂商之间具备了一套通用的依据和标准,由硬件设备厂商提供OPC服务器程序,软件设计中仅需在满足OPC规范的情况下,即可与不同的硬件设备进行数据交互,这样就扫除了不同软件和硬件之间的通信障碍,并且从根本上解决了软件设计中必须为不同设备开发驱动程序的问题。同时,不同软件之间由于数据接口不匹配带来的通信问题也可通过OPC技术解决,为实现不同的系统及模块间协调运行提供了可能[2,3,4]。

1、OPC技术规范及技术背景

1.1 OPC规范概述

OPC技术是在微软公司的COM和DCOM基础上发展的,因此具备面对对象的特征,OPC规范是包含了一系列的属性和方法的集合,由OPC基金会进行发布和维护,作为全世界硬件设备厂商的研发规范。OPC规范主要包含实时数据存取规范(DataAccess,DA)、报警与事件处理规范、历史数据处理规范、批量数据过程规范、数据安全规范和数据交换规范等一系列规范。其中OPCDA规范是OPC规范的基础,基于OPCDA规范的实时数据,其余的规范才得以建立发展[5,6,7,8,9]。

OPCDA规范有别于一般传统的数据交互方式,其可使上位机与现场硬件设备在相互之间的通信规则未知的情况下还可以正常进行数据交互。OPCDA规范采用COM技术典型的C/S模式,一个OPC客户端可以连接到一个或多个OPCDA服务器,一个OPCDA服务器可以与一个或多个客户端相连接。其典型的结构模型如图1所示。理论上OPCDA服务器可以和所有的硬件设备或实时数据源连接,因此使上位机软件不需要为特定的硬件设备开发驱动程序。

图1OPCC/S模式典型架构图

PC服务器是基于OPC规范的控制系统的重要组成部分,其主要功能是为对应设备提供符合OPC规范的接口和数据通信机制。OPC规范中要求硬件设备厂商必须提供符合规范的OPC服务器,以保证任何符合OPC规范的OPC客户端均可实现对其的访问和数据交互。同时,OPC规范要求所有的软件厂商必须提供符合规范的OPC客户端,以保证客户端可访问任何符合规范的OPC服务器,并与其进行数据交互。

OPC服务器内部结构由服务器(Server)对象、组(Group)对象和项(Item)对象组成,其中:Server对象维护自身信息和Group对象链表;Group对象维护自身信息和Item对象链表;Item对象内部维护自身信息,主要包括访问权限、激活状态、数据类型、数据值等。Server对象和Group对象为标准COM组件,提供标准接口,Item对象不提供客户端接口,可自定义或派生于COM。这样OPC服务器就可将对硬件设备的访问封装在内部,而只为OPC客户端提供访问接口,OPC客户端仅需明确接口即可调用相应的服务完成功能,无须考虑访问硬件设备这一复杂过程。OPC服务器内部结构如图2所示。

图2OPC服务器内部结构

图3为OPC服务器和OPC客户端数据流向图。客户端通过接口函数与服务器进行数据交互,客户端用户界面可实现对服务器端的操作;服务器通过驱动程序与硬件设备数据源进行数据交互,Server地址空间起保存具体数据源的作用,对象接口部分是客户端和服务器进行数据传递的唯一途径,服务器的用户界面并非必须存在,一般只用作监测服务器运行状态和客户端数量等。

图3OPC服务器和客户端数据流向

1.2 地面设备测控系统常用架构

随着我国航天运载火箭的发展,地面设备测控系统也经历了从无到有,由简入繁的过程,本文以包含3个分系统的地面设备测控系统为例,介绍地面设备测控系统的常用架构。

1)分系统独立的集成式测控系统:

该系统架构原理图如图4所示,3个分系统独立设计,互相之间没有数据交互。分系统的内部采用上位机+系统测控单元的常用架构模式。系统测控单元是系统架构的核心,一般根据系统功能和性能需求选取PLC、单片机和实时控制器等硬件设备,控制执行器件(电机、电磁阀等)完成系统的规定动作,通过传感器采集系统的各项参数和状态。上位机运行用户界面以完成监测和控制,与系统测控单元进行数据交互,显示系统的参数和状态,并完成数据处理和存储等功能。此种系统架构下,数据交互必须通过驱动程序执行,而不同的分系统的具体的硬件设备和厂商均不同,导致不同分系统的数据交互需要的驱动程序不一致,软件开发难度大,系统通用性和可维护性差,并且各分系统独立运行,时间难以统一也是一大难题。发射测试过程中,各分系统会产生大量的数据,由于各分系统数据独立处理和存储,当分系统工作存在测试流程上的逻辑性时,数据后处理和分析的工作量也相当巨大。

图4分系统独立的集成式测控系统

2)地面设备集成测控系统:

系统架构原理图如图5所示,在系统架构1)的基础上,增加指挥控制单元和数据处理单元。指挥控制单元和数据处理单元可以与各分系统的上位机进行数据交互,指挥控制单元负责发射测试过程的指挥调度协调功能,提升发射测试过程的指挥调度自动化,数据处理单元负责将测试过程中各分系统产生的数据进行实时处理和存储,并在此基础上,为实现全系统的数据实时监测判读提供了条件。但是,此种系统仍然以系统架构1)为基础,没有脱离分系统独立的拓扑结构,并且与系统测控单元的数据交互仍然需要单独设计,很难做到接口一致。

图5集成式测控系统架构

2、系统架构设计

为解决地面设备各分系统测控单元选型不一,设备接口不一致等问题,本文提出一种基于OPC技术的地面设备测控系统架构,如图6所示。系统架构采取分层式架构设计,分为现场设备层、OPC服务器层、OPC客户端层和系统应用层。

图6基于OPC技术的地面设备测控系统架构

1)现场设备层。

仍以3个分系统为例,包括各分系统的测控单元、执行器件和传感器,分系统1与分系统2的测控单元选型相同的情况下,二者可共用相同驱动程序接口,但分系统3的测控单元与其余分系统不同,因此驱动程序接口不一致。

2)OPC服务器层。

分系统1与分系统2的驱动程序相同,因此二者共用同一OPCDA服务器,分系统3使用不同的OPCDA服务器,两个OPCDA服务器可以依据OPC数据交换规范进行数据交互,数据交互过程由OPC数据交换服务器实现。这样在OPC服务器层即可实现数据交互,当某一分系统存在造成多个分系统的人员和设备安全风险的故障时,可通过OPC数据交换服务器使其余分系统得知,并应急处理,提升了应急处理信息的传递速率。在OPCDA服务器的基础上,依据OPC报警与事件处理规范建立OPC报警处理(AE)服务器,用于对实时数据采集后进行简单的判断和相应。依据OPC历史数据处理规范建立OPC历史数据处理(HDA)服务器,用于OPC服务器层对实时数据进行趋势等分析。最后,OPC服务器层依据OPC规范,向OPC客户端提供接口以供调用。

3)OPC客户端层。

包含OPCDA、OPCAE、OPCHDA客户端,可通过客户端调用接口完成与各自服务器的数据交互,并且在客户端层设置OPC服务器配置工具,用于对OPC服务器层包含的服务器进行配置,作为系统扩充和更改时使用。

4)系统应用层。

系统应用层的主要作用是提供面向用户的用户界面、实时数据处理和存储,测试数据中心将地面设备过程中的所有测试数据进行实时处理,按照预先设定好的处理方法进行处理,完成后进行数据库操作,并将数据提供给需要的模块。分系统1-分系统3用户界面为各分系统人员进行测试操作、监测和控制的人机界面接口。地面设备指挥控制用户界面实现发射测试过程的指挥调度协调功能,提升发射测试过程的指挥调度自动化,使各分系统按照测试流程顺序执行动作。数据浏览用户界面基于实时测试数据中心和历史数据库建立,用于在发射测试过程中及发射后进行数据浏览、数据报表、数据判读及数据导出等功能的实现。在测试发射的不同阶段,对地面设备的技术状态要求不一,因此应用层配置工具主要完成测试流程配置、指令配置、参数配置和用户界面配置等功能。

图6所示的系统架构中,现场设备层和OPC服务器层之间的数据交互需要硬件设备的驱动程序支持。基于OPC规范,硬件设备厂商在为其硬件设备开发OPC服务器时,已经将驱动程序一并包含并提供,因此不需要系统软件设计人员再重复开发,软件设计人员仅需依据OPC服务器提供的接口进行相应的客户端开发即可实现与所有的硬件设备的数据交互,最大限度保证了设计通用性,无论哪个分系统,对于OPC客户端而言,接口均一致,保证了客户端及系统应用层软件的通用性。

本文提出的系统架构中,分系统作为地面设备测控系统的一部分嵌入到系统架构中,利用应用层配置工具可进行测试流程配置,可快速完成不同分系统的测试流程界面的配置,免去大量测试流程调整的工作。

在测控系统内部出现故障时,采取对OPC服务器进行配置的方式,对地面设备测控系统架构进行在线重构,保证系统除故障点外的其余部分不受故障影响,可继续完成测试流程,提升了系统的容错能力和可维护性。实时数据和历史数据均统一维护在实时数据中心和历史数据库中,保证数据的完整性及数据采集格式的统一,便于进行数据判读和报表分析等工作。

3、结语

本文首先提出当前运载火箭地面设备测控系统的需求,分析OPC技术规范的原理和优势,其次在概括了当前地面设备测控系统的常用架构的弊端的基础上,提出了基于OPC技术的运载火箭地面设备测控系统架构,介绍其组成,并重点描述了各虚拟层的功能,最后着重分析了提出的系统架构相对于常用架构在工作量、可维护性和扩充能力方面的优势。基于OPC技术的运载火箭地面设备测控系统,可大大减少系统软件设计的工作量,使之更集中于系统功能的实现而非底层驱动的实现上,可提高系统的扩充能力和容错能力,其数据维护的方式更为合理,为后续数据判读智能化、测试流程全自动化发展奠定了基础,为实现运载火箭加注发射测试过程无人值守提供了可行的思路。

参考文献：

[1]黄惠群,刘晓龙,马杰.基于OPC统一架构技术的盾构实时监测系统[J].城市轨道交通研究,2019,22(4):94-97.

[2]李赫,杨传颖.OPC技术发展综述[J].仪器仪表用户,2012,19(4):6-8.

[3]刘少清,季振山,王勇,等.基于LabVIEW和PLC的智慧农业监控系统[J].仪表技术,2018(6):1-4.

[4]胡忠华,崔兴强.基于OPCUA接口的数控铣床eMCS系统设计[J].工业仪表与自动化装置,2019(3):54-58.

[5]雷红玲,谢运祥.基于OPC的非线性对象实验控制平台设计及实现[J].自动化技术与应用,2019,38(5):31-36.

[6]吴晗,杨颖,周亚军.基于OPC的子午线轮胎生产过程监控系统[J].机电工程,2014,31(11):1509-1512.

[7]张为民,马杰.生产设备实时数据远程监测研究与实现[J].计算机应用与软件,2018,35(9):126-131.

[8]夏璐杰,孙首群,卢华阳.基于OPC与PLC的远程监视系统的研究[J].自动化仪表,2017,38(2):22-24.

[9]王韬,石昊东,季春梅.基于OPC协议的集中自动化控制系统[J].机械制造与自动化,2016,45(1):212-214.

郑国昆,苏娟,吴齐才,杨之江.基于OPC技术的运载火箭地面设备测控系统架构研究[J].计算机应用与软件,2020,37(11):18-21.