EME、教育学等其他专业毕业论文范文
这是《供电公司用电信息采集子系统设计与实现》这篇计算机软件工程硕士毕业论文的第五章,也是论文的核心内容之一,主要介绍了用电信息采集子系统的功能实现及测试。
5 系统功能实现与测试
按照系统的功能设计,用电信息采集子系统的功能实现主要包括了前台的基于Web的人机交互功能研发和后台的终端硬件的Modbus协议通信功能两个方面,本章对系统进行详细的功能开发实现,同时介绍系统的测试工作。本章具体的研究内容包括了系统的开发环境介绍、后台通信功能实现、上层软件的功能模块实现以及系统的测试工作分析等方面。
5.1 开发环境
用电信息采集子系统的上层软件采用Java Web技术以及SSM模式进行研发,具体的开发环境及技术选择如下:
1. IDE集成开发环境:MyEclipse 2013
2. Web页面设计工具:Dreamweaver 11.0
3. Web动态页面技术:JSP、JavaBean
4. Web服务软件:Tomcat 7.0.1
5. 数据库工具:Oracle 11G
6. SSM版本:Spring 4.0.2,SpringMVC 4.0.2,MyBatis 3.2.6
系统的后台通信功能采用Modbus协议技术研发,属于嵌入式开发,其开发环境及技术选择如下:
1. 开发主机操作系统:ubantu Linux 16.04LTS
2. 开发语言:C语言
3. Modbus协议版本:Modbus V2.2
4. 现场总线接口:RS485总线
5.2 系统后台通信功能实现
系统的后台通信功能主要是通过供电端现场的通讯设备和采集点设备进行交互,其中和Modbus协议相关的功能需要在采集点设备中进行嵌入式开发。在目前已经部署的采集点设备中均提供了用于二次功能拓展开发的ARM处理器和RAM存储器作为硬件支持。按照系统的功能设计,后台通信功能的开发工作重点在于Modbus/TCP协议以及串行Modbus通信功能的开发实现。本节对系统后台通信功能实现过程中的嵌入式开发环境配置工作、Modbus/TCP协议相关功能开发以及串行Modbus通信功能开发进行详细分析与介绍。
5.2.1 嵌入式开发环境配置
在嵌入式软件开发中需要采用支持硬件芯片的操作系统作为ARM功能代码运行的基础环境支持,本系统采用了基于Ubantu16.04LTS版本实现。在具体的开发环境配置操作时,利用和用于嵌入式开发的采集点设备以TCP/IP网络连接的Ubantu主机中的SSH Secure File Transfer Client(SSH SFTC)工具获取GCC编译环境组件,同时还需要下载uIP编译包,作为TCP/IP以太网通信相关功能开发的函数接口支持。
随后,将上述导入的相关Linux内核文件,采用TCP/IP连接下发到采集点设备中的临时目录,并进行解压和参数配置操作,主要的配置内容分为菜单功能、PPP点对点通信协议、串口参数配置等方面。在完成了上述参数配置之后,本系统基于XML可扩展标记语言技术奖采集点中的文件进行配置,配置内容分为开发主机端的IP地址、通信端口、设备登录验证信息等,具体的配置内容如下:
其中的服务器是指用于嵌入式开发的开发主机,上述文件配置信息在采集点设备的RAM中采用C语言的结构体进行临时保存,并命名为rtuconfg,其内部结构如下:
typedef struct{
server_t server; //服务器对象
device_t device; //设备对象
heartbeat_t heartbeat; //心跳包对象
reg_t reg; //注册包
}rtuconfg_t;
采集点设备在和开发主机进行通信时,通过对rtuconfg结构体进行数据读取,作为通信过程的参数支持。在完成了上述配置之后,即可进行后台通信功能的嵌入式开发。
5.2.2 Modbus/TCP功能实现
在进行后台通信功能开发过程中,对于Modbus总线通信数据和TCP/IP以太网通信数据的转换操作,按照Modbus协议的技术规范,其中包含的协议标记字段主要分为协议标识符、转译符以及文本字符数据,因此需要在采集点设备中设置对应的处理规则,本系统采用的自定义处理规则包括如下3条:
1. 规则1:在数据包的读取过程中,读取到0x7e字节信息之后,在采集点设备中连续传输2字节数据(0x7d和0x5e),采用上述3个字节的数据实现Modbus和TCP/IP协议数据包中的协议标识符的转换处理。
2. 规则2:在数据包的读取过程中,读取到0x7d字节信息之后,在采集点设备中连续传输2字节数据(0x7d和0x5d),采用上述3个字节数据实现Modbus和TCP/IP协议数据包中的转译符的转换处理。
3. 规则3:在数据包的读取过程中,读取到0x20字节信息之后,在采集点设备中连续传输2字节数据,分别为0x7d,以及原字节位置数据与0x20异或计算结果,采用上述3个字节的数据实现Modbus协议和TCP/IP协议数据包之间的字符信息转换处理。
在后台通信功能体系中,采集点设备采用Modbus/TCP协议技术与现场的通讯设备直连,后者内部部署了完备的TCP/IP协议族,并采用标准化的套接字和系统Web服务器后台通信,所以在不考虑中间通讯设备的数据转发前提下,本系统Web服务器主机和采集点设备之间需要实现Modbus和TCP/IP协议之间的数据转换,即Modbus/TCP的相关功能开发。本节介绍其中的Modbus/TCP通信功能的实现,开发工作集中在采集点设备中,包括了面向上层的TCP通信功能开发和内部的协议转换处理两个方面:
1. 采集点设备中的TCP/IP通信功能实现
在开发过程中首先基于uIP编译包中的socket()函数调用创建用于和Web服务器后台逻辑连接的套接字,其中协议参数选择AF_INET,通信协议选择TCP协议。随后,调用start()函数实现TCP套接字的激活和启动处理,在套接字激活完成后调用setsockopt()函数设置数据交互过程中的心跳周期参数KEEP_ALIVE值为5秒,以及重复数据包发送尝试次数参数为10,即在等待5秒无影响之后的数据重发次数为10次。同时还需要对下层Modbus协议通信的保持时间参数SO_KEEPALIVE、TCP连接保持的空闲时间TCP_KEEPIDLE、活跃周期参数TCP_KEEPINTVL以及最大连通时间参数TCP_KEEPCNT进行设置,具体参数取值根据不同的数据通信类型进行设置。在完成了上述相关基本参数的设置之后,采集点设备中通过读取rtuconfg结构体的内容,获取远程节点(Web服务器主机后台)的通信信息,并基于uIP编译包的connect()函数调用实现网络连接,在建立了网络连接之后再调用uIP中的send()函数将本地注册信息报进行发送,发送数据的预处理代码如下:
/*获取本地协议地址*/
getsockname(socketfd, (struct sockaddr *)&addr_in, (socklen_t*)&addr_len);
/*存储本地协议地址*/
fprintf(stderr, "local ip %s:%d ", inet_ntoa(addr_in.sin_addr), ntohs(addr_in. sin_port));
在完成了注册报文的发送并接收到远程节点的反馈之后,在采集点设备中持续调用send()函数将Modbus/TCP转换之后的采集数据、设备反馈信息等发送至Web服务器后台,并在数据发送完成之后调用uIP的close()关闭本次通信套接字。如果注册失败,则需要在采集点设备中创建网络连接错误的故障代码,并基于采集点设备的异常上报机制,通过专用通信通道资源将异常情况进行上报处理,为设备运维管理人员提供故障处理的数据参考。
2. 采集点设备中的Modbus/TCP协议转换功能实现
按照采集点设备中的TCP/IP通信功能实现工作,在采集点设备和作为远程节点的Web服务器主机后台进行通信过程中,传输的目标数据需要为已经转换完成的TCP/IP协议数据包。因此,在采集点设备中还需要进行Modbus/TCP的相关功能开发,在其中实现对Modbus协议数据包进行解析和重新处理,得到基于TCP/IP协议的目标数据。
在具体的功能开发过程中,采集点设备按照远程节点下发的用电信息采集指令或者设备监测指令,利用Linux系统中的多线程机制,调用thread()函数创建独立线程,在其中对下发的指令信息进行解析处理,并将其按照Modbus协议规范以及本系统自定义的Modbus通信协议格式进行重新封装,随后通过串行Modbus协议技术向智能电表设备进行下发处理。上述功能的逻辑处理核心代码流程如图5-1所示。
图5-1 Modbus/TCP通信功能实现流程
按照图5-1所示,在下行数据的协议格式转换处理过程中首先通过调用init_tty()函数对抄表设备的RS485串口进行初始化操作,随后在下行数据包中增加CRC校验计算结果,并进行数据的下发。当现场硬件的反馈信息通过RS485串口传输到来时,通过调用tty_read()函数进行目标数据的读取,并按照MBAP数据格式定义在其中读取该数据段,并将后续数据进行覆盖处理。最后返回到上层利用TCP/IP的套接字通信功能进行远程发送。
如果在上述处理过程中出现了网络异常,则在采集点设备中手动触发其管道崩溃错误,从而导致整个处理过程的中断。在后续处理过程中,通过对采集点设备中的Sigpipe信号进行屏蔽,并关闭上层交互所使用的socket套接字,重新进行数据的协议转换尝试操作。
如果尝试操作持续失败5次,则更新采集点设备的异常状态,在系统中将该采集点设备标记为失败设备。
5.2.3 串行Modbus功能实现
在目前公司所采用的智能电网硬件体系中,电网中部署的采集点设备采用了半双工模式的RS485串口实现与智能电表和调试设备之间的物理连接,最大连接支持数量为247个,因此为了实现数据的有序交互,在串口Modbus数据通信过程中,采用了GPIO模式对现场的总线通信数据交互过程进行逻辑调度处理。
具体而言,在串行Modbus数据通信过程中,上行的采集指令以及设备监测指令在下发过程中,首先利用Modbus协议中的RS485总线支持协议将采集点设备中的GPIO端口以及对应的RS485串口进行初始化处理,并按照本系统的Modbus通信协议规范,在其中填充CRC校验码。随后,调用Linux内核中的write()函数将上述数据信息下发到该RS485串口,后者自动将数据通过总线发送到智能电表设备或者调试设备中。
由于在智能电表设备中接收到的指令数据为标准的工业现场总线协议格式,所以能够直接将其中缓存的用电信息进行上报处理。采集点设备在数据接收过程中首先通过调用同步读取函数read()将RS485串口设置为阻塞侦听状态,并在数据到来时进行数据接收和缓存处理。随后,在采集点设备中按照图5-2所示的代码流程进行协议转换处理,得到可以基于Modbus/TCP协议进行通信的目标数据。
图5-2 系统串行链路Modbus通信处理流程
在图5-2中所示的代码流程中,tty_write()函数的指令下发操作时采用R/W模式,在内部调用open()函数开启GPIO端口,并加载GPIO的数据处理功能,同时在GPIO端口参数设置中将波特率、字符长度、停止位分别设置为4800、8比特长度以及1,并且由于不需要进行数据校验处理,所以讲GPIO端口的奇偶校验位设置为0。开启GPIO端口的主要原因是由于RS485串口的供电电压为3.3V,如果出现供电不足的问题,则会导致RS485串口读取的数据中出现收尾字节的数据错误。在RS485串口的参数设置中,将其编号设置为ttyS4,并将其serial_mode设置为NON_CONTROL_DISTERB_ENABLE模式,即采用不可终端方式进行用电信息采集结果的接收处理。在最后的数据上报过程中主要是通过write()函数调用将从RS485串口读取的数据写入到临时缓冲中,并在缓冲头部设置1字节的Modbus串行数据标记符,数据内容为全零数据,用于标记接收到的数据为基于串行Modbus协议的数据包。
5.2.4 后台TCP通信功能实现
后台通信功能是指本系统Web服务器中和前文介绍的供电端现场硬件体系之间的通信功能,对应了系统网络结构中的后台TCP/IP通信功能组件。后台TCP通信功能主要是通过和现场硬件体系中的各个通信设备进行交互,实现现场硬件控制指令、数据采集指令等下行数据的下发,以及设备反馈信息(包括了手动设备巡检处理的被动响应数据和现场设备自动上报的主动状态数据等方面)和采集结果数据等上行数据的接收。
在具体的功能实现过程中,由于后台TCP通信功能属于标准的基于TCP/IP网络协议的以太网通信,所以采用了Java EE平台中的TCP/IP Socket套接字技术进行实现,具体的功能包括了下行数据的下发处理和上行数据的接收处理两个方面,通信协议均采用TCP通信协议。后台TCP通信功能采用标准的以太网Socket技术开发,以上行数据的接收功能为例,系统Web服务器后台作为通信过程中的服务器端,现场的网络通信设备作为通信过程中的客户端,其具体的数据通信功能实现框架如图5-3所示。
图5-3 后台TCP通信功能实现框架
按照图5-3中所示,在现场硬件的采集结果数据以及设备状态响应数据等上行数据的通信过程中,系统在Web服务器后台开启8399端口进行监听,各个现场通信设备在需要进行通信时,通过创建基于TCP协议的Socket套接字连接Web服务器主机的8399端口,并将数据以TCP协议进行封装和发送。
在Web服务器后台通过端口监听的方式,在接收到现场通信设备的数据上报请求之后,通过创建新的数据接收线程的方式将数据的接收过程封装在独立的线程中进行接收和解析处理,并向现场通信设备发送数据,同时等待接收现场设备的反馈信息。
其中,作为客户端的现场通信设备采用路由器、RTU单元等具有内置TCP数据转发的网络设备,因此在功能实现过程中只需要对系统Web服务器后台的TCP Socket套接字通信功能进行开发即可(相关代码略)。
系统的Web服务器在接收到现场硬件的上行数据发送请求之后,采用独立线程的方式将数据的接收及解析处理过程放在单独线程中进行处理,按照不同类型的数据进行解析与后台存储,作为系统前台Web服务功能运行的数据支持。下行数据的处理过程和上行数据处理过程基本类似,区别在于Web服务器后台按照具体的下行数据类型及操作请求,将对应的数据基于TCP Socket套接字发送到对应的现场通信设备中。
5.3 系统功能实现
本节对用电信息采集子系统的前台Web服务功能的开发实现工作进行介绍分析,采用Java Web开发技术对系统中的4个功能模块进行具体的逻辑流程分析和实现。在Web服务的后台响应过程中,系统采用JavaBean组件的方式对JSP Web页面的操作请求进行响应,并基于SSM模式实现前后台逻辑组件和视图容器的调度交互。
5.3.1 定时任务管理功能实现
按照定时任务管理模块的功能逻辑框架设计,在实现过程中需要在后台以任务集合的方式响应客户端的操作请求,并利用后台通信组件实现定时任务的周期性用电信息远程采集。在功能实现中将定时任务的增删改查等基本操作功能封装为TimelyTaskActive功能类,在其中按照定时任务的基本信息基于MyBatis组件以及定时任务数据对象类TimelyTask、外部数据映射配置文件,按照前台交互要求实现对定时任务的静态信息管理操作。
在TimelyTaskActive功能类中提供了定时任务创建createTask()、定时任务编辑editTask()、定时任务查看queryTask()、定时任务删除deleteTask()等用于定时任务静态数据维护管理的成员函数。以其中的定时任务创建功能为例,系统通过调用createTask()成员函数按照前台页面提交的任务创建参数,在内部构建对应的定时任务数据对象,随后利用数据库会话机制和数据对象映射的方式将新创建的定时任务进行持久化存储。
(createTask()函数的关键代码逻辑略)。
在定时任务创建的过程中,系统首先根据定时任务创建JSP页面传递的POST参数进行TimelyTask数据对象的实例化,包括了任务的名称、用户类型、数据类型、采集周期、启用时间等方面。随后通过获取Web服务器端的SESSION全局变量的方式,从其中读取“USER”子变量,将其中保存的当前登录用户信息和TimelyTask数据对象进行关联。最后基于TimelyTask数据对象以及当前用户信息,在MyBatis组件的支持下,通过读取保存在外部XML文件中的定时任务数据对象配置信息,创建后台Oracle数据库的SESSION会话,以INSERT指令的方式进行持久化存储操作。定时任务创建功能的运行效果如图5-4所示。
图5-4 定时任务创建功能运行界面
电网运维人员通过在图5-4中录入新的定时任务的基本信息以及所需采集的数据单元内容之后,通过点击确定按钮,系统在后台基于图5-4中所示的内部逻辑创建对应的定时采集任务。新建的定时采集任务属于静态任务,即仅保存在任务集合中,并未实际进行执行。定时任务管理模块中的定时任务上报功能实现了定时任务的执行启动操作,在实现过程中通过在TimelyTaskActive功能类中定义任务上报函数submitTask(),按照任务属性中的采集周期参数以及日期参数提交执行,并与后台的网络通信功能组件进行交互,实现从供电端现场硬件中将任务中指定的用电信息进行远程采集。
(submitTask()函数的关键代码逻辑流程略)。
定时任务的上报处理中首先通过对任务的上报状态进行更新,基于TimelyTask定时任务数据对象将Oracle数据库中保存的任务状态更改为“已上报”。随后,在当前已经处于执行状态的采集任务列表中添加当前任务,该列表由系统在启动时初始化,根据Oracle数据库中保存的所有已上报任务,以列表对象的方式进行逐个保存,同时创建调度线程和对应的定时器对象,根据每个任务设置的采集周期和后台通信组件进行交互,按照其中的任务参数进行用电信息采集、解析、保存等逻辑处理。
5.3.2 采集质量检查功能实现
采集质量检查模块为电网运维人员提供了已执行任务的抄表成功率和采集成功率的在线查看功能,同时针对采集失败的任务可以进行手动任务补召操作。其中,抄表成功率可以按供电单位、终端类型、终端厂家、用户类型、电表通讯类型进行查看,系统通过对供电单位、电表总数、成功电表数、暂停电表数、失败电表数、采集成功率进行统计和计算,将其返回页面展示;采集成功率可以按供电单位、终端型号、终端厂家、用户类型、采集方式进行查看,系统通过对供电单位、通信总次数、通信失败次数、通信失败数、通信成功率进行统计和计算,将其返回页面展示。
在采集质量检查功能模块的实现过程中,抄表成功率和采集成功率的在线查看功能封装在OperateRateActive中进行处理,其中采用calculateRateByType()成员函数实现对不同类型的抄表成功率和采集成功率进行计算。
(核心代码略)。
其中,按照用户类型进行采集成功率查看的功能运行页面如图5-5所示,系统按照电网运维人员选择的成功率查看条件及类型,将指定时间范围内的数据按照上述代码进行内部计算与返回,将其以列表形式按照查看条件进行页面展示。
图5-5 抄表成功率查看功能运行界面
同时,在采集质量检查模块中还可以针对执行失败的采集任务进行查询检索,并发起数据补召请求,通过人工手动的形式重新执行失败任务。数据补召功能是通过FailureTaskActive活动类结构处理,其中提供的方法函数包括了失败任务的查询函数queryFailedTask()以及数据补召函数recollectByTask()等,前者实现了按条件进行失败任务的查询、统计处理,后者实现了手动数据补测的功能。
(核心代码略)。
在任务补召功能中,系统按照电网运维人员提交的查询时间参数,将执行失败的任务按照用户类型以及任务进行分类,展示任务执行的成功数量、失败数量以及成功率等,并由用户决定是否对执行失败的任务进行手动任务补召,其运行页面如图5-6所示。
图5-6 失败任务查询结果查看功能运行界面
如果电网运维人员点击失败任务补召按钮,则系统弹出如图5-7所示的页面,在其中用户可以通过选择指定任务对应的终端设备,点击单点补测按钮,以手动形式向供电端现场硬件发送采集请求,获取实时用电数据信息。
图5-7 失败任务补召功能运行界面
5.3.3 设备监测管理功能实现
在设备监测管理模块中,系统通过后台通信功能组件持续监听现场设备主动上报的异常告警信息,同时支持人工对于设备主动远程维护的操作,包括了针对单个终端设备的实时工况查询以及采集点设备的批量巡检操作等。电网运维人员可以通过条件查询的方式查看系统接收到的设备异常告警信息,同时可以查看手动远程维护管理得到的反馈信息。
其中异常告警信息是由系统在后台以持续监听的方式,将从现场设备接收到的异常告警信息进行后台保存,在此基础上为用户提供告警数据查询功能支持。
异常告警查看功能及后台的数据接收功能封装在自定义的设备告警管理类DeviceAlarmActive活动类中,其中采用queryAlarmByParam()成员函数执行告警信息的查询操作,并利用acceptAlarmFormDevice()成员函数进行设备的异常告警信息的监听、接收、解析、持久化存储等操作,在功能处理过程中采用的数据对象为DeviceAlarm数据对象类。
(异常告警信息管理相关功能的核心代码略)。
系统采用上述代码进行异常告警信息的查询检索之后,电网运维人员可以根据具体的设备异常情况,手动发起设备异常补录请求,按照设备现场维护人员的工作结果,将设备异常的实际处理情况录入到本系统中,其中包括了异常原因、处理的具体内容、处理时间等方面,其运行页面如图5-8所示。
图5-8 异常补录功能运行界面
在设备实时工况查询功能中,电网运维人员可以按照生产厂家、通道类型、供电单位等参数,向供电端现场设备发送实时运行工况状态的查询请求,包括了采集点设备以及调试设备等,并按照现场返回的工况数据将设备总数、暂停设备数量、在线设备数量以及离线设备数量进行统计和展示。
在功能实现中将上述功能封装为RealtimeStatusActive活动类,通过其中的getDeviceStatusByParam()成员函数按照工况查询条件,向现场设备发送工况采集指令,同时采用calculateStatus()成员函数根据采集到的实时工况进行数量统计处理。
(核心代码略)。
实时工况的查询可以按照多种类型进行查询,其中的按照下属供电单位进行查询的运行页面如图5-9所示,系统将所有下属供电单位的终端设备在线的实时情况进行数量统计与展示。
图5-9 设备实时工况查询功能运行界面
设备批量巡检功能是指针对供电端现场的采集点设备进行远程调试,通过向调试设备发送巡检指令,将连接在调试设备中的采集点设备的事件信息以及状态信息等数据进行远程采集,并将其以图形化方式进行展示。
设备批量巡检功能在实现过程中是通过自定义类DevicePatchCheckActive活动类实现,在其中封装了选择目标采集点设备selectTargetDevice()成员函数、createCheckCodeByParam()创建巡检指令成员函数、发送现场设备巡检指令sendCheckCode()成员函数、统计巡检结果成员函数calculateCheckResult()等,其中的核心代码略。
设备批量巡检功能的运行页面如图5-10所示,系统按照电网运维人员选择的巡检目标采集点设备以及巡检内容,采用上述代码以及后台通信功能组件,将巡检指令发送到采集点设备连接的调试设备中,后者将巡检指令中指定的采集点设备相关数据进行采集和返回,系统将其以列表形式进行展示,用户可以在其中进行巡检结果的在线打印以及导出处理。
图5-10 设备批量巡检功能运行界面
5.3.4 手动采集管理功能实现
手动采集管理模块包括了针对采集点设备的数据召测管理和针对现场智能电表的手动远程穿透抄表两个方面。在功能实现过程中主要是按照电网运维人员在JSP Web页面中提交的数据召测和穿透抄表参数,利用系统Web服务器主机的后台通信功能模块向供电端现场的采集点设备和智能电表设备发送操作指令,并接收现场设备返回的响应数据。
在数据召测管理功能中,系统按照电网运维人员选择的采集点设备以及所需采集的终端数据类型,包括了状态数据、事件数据以及冻结/统计数据等,向采集点设备发送数据采集请求,并将接收到的采集结果数据以列表的形式进行页面展示。数据召测功能的实现采用自定义类VolunicaterActive活动类实现,其中封装了抄表设备选择selectCollectDevice()成员函数、抄表设备数据召测指令字符串的创建createVolunicateCode()成员函数、sendVolunicateCode()发送召测指令成员函数以及接收召测结果成员函数receiveVolunicateResult()等,其中的核心代码略。
数据召测管理功能的运行页面如图5-11所示,电网运维人员可以在其中选择单个或多个采集点设备,并在可召测的数据类型中选择具体的采集数据,随后点击采集按钮向采集点设备发送召测指令,并将接收到的结果展示在结果列表中。
图5-11 数据召测功能运行界面
穿透抄表是指系统直接和供电端现场的智能电表设备进行交互,从中读取更为丰富的用电信息,包括了正向有功电能、反向有功电能、正向无功电能以及反向无功电能等多个方面。与自动任务采集到的用电信息相比,穿透抄表的结果数据更为丰富,同时可以为电网运维人员提供更为灵活便利的用电现场情况检查支持。
在功能实现过程中,穿透抄表功能是通过自定义类CutRecordActive活动类处理,其中封装了抄表设备选择selectCollectDevice()成员函数、测量点选择selectPowerMonitor()成员函数、抄表数据类型设置setCollectDataType()成员函数、发送穿透抄表指令sendGatherCode()成员函数以及receiveGatherResult()接收抄表数据成员函数等。
穿透抄表功能的运行页面如图5-12所示,电网运维人员在选择了采集点下的测量点设备,即智能电表装置之后,并选中抄表功能项,随后点击穿透抄表按钮,系统自动基于后台的通信功能组件向远程设备发送抄表指令,并将接收的抄表结果在列表中展示。
图5-12 穿透抄表功能运行界面
5.4 系统测试
用电信息采集子系统在开发完成之后,针对系统中的上层软件Web服务功能、后台通信功能以及采集点中的嵌入式通信功能进行了测试,同时还对系统的性能表现进行了测试分析。
5.4.1 系统测试环境
用电信息采集子系统的测试环境如表5-1所示。
表5-1 用电信息采集子系统测试环境
5.4.2 系统功能测试
1. Web服务功能测试
Web服务功能测试是针对本系统的上层Web服务进行测试,即考察系统是否能够正常访问、各Web页面显示效果是否正常、上层应用管理功能逻辑是否正确等,具体测试用例如表5-2所示。
表5-2 系统Web服务功能测试用例
系统的Web服务功能测试对系统上层Web系统的功能响应情况进行了测试分析,采用模拟数据对供电端现场的硬件情况进行模拟,并提前录入用于系统功能操作响应的设备数据、抄表数据等基本信息,查看系统的Web页面响应情况以及功能操作过程是否符合要求。按照系统的内部功能结构体系,对系统的各个功能模块进行页面访问,得到系统的页面响应均符合预期,并且Web页面布局也能够兼容IE浏览器,因此可以得到系统的上层Web服务功能测试通过。
2. Web服务器后台通信功能测试
Web服务器后台通信功能测试主要针对本系统服务器端和供电端现场硬件体系之间的数据交互过程是否正常,是否能够满足本系统和硬件体系进行采集数据交互以及控制指令下发等过程的网络通信要求,具体的测试用例如表5-3所示。
表5-3 系统Web服务器后台通信功能测试用例
系统的Web服务器后台通信功能测试主要采用了模拟数据的方式,检查系统是否能够通过后台通信功能组件从供电端现场硬件体系中正确接收数据,并将数据记录在临时文件中进行查看。通过对后台通信功能进行测试,系统的Web服务器后台能够正确从现场硬件体系中的通信设备中接收预先设置的模拟测试数据,并将其写入到临时文件中。所以,可以得到系统能够正常与现场硬件体系进行网络交互,实现硬件体系的上行数据和下行数据的接收与发送。
3. 采集点设备Modbus通信功能测试
系统的采集点设备中集成了和Modbus通信相关的功能,采用嵌入式开发技术进行实现,所以在测试工作中需要对采集点设备中的Modbus通信功能进行测试,具体的测试工具采用Modbus Module Configure V4.1,测试的功能包括了采集点设备中的串行Modbus通信功能、Modbus/TCP通信功能两个方面。
(1)串行Modbus通信功能测试
在串行Modbus通信功能的测试过程中,将测试所用的Modbus Module Configure V4.1工具安装在测试所用的PC主机中,同时将用于测试的采集点设备采用串行线路插接到PC主机的串口上,测试过程中的数据接收以及发送操作采用PC主机中安装的SSCOM 3.2工具软件来实现。在测试PC主机中打开Modbus Module Configure V4.1工具,并在其中对其串口参数进行设定,其中的波特率参数设置为9600,其它的通信参数采用默认配置值,如图5-13所示。
图5-13 Modbus Module Configure V4.1工具参数设置
将测试所用的采集点设备采用PC测试主机中的另一个串口进行插接,打开Modbus Module Configure V4.1工具,在其中设置数据发送参数为Coordinator,数据接收设备选择为Router。
在测试PC主机中打开SSCOM 3.2工具,将串口号设置为用于数据发送的COM串口,波特率参数设置为9600,其余参数全部设置为默认。随后,在SSCOM 3.2中发送自定义字符串,如图5-14所示。
图5-14 串行Modbus通信测试数据发送
同时在测试PC主机中再次打开SSCOM 3.2工具,将串口号设置为已插接采集点设备的COM串口,波特率设置为9600,其余参数全部设置为默认,查看SSCOM 3.2中的数据接收界面中得到的字符串是否和发送字符串相同,如图5-15所示。
图5-15 串行Modbus通信测试数据接收
通过SSCOM工具的收发数据过程能够得到,采集点设备中的串行Modbus通信功能能够正常实现在总线环境下的数据接收与发送,所以在采集点设备中的串行Modbus通信功能正常。
(2)Modbus/TCP通信功能测试
Modbus/TCP通信功能测试同样采用Modbus Module Configure V4.1工具和SSCOM 3.2工具进行实现,在测试过程中采用的采集点设备以及测试主机的硬件连接方式和串行Modbus功能测试中完全一致。测试环境的主要区别在于采用系统的Web服务器主机替代测试PC主机,模拟本系统Web服务器后台和采集点设备之间的网络通信。具体的测试过程如下:
参照和串行Modbus通信测试相同的参数进行Modbus Module Configure V4.1工具的参数设置,同时对SSCOM 3.2工具中的数据发送模式设置为异步模式。在Web服务器主机中采用Shell指令向串口写入测试所用的字符串,查看SSCOM 3.2工具中是否能够接收到数据,并在数据框中进行展示。在SSCOM 3.2工具中写入数据并进行发送,在Web服务器主机的Shell界面中读取测试串口的数据内容,检查是否和发送数据一致。
按照上述测试过程对系统的Modbus/TCP通信功能进行测试,模拟系统Web服务器和采集点设备之间的Modbus/TCP通信过程,得到其数据通信的处理过程均符合测试数据。
5.4.3 系统性能测试
在系统的性能测试工作中主要针对系统的Web服务功能以及后台通信功能进行了并发能力以及响应时间的测试分析,在测试过程中采用了Siege性能测试工具,将其安装在Web服务器主机中,对系统后台的相关性能指标进行监测和读取。性能测试模拟系统的实际使用过程进行测试,采用自动化测试脚本对指定并发量的系统访问以及后台通信过程进行模拟,在Siege工具中检查系统各项功能的应用过程以及底层通信过程,检查系统的承压能力,具体得到的系统性能表现结果如表5-4所示。
表5-4 系统性能测试结果表
按招标5-4中所示,通过Siege工具对系统的Web服务功能进行性能检验,得到的系统Web服务响应时间以及并发能力表现均符合性能要求,同时通过查看系统后台通信的相关性能数据,可以得到系统的供电端现场的硬件支持能力也符合要求,并且能够正确实现现场用电信息的远程采集。另外,通过将系统在所在供电公司内部进行部署应用,大大降低了公司的用电信息采集业务的人力资源成本,将采集过程采用自动化的方式进行远程实现,有效提高了抄表业务的整体效率,提高了公司的整体供电服务能力。
5.5 本章小结
本章对用电信息采集子系统的功能实现以及系统测试工作进行了详细分析与阐述,通过展示系统的开发环境,对系统的后台通信功能实现过程进行分析与介绍,同时针对系统Web服务中的4个核心功能模块进行了开发实现。最后,还对用电信息采集子系统的测试工作进行介绍,给出系统的测试环境,以及具体的功能测试和性能测试的过程以及测试结果等。
声明:本站毕业论文范文资源均由鼎诚文创收集于互联网,如有侵权,请联系删除!