计量自动化系统上行和载波通信联合测试研究

梁捷

（广西电网有限责任公司电力科学研究院，南宁 530023）

0 前言

计量数据采集的可靠性日益受到重视。该系统在运维过程不时会出现终端上线率不稳定、参数下发失败、数据采集成功率低等问题[1]。但由于计量自动化系统的通信单元主要包括主站、采集终端，载波通讯模块[2]和电能表等，涉及多个厂家。且信道包括上/下行和载波模块和电能表的交互接口等[3]，信道覆盖面广，协议层级较复杂，给通讯故障的快速定位和原因分析带来困难[4]。

为使得通讯故障的排查范围能覆盖至各通讯单元和信道，实现上行和载波各通信环节的联合测试，本文在研究电表载波模块地址分配和电能表数据采集的测试原理和流程的基础上，设计了一种电力线载波(power line carrierwave，PLC)用电信息采集系统测试方案和应用平台。并通过关于电表载波模块和计量终端的两个故障案例验证了该平台的实用性。

1 测试平台设计

1.1 平台架构

计量自动化系统常见上、下行通讯方式分别为GPRS和低压窄带电力线载波方式，据统计，该系统PLC现场抄表故障原因主要源于两方面：软件方面为上/下行通信规约解析不一致、计量主站下发报文故障，计量终端数据上报错误等；硬件方面为计量自动化终端或PLC模块通讯故障和无线通讯干扰[5]等。

图1 测试平台简图

为实现计量自动化系统PLC抄表故障的准确定位，针对上述常见的通讯方式设计测试平台如图1。

该平台由数据管理器、数据分析模块、模拟主站等组成。其中模拟主站可根据测试方案，按照上行通讯协议[6-8]对计量终端下发测试报文，以及接收和解析终端回复的报文。

数据管理器可对电表和PLC模块间的报文进行中继转发，并对整个系统的报文信息进行监听，分析模块可对监听到的报文数据进行分析判断并给出结果。数据管理器与PLC模块和电表的通讯方式为RS232串口方式。

由于终端不支持“终端-模拟主站”以及“终端-数据分析模块”两条信道的同时通信，设置终端接入控制模块，它通过修改诊断终端的通讯服务器参数，控制终端TCP/ΙP（Socket）通信连接的建立，接管终端与主站的通讯链路。

数据分析模块一方面可比较待测PLC模块回复数据和电表实际数据，判断PLC模块的数据采集功能是否正常，同时根据报文中附带的时间信息评估通讯延时。另一方面可通过终端的测试用RS232串口搜集终端通讯参数、信号强度，拨号情况等信息，并获取模拟主站收到的上行报文，对上行无线信道的故障进行多方面分析判断，综上可实现计量自动化系统的上/下行信道和PLC模块与电能表的多点信道故障综合测试，有利于提升通讯故障排查水平，改善运维工作质量。

1.2 测试流程

该平台的测试范围覆盖至计量终端及多个PLC模块之间的通讯信道，测试流程见图2和图3。

图2 本文平台的上行GPRS方式测试流程

上行测试主要步骤为：

1) 数据分析模块首先根据故障终端类型和故障现象对故障进行初步分类，并选择相似条件的方案，载入诊断任务和专家知识库，并控制终端接入控制模块切换至RS232通道。

2) 数据分析模块通过RS232通道召测终端通信参数，并将其返回数据库存储。

3) 数据分析模块对采集到的通讯报文进行规约解析，提取参数信息，若不需结合终端实时和历史报文数据进行判断，则根据专家知识库中的诊断知识或在线输入的新的诊断知识，执行终端故障原因匹配和诊断，得出诊断结果。

4) 若需结合终端实时和历史报文数据进行判断，则控制终端接入控制模块切换至GPRS无线通道。通过模拟主站搜集终端历史数据和召测实时数据，并将终端参数和实时数据返回数据分析模块进行规约解析。

5) 数据分析模块根据步骤(3)和(4)搜集的信息进行诊断；

6) 根据故障原因和诊断结果，从专家库中获取相应解决方案，并汇集成终端故障诊断报告，最后进行存储和显示。

图3 本文平台的下行载波方式测试流程

下行测试主要步骤为：

1) 首先设置下发报文内容，确定待测PLC模块数量、起始电表地址、测试超时时间，重测次数和轮循次数等参数。如果待测PLC模块经下发报文后未正常应答，且等待回复时间大于超时时间，则判断此次通讯异常，重新对该模块下发命令，若重复次数达到重试次数，则判断该模块异常。

2)给待测PLC模块和计量终端上电，模块自检、规约一致性判断，建立同电表和模拟主站通信连接等。

3) 模拟主站为每个电表PLC模块分配长度为10位的逻辑地址。PLC模块收到地址配置报文后回复确认。若模拟主站未收到某一模块的确认报文，则重新进行分配，直至达到最大重试次数。

4)模拟主站通过计量终端向待测PLC模块下发抄表命令。数据管理器实时监听信道中各通信单元之间的交互信息，并保存至数据库。

5)数据分析模块对监听记录数据进行分析判断，若模拟主站接收到的数据与电表实际数据一致，则认为该模块数据采集功能正常；否则根据历史记录报文，可进行故障分析和故障点定位。

对比于文献[9]，本平台将故障的分析范围扩展到计量自动化系统的上/下行信道，且可实现PLC模块层的故障定位。

2 测试案例分析

测试案例包含24只电表PLC模块和单相电能表，1个集中器。为排除市电中的噪声等干扰源对通讯环境的影响，测试平台由经电源净化装置过滤的市电进行供电。

主要包括4个测试项目：

a)上行无线通信测试。

b)上线稳定性测试。

c) PLC模块地址分配测试。

d)数据采集测试。

各项目对应的诊断任务的主要内容为：

2.1 上行无线通信测试

首先人工设置终端通信参数，然后根据图2流程执行通信参数测试方案，下发诊断任务，数据分析模块通过RS232通道召测终端通信参数，包括终端上设置的主站ΙP地址或者端口号，SΙM卡号码和终端拨号信息等，并与预期值进行比对，执行诊断。再切换到GPRS无线通道召测终端数据，排查GPRS通信模块硬件故障。

2.2 上线稳定性测试

执行上线稳定性和抄读成功率测试方案，下发诊断任务，数据分析模块通过RS232通道召测终端通信参数，包括当前无线信号强度，心跳间隔，月通信流量等，并与预期值进行比对，执行诊断。再切换到GPRS无线通道召测终端在执行的数据采集任务数，侦听异常告警上报情况，并通过点对点召测方式进行测量点有效性核对。排查影响终端上线稳定的因素。同时也可监测到一些指标状态，如电流不平衡、电流过负荷、缺相、失压等。

2.3 PLC模块地址分配

如图4，测试平台初始化后，模拟主站首先对电能表PLC模块发送分配逻辑地址请求，模块允许后数据管理器为该模块分配地址，并监听回复报文，数据分析模块判断逻辑地址分配是否成功，若任意报文缺失则认为分配失败。

图4 PLC模块地址分配过程

2.4 数据采集测试

首先由模拟主站通过计量终端下发电表数据采集命令，电能表收到数据管理器转发的采集命令后，将采集到的数据通过RS232串口回复至数据管理器。然后，PLC模块收到数据管理器数据报文后通过PLC通道发送至计量终端，最后通过上行通道回送至模拟主站。测试系统通过RS232串口打开电表与PLC模块间的通讯接口是为了获取电表实际数据用于数据采集结果的分析判断。比较模拟主站在上述过程中获取的采集数据与数据管理器监听到的电表数据，若数值一致则表明数据采集成功，反之失败。

2.5 通讯故障实例分析

该系统应用时发现的一些常见故障实例如下：

1)上行无线通信故障。故障终端通过RS232通信正常，但上行无线通信无法登录，终端拨号信息提示硬件检测失败，经查发现部分终端的GPRS通信模块与终端的接触不良，部分模块重新拔插后恢复正常，但部分故障依旧，则判断为通信模块故障，需更换故障模块。部分终端拨号信息提示建立PPP连接失败，其可能是因为未安装SΙM卡或卡损坏，异或SΙM卡与通信模块的卡槽接触不良。也可能是SΙM卡欠费，此时常伴随时间性或者地域性特征，可通过月通信流量情况判断。部分终端拨号信息提示登录主站失败，可通过RS232通道召测到的终端通信参数进行分析，可能的故障原因包括终端上设置的主站ΙP地址或者端口号，SΙM卡号码不正确等。

2)上线不稳定案例。故障终端在线时间过低，终端频繁登陆、退出。通过RS232信道读取无线信号强度和心跳间隔，发现部分终端无线信号强度低(RSSΙ小于-90 dBm)，或心跳间隔过短（不大于1 min/次），导致心跳帧过多，易导致流量超标。部分终端在通过GPRS无线通道召测终端在执行的数据采集任务时，发现存在许多无效的任务模板，导致终端采集任务重，从而导致网络拥堵，部分终端通过点对点召测进行测量点有效性核对时发现存在许多无效测量点，也会占用终端资源，造成上线不稳定。

3)采集终端故障。某待测系统发生采集失败后，首先核对数据管理器的上行通信的记录表明模拟主站与计量终端间GPRS通信正常，可排除模拟主站及上行信道的故障，然后根据下行报文解析出故障采集点的地址，定位到电表PLC模块的地址，然后，根据该地址核对计量终端下行通信记录，发现无计量终端向该地址的模块转发命令的记录，但是有PLC模块通过数据管理器向电表转发报文的记录，则定位故障点为计量终端。

(4)电表PLC模块登录故障。在某电表的PLC模块的历史通讯记录中查询到，在其地址分配过程中，短时间内有多次数据管理器对其“发送 55”的记录，即地址分配请求，但未收到回复，并达到最大重试次数，则认为该电表PLC模块登录异常。

3 结束语

针对计量自动化系统上/下行信道涉及的通信单元较多，电力线载波的通讯故障定位困难的问题，研究了上行无线通信和上线稳定性测试、电表载波模块地址分配和计量系统数据采集测试的机理和流程，研制了一种计量自动化系统上行和载波通信联合测试平台，可实现计量终端和电能表载波通讯模块的通讯功能测试和故障定位功能。给出了关于电表载波模块和计量终端的四类常见故障案例的故障点分析和定位过程，测试结果验证了本文测试平台的可行性。