微网能量管理系统中数据采集子系统的优化设计与应用

2010-09-03丁明,周亮,毕锐

合肥工业大学学报（自然科学版） 2010年12期

丁明, 周亮, 毕锐

(合肥工业大学教育部光伏系统工程研究中心,安徽合肥 230009)

含分布式电源的微型电网,与传统电网相比,无论是从系统容量和采集点的规模上以及控制方法上都有较大区别。对于微型电网而言,数据采集系统的快速响应特性显得犹为重要[1-3]。数据采集系统作为微网管理控制系统基础平台的重要组成部分,负责完成与各远端IED(Intelligent E-lectronic Device,简称IED)装置及分布式电源控制器的数据交换,同时为微网能量管理系统的上层高级应用提供可靠的数据源。数据采集系统不但自身有着很强的硬件环境约束性,同时要求具有很高的稳定性和数据实时性。

数据采集系统周期性数据总召、对时等操作会瞬时增大网络负荷量。经过eEye公司的专业网络数据流量监测软件Iris分析,总召周期内的数据流量是正常状态下的3倍之多。这些都要求数据采集系统在处理这些重要数据时要具有较高的准确性、可靠性以及灵活性,能够对流量不稳定的数据流具有较强的可伸缩处理能力。

远动信息的采集将由集中采集向就地分布式采集方向发展[4]。传统大电网所面临的庞大数据通信问题可以借鉴微网中的数据采集系统解决方案。系统的功能下放与测控设备分布化将大大提高其自身的可靠性。

1 硬件系统结构

基于目前网络系统普遍遵循的横向分布、纵向分层[5]思想,应该优先选择建立一个标准的开放分布式网络硬件平台,平台结构如图1所示。

图1 硬件设备网络结构

通信网络的良好连接是保证数据实时性的物质基础[6]。由于RS485串行通信接口受到节点数目的限制以及考虑到对网络硬件资源的有效充分利用,采用以太网支撑的网络层是经济且实用的选择。网关作为以太网络接口与RS485串行接口的规约转化器,解决不同厂家设备的入网问题,同时增加硬件系统的可扩展性。文献[7]提出一种专用数字通信网关,通过简化网络结构保证数据的实时性,但是没有考虑优化网关的功能约束,避免因此造成的不必要的系统延时[8]。为保证网关的灵活性,系统应该配备相应的网关外围参数修改软件。

可靠的网络硬件平台应该提供冗余网路和互为热备用服务器。通过划分一定的网络带宽,微网系统中的SCADA(数据采集与监视控制系统)监控信息、继电保护故障信息和电能量信息,都可以根据相应的规约协议同时使用以太网络传输到监控层,这样可以充分利用网络资源和降低管理成本。为提高系统通信的开放性、兼容性和可靠性,监控层中的调度监控工作站与网关之间的远动数据传输应遵循统一的基于 TCP(Transmission Control Protocol,简称TCP)的远动协议。文献[9]介绍了通过修改同样支持应用服务数据单元(ASDU)的IEC60870-5-103规约,与IEC60870-5-104具有相同的APCI(应用规约控制信息)传输接口,使前者同样可以支持以太网传输。

2 软件系统设计

数据采集的软件系统设计中需要考虑到物理网络环境的特性。采用以太网方式组建的数据采集系统,需要考虑TCP/IP协议与操作系统的配合,并考虑采集系统作为客户端与各测控单元或电源控制器链路的稳定性以及数据交互的可靠性。对链路的稳定性和可靠性的合理维护须仔细处理,否则会造成系统的性能大幅度降低[10]。在保证硬件系统具有较强可靠性的前提下,软件系统应该具有可靠的通信通道维护能力,同时保持较大数据吞吐量。软件系统设计从软件的结构模型、数据模型、信息模型3个方面实现以上要求。

2.1 结构模型

软件粒度的选择决定着各功能模块的大小。由于规约的解析和打包功能模块是可重用性较高的模块,软件采用模块化编程可以将各模块之间的耦合程度降低,同时在今后软件扩展其它规约时也会很方便。数据采集系统的软件框架如图2所示,大致可以分为外部接口层、规约层、通信层等部分。

图2中实线箭头代表上行数据,虚线箭头代表下行数据。同步命名管道通过外部接口发布管道名称。微网能量管理系统数据处理模块根据管道名称请求写管道,然后按照约定的数据格式将远动控制命令发送给数据采集系统。远动控制命令将按照规约重新打包,通过通信平台直接发送到对应的网关。网关程序将接收到的控制命令准确送到对应的装置。

图2 软件系统结构

通信平台将接收的上行数据包放入一个工作队列,规约处理模块对上行数据包逐帧预读取,并按照规约将帧数据解析为系统生数据并存入内存实时数据库。数据采集系统的外部接口是由拥有优越安全性的内存实时库和同步命名管道共同实现的,负责采集数据和控制命令的转发工作。

由于IEC60870-5-104等系列远动协议是基于TCP连接,数据包有可能丢失、延迟、重复和乱序,因此应用层协议必须使用超时和重传机构[11]。规约处理模块和计时器模块共同负责相应的数据传输按照严格的纠错机制运行。

2.2 数据模型

数据采集系统中的动态数据信息交互采用线程池[12]及其相关技术。如果以网关为单位建立收发数据包线程,那么将会产生大量冗余的线程上下文切换处理,占用大量系统资源,很难确保数据的实时性、完整性和准确性。通用通信平台基于IOCP(I/O完成端口)机制,实现高效的数据收发,是应用程序使用线程池处理异步I/O(输入输出)请求的一种成熟通信机制[13]。IOCP是一种优化的多线程并发模型,通过有效的线程管理,减少线程上下文的切换,避免多线程资源竞争,适合于存在大量套接字I/O请求的场合。默认状态下,线程池中预先创建的等待线程的数目稍大于主机CPU数量[14]。

系统启动后,主线程首先会初始化各线程,从数据库服务器下装数据采集系统的配置信息参数表,然后创建内存实时数据库。主线程在程序正常运行时负责数据显示和子线程控制。各线程之间关系如图3所示。I/O端口监视线程将上行数据包指针放入工作队列中等待逻辑工作线程的处理。工作队列将规约层与通信层的耦合降到最低,而不影响数据的实时传输。工作队列的独立性越大,规约层与通信层的耦合也就越松。处于规约层的逻辑工作线程同样采用线程池技术。为避免数据流瓶颈的存在,2级线程池分别处于系统不同的结构层,分摊系统负载从而保证数据流的平稳过渡。重要的下行控制数据直接通过通信平台提供的发送接口单独发送,保证控制命令或规约交互数据帧的无延时下发,同时上行数据与下行数据之间互不影响。

由于数据传输控制的需要,规约层需要向各网关定时下发交互数据帧。这些下行数据发送请求直接转发到完成端口的完成队列(Completion Queue)中,由I/O端口监视线程池中的线程实时同步处理。

图3 核心线程关系图

(1)I/O端口监视线程。网络层的数据收发速度是系统性能的重要标志之一。完成端口监视线程同步返回完成端口上的异步调用请求。其主要流程如图4所示。由于对上行数据包只作简单的转发处理,IOCP的工作负载能力足以满足系统内所有网关的数据收发工作。

图4 I/O端口监视线程流程图

(2)逻辑工作线程。逻辑工作线程主要处理接收到的数据包,完成数据的分流,是数据采集系统的枢纽。它的处理类似于I/O端口监视线程,都采用线程池技术,但逻辑工作线程的激活个数是由工作队列内的工作任务数量决定的。逻辑工作线程处理工作队列中任务的效率将是决定采集数据实时性的一个关键因素。这种利用工作队列任务量管理线程池的方法具有很强的灵活性。线程内部主要流程如图5所示。上传的连接状态变化任务Job_ConnecterStateChange将按照对应的网关号创建或修改网关上下文GatewayContext。网关上下文包含规约传输控制所需的所有实时控制参数。

图5 逻辑工作线程流程图

(3)同步命名管道线程。命名管道能够保证2个相互通信的进程之间互不干扰又协调一致工作。为缩短重要远动控制命令响应周期,并且保证遥控/遥调命令数据的独立性和安全性,下行数据不经过实时数据库,而是单独建立一个同步等待线程,以触发内核对象 Named Pipe(命名管道)读事件激活该线程。

命名管道支持双向数据传输。在成功接收到并成功发送数据处理模块的遥控/遥调命令后,同步管道触发写管道事件,将原包内容回送给数据处理模块。后者则确认数据包准确到达数据采集系统。遥信变位事件的实时告警也是通过同步命名管道告知数据处理模块,从而图形显示模块能够根据遥信触发事件查询实时数据库中更新的遥信信息,不需要定时扫描实时库,减轻了系统负担,缩小了图形数据显示的延时。线程内部主要流程如图6所示。

图6 同步命名管道线程流程图

(4)计时器线程。延时连接、定时发送的控制帧以及数据超时纠错机制都需要一个异步的定时器。该定时器线程同样使用了和同步管道相同的内核对象触发的等待线程技术。以100 ms为单位,内核对象每次被触发之后,对每个有效网关上下文中的所有定时器对象做相应的状态检查并作相应的操作或置位,线程内部流程如图7所示。

图7 计时器线程流程图

(5)链接监视线程。通信过程中,需要可靠的错误恢复机制。在出现数据异常时,规约层传输控制可能会断开与某个网关的链接并立即重连。为减少阻塞型链接在延时连接过程中对其它链接数据收发的影响,通信平台需要一个异步连接机制。链接监视线程中分配各网关相应的LinkContext(链接上下文),该上下文中保存了链接对应的链接套接字、数据缓冲地址以及顺序控制参数。当建立一个新的链接,线程调用关联函数将当前链路套接字与IOCP关联后,这条链路上的所有数据交互都会经过完成端口,线程内部流程如图8所示。

图8 链接监视线程流程图

2.3 信息模型

规约处理类CProtocol Process作为主干类提供初始化通信平台、数据交互处理、管理计时器以及返回自定义常见错误信息等操作。规约支持类CPackFrame和CSolveFrame配合规约处理类提供打包和解包方法接口,完成数据收发工作,同时CSolveFrame类将上行数据及时更新到实时数据库中。通信类CCommunication基于IOCP实现,对规约处理类提供通用通信接口。程序中的异步套接字采用微软公司的封装类CAsync-Socket。异步套接字是为了避免在同一线程中的阻塞问题。IOCP机制如前所述是通过管理多线程的上下文切换改善效率,同时封装了异步套接字的调用。数据操作类 CIOCPBuffer基于OVERLAPPED数据结构为IOCP通信提供各类数据操作。它是IOCP依赖的特定数据结构,与CPtrQueue建立的数据缓存循环队列所属范畴不同。工作队列操作类CJobProcess提供一个静态工作队列链表JobQueueList以确保其唯一性,同时提供对队列成员的具体操作。

系统静态对象如图9所示,其中Gateway-Context(网关上下文)和 LinkContext的区分,不仅降低了网络层与规约层耦合,同时方便了管理。两者的对应点是网关号。连接成功并成功创建和初始化的上下文将存放于ContextMap映射中,以网关号作为对象主键。断开连接或删除网关时,相应的上下文直接从映射中释放。LinkContext中的链路状态分为可用状态USABLE和不可用状态UNUSABLE,GatewayContex中的网关状态分为关闭CLOSED、连接CONNECTED、激活ACTIVE、待关闭CLOSING。链路状态的改变必须通知对应的网关上下文,而网关状态中只有关闭和待关闭才会影响到链路状态。

图9 系统静态对象

逻辑工作线程池中的线程接收到TCP数据包之后,会将其转存到一个数据缓存循环队列QRec-Queue中。这个数据缓存循环队列提供可靠的读写操作,不支持定点插入,能够很好地保证数据的完整性和顺序性。引入数据循环队列是为了避免数据的收发影响解析数据帧。根据分层解析原则,从QRecQueue队列中预读取的I帧将会被再次深入解析,本文中把读取到的I帧写入解包缓存循环队列I_FrameBuf。它与QRecQueue同样都是数据缓存循环队列类CPtrQueue的对象。

3 数据采集系统的应用

合肥工业大学微网实验平台基于上述网络硬件平台构建思想,采用专用测控装置和数字网关。系统内目前已有71个遥控点、609个遥测信息点和266个遥信信息点。

根据软件系统设计的思路,编制系统主程序：DAS-MGEMS。根据文献[15,16]提供的测试原则,经过专业测试软件的压力测试、配置参数测试和应用功能测试,目前软件已在合肥工业大学微网实验平台通过各功能模块的联调实验,系统运行正常、稳定可靠,达到设计的要求。基于HP公司的系统性能测试软件 LoadRunner对主程序DAS-MGEMS运行时,系统的CPU使用率变化和TCP数据包传输请求量变化的对比,如图10所示。网内数据流量因为系统周期事件所导致的瞬时剧烈波动对系统资源负载变化的影响不明显,系统运行画面如图11所示。