其他毕业论文范文

根据系统的功能和非功能需求分析，在《供电公司用电信息采集子系统设计与实现》这篇计算机软件工程专业的硕士毕业论文第四章中，详细介绍了用电信息采集子系统的功能设计原则、通信功能设计、总体设计、功能模块设计和数据库设计等。

4 系统设计

本章对用电信息采集子系统进行详细的功能设计，介绍系统设计工作中遵循的基本原则，并按照系统后台硬件体系结构、网络结构、功能框架、各个功能模块、后台数据库的顺序，对具体的功能设计工作进行详细分析和阐述。

4.1 系统设计原则

对于用电信息采集子系统而言，其运行的环境相对较为复杂，并且涉及到大量的后台数据通信交互操作，对于系统的运行可靠性、安全性等要求较高，因此在系统的功能设计工作中需要遵循层次化原则、完备性原则和可靠性原则，为系统的功能研发工作提供保障。

1. 层次化设计原则：按照系统需求分析，其结构层次主要包括了上层管理软件、中间数据通讯通道、供电端现场硬件体系三个层次，并且在现场硬件体系中还包括了各类终端设备之间的总线通信层次等，因此在系统功能设计中需要按照上述层次划分，对每个层次内部的功能逻辑和技术模型进行设计，并在各个功能层次之间采用标准化的接口实现层次之间的业务逻辑交互处理，从而确保系统在后续的维护过程中，不会由于单个层次功能逻辑结构的变化而导致需要对其他层次的内部逻辑结构进行重新设计和研发。

2. 完备性设计原则：本系统的研发是为了提高公司用电信息采集业务的自动化程度，以远程采集和维护的方式提高电网运维人员的工作效率。因此，在系统功能设计中需要严格按照当前公司在供电用户用电信息采集过程中的实际需求，在功能体系结构方面需要全面覆盖业务需求，达到功能的完备性。

3. 可靠性设计原则：由于本系统的层次结构体系相对较为复杂，涉及到的相关技术要点较多，并且其中处理的用电信息对于公司而言具有较高的商业价值。所以在功能设计工作中需要确保系统每个层次功能方案的合理性，以及各个功能层次之间的交互接口统一性，采用标准化的软件设计工具与技术，选择合理的开发技术，提高系统在运行过程中的功能可靠性。

4.2 系统后台通信设计

用电信息采集子系统的后台通信主要是指本系统中面向终端用户的管理软件和供电端现场硬件设备之间的数据通信过程，包括了用电信息采集任务指令、设备巡检指令、手动采集指令等控制命令的下发，以及用电信息采集结果、设备调试/故障/状态信息等数据的上报两个方面。

4.2.1 总体通信结构设计

按照系统的结构分析，从逻辑角度来看，系统的后台通信过程主要包括了智能电表和采集点之间、采集点/调试设备与通讯设备之间、通讯设备与系统上层软件之间的数据交互，如图4-1所示。

图4-1 系统后台通信网段划分

按照图4-1中所示，供电端现场硬件体系是通过各个通讯设备，例如RTU单元、路由器等，在电力通信专网环境下接入到本系统上层管理软件服务器中。电力通信专网由公司提供，通常采用无线或有线的基于TCP/IP协议的以太网实现，包括公司自主组网和网络供应商专用网络租用两种形式。在现场硬件体系中采用现场总线实现各类终端设备的物理连接，所以其设计任务主要集中在各个现场总线的通信协议及通信方案的选择和设计，其中的技术难点说明如下：

1. 总线通讯协议的选择：目前可用的总线通信标准以及网络协议种类较多，在设计工作中需要按照实际的要求，从中选择可靠性和性价比较高的协议体系。

2. 通信数据的协议转换：上行数据和下行指令的通信需要跨越TCP/IP网络和现场总线网络，因此如何在两种不同技术规格的网络之间实现通信数据的格式化转换处理，是确定了总线通信协议之后，所需重点考虑的技术问题。

3. 硬件内部通信模块研发：在确定了总线通讯协议以及数据协议转换的技术方案之后，在各类现场硬件中需要以嵌入式软件开发的形式，在设备内部集成协议转换功能组件和模块，对于其中的软件功能处理以及逻辑流程设计需要采用可靠的技术以及工具，对其进行开发实现。

在目前众多的总线通信技术标准和协议中，Modbus工业现场总线通信协议具有数据通信可靠性高、部署便利、通信速率良好等优点。因此，在本系统后台通信体系中的现场总线通信协议采用了Modbus技术，利用了其中的串行Modbus技术和Modbus/TCP技术分别实现智能电表和采集点之间、采集点和通讯设备之间的数据通信，具体的功能体系结构设计如图4-2所示。

图4-2 系统后台通信功能体系结构

按照图4-2所示，系统后台通信功能体系中，智能电表设备和采集点之间采用数据传输更为高效和可靠的串行Modbus技术实现，采集点和调试设备、通讯设备之间利用Modbus/TCP技术实现Modbus协议和TCP协议之间的数据转换处理，为本系统的Web服务器后台提供基于标准的TCP/IP以太网通信协议技术标准的数据交互功能。

因此，系统后台通信功能的设计与研发主要集中在各个采集点设备中，在其中需要以嵌入式的方式集成关于Modbus通信技术的相关功能组件。采用上述技术方案的优势在于充分发挥Modbus工业现场通信技术的硬件支持能力以及通信效率，实现大量智能电表的用电信息采集结果的上报，同时基于各个采集点的数据协议转换，为本系统的服务器后台提供基于TCP/IP以太网协议标准的数据处理支持，便于上层软件的功能开发。

4.2.2 Modbus通信协议设计

在采集点设备中需要进行Modbus/TCP协议以及串行Modbus协议之间的数据格式转换，所以在后台通信设计工作中首先需要按照数据通信要求进行协议结构的设计，具体包含Modbus/TCP协议数据包格式定义及内部的数据帧结构定义。

1. Modbus/TCP数据包结构

在采集点设备中的内部数据需要基于Modbus/TCP协议进行数据格式化处理，采用其中的硬件寄存器作为数据格式转换的物理媒介，在具体的数据包格式设计中采用基于特定寄存器的固定偏移位作为设计基础，按照不同的数据信息请求或者响应的类型，设置固定偏移位。例如，假定设置的偏移位为4位，读取的首地址为U19位，其中存储的数据为5，则在Modbus/TCP协议中，上述操作过程的请求数据信息以及响应数据信息的数据包格式定义如图4-3所示：

图4-3 Modbus/TCP通信协议数据包格式

按照图4-3中所示，在Modbus/TCP协议的请求数据包以及响应数据包中均包含了一个共计8字节的前缀数据标志串，按照Modbus技术的规范，各个字节的具体含义与内容在此不展开介绍。

2. Modbus协议数据帧格式

按照上述Modbus/TCP协议的数据包格式定义，在其中的数据帧中采用Modbus协议封装与智能电表之间交互上行数据和下行数据。在数据帧格式定义设计中，采用同样的数据读写参数，即偏移位设置为4，读取和写入地址为U19，则在数据的具体读写处理过程中，其数据帧的内部格式如图4-4所示：

图4-4 Modbus数据帧结构定义

按照图4-4所示，在Modbus数据帧结构中，仅保留从站地址说明符合Modbus协议功能代码标记，随后的数据均为实际的数据读取请求和反馈数据。目前在Modbus/TCP协议的数据校验方面未提供必要字段的默认支持，因此在数据包格式以及数据帧格式的定义中均未加入“CRC-16”、“LRC”等用于数据校验处理的数据位，所以在实际的应用过程中，本系统对于后台通讯数据的差错校验以及安全验证等过程，均采用TCP/IP以太网通信协议中各个协议栈的校验机制来实现。

另外，在基于上述协议数据格式的信息读写处理之前，采集点设备与其他终端现场硬件之间的通信连接过程还需要进行必要的注册处理机制，并且直接采用通用的串行Modbus协议发送注册标志即可。在完成注册并激活通信通道后，采集点设备作为Modbus通信的中心节点，负责接收其他终端设备的Modbus登录请求，在登录请求数据包中封装报头信息（2字节，分别为0x68和0xc5），以及代表该登录设备通信编号的ID串，共计5个字节，另外还分别包含长度为1字节的校验码以及尾部标志符（0x16）。采集点设备在接收到上述登录数据包之后，即可与该终端硬件设备进行基于Modbus协议的数据交互通信。

4.2.3 Modbus通信方案设计

在Modbus通信协议格式设计完成之后，还需要针对系统后台通讯过程中的通信兼容性问题，即通过对应的方案设计，解决现场硬件体系中以Modbus协议封装的数据和上层通信体系、管理软件中面向的TCP/IP协议体系之间的数据转换处理。由于现场采集到的用电信息、设备反馈信息等均采用Modbus协议处理，而本系统的通信节点以及Web服务器之间的通信是基于TCP/IP以太网进行通信，因此在Modbus通信方案设计中的关键在于Modbus协议和TCP/IP协议之间的协议数据格式转换问题，具体表现为本文所选的Modbus/TCP协议和串行Modbus协议之间的协议格式转换。

在Modbus通信方案设计工作中需要对本系统Web服务器后台与各个通信节点之间的以太网通信功能以及采集点设备和其他现场硬件之间的Modbus通信功能进行设计，后者主要利用Modbus/TCP协议和串行Modbus协议进行设计。在Modbus协议技术规范中约束了交互双方通信的数据包格式，并且对于底层物理通信介质没有固定要求，交互双方的数据包在发发送之前和接收之后的处理过程只要符合Modbus协议技术规格即可，即按照Modbus协议的头部格式以及数据域的帧格式进行处理。在本系统面向的供电端现场中，所有的采集点设备、调试设备、网络设备等均预先设置了唯一的通信地址标记符，所以在数据收发过程中按照Modbus协议技术规范进行处理。

具体而言，在Modbus/TCP协议和串行Modbus协议的数据转换过程中，首先在Modbus数据帧中包含的ADU标记单元中记录通信过程的域标记信息，随后基于TCP/IP以太网环境进行数据交互通讯，上述ADU标记单元中记录的数据作为TCP/IP通信过程中的MBAP报文头部标记。采用上述方法能够将以Modbus数据帧格式封装的交互数据在以太网环境中进行通信，并且不会由于TCP/IP报文的切割问题而影响到接收端的Modbus协议的报文解析处理。所以在本系统的Modbus通信方案中主要采用了基于ADU数据单元中的MBAP报文头的读取和更新作为基础，对于PDU数据单元不进行自定义更改，具体的Modbus通信方案技术模型设计如图4-5所示。

图4-5 Modbus/TCP协议数据格式转换处理流程

在图4-5中，其他设备主要分为和采集点设备有数据交互关系的智能电表设备、调试设备等，并且是采用RS485总线进行物理连接，并基于Modbus协议实现数据通信。从图中可以看到在Modbus/TCP协议数据的格式转换处理过程中主要是通过在采集点设备内部针对目标数据进行BMAP报文头和CRC校验码的设置或去除来实现，具体的逻辑处理步骤包括如下方面：

1. 对于新增的采集点设备，需要首先通过中间的通讯设备向本系统的上层软件服务器发送登录指令，由现场安装人员在线路接通之后手动上报。随后，该采集点设备即可接收上层软件下发的各类指令，在下发过程中所有通讯数据采用Modbus/TCP协议进行数据封装，并在以太网环境中通过现场的网络通讯设备传输到采集点设备。

2. 下行数据基于以太网环境发送到采集点设备之后直接进行数据包内容的解析，并在解析结果中进行MBAP头部信息剔除操作，随后对去除了MBAP头部信息的数据进行CRC校验操作，并将得到的CRC校验码写入到数据尾部，得到基于Modbus协议技术规范的数据包，并通过现场RS485总线向其他设备下发。

3. 其他设备接收到基于Modbus协议的数据包之后，按照自定义的Modbus协议数据包以及数据帧的格式设计，解析得到具体的下行指令，并按照指令的内容执行对应的操作，例如用电信息读取或者设备调试、状态读取等，并将读取的结果同样采用Modbus协议格式进行封装和上报。

4. 采集点设备在接收到其他设备上报的数据之后，首先将数据包中的CRC校验码进行去除，随后根据数据帧的内容长度，在数据包头部添加MBAP信息，得到基于Modbus/TCP协议技术规范的数据包，并利用TCP/IP以太网通信协议将上述数据包作为数据内容进行封装，最后将其通过现场网络通讯设备发送到上层软件中进行后续处理。

所以基于上述分析，系统后台通信体系中的主要逻辑操作均集中在采集点设备中，并且利用对通信目标数据进行格式转换，达到采集点设备和上层软件之间采用通用的TCP/IP以太网通信规范，现场硬件体系中采用Modbus总线通信规范的目的。采用上述方案的优势主要是将整个后台通信的逻辑处理过程按照实际的现场硬件拓扑结构分散到各个直连设备之间，有助于对网络通信过程的流量进行控制，提高数据通讯效率，并且能够充分利用现场的总线通信网络，不需要增加额外的硬件连接。同时，上述技术方案还可以充分利用Modbus协议技术中的工业级的可靠性优势，与常用的TCP/IP以太网通信技术相比，Modbus通信的可靠性要更高，对于用电信息采集结果等具有较高商业价值的数据通讯而言，在交互过程中的可靠性会大大提升。

4.3 系统整体结构设计

在系统后台通信功能设计的基础上，本节对用电信息采集子系统的整体结构进行设计，其中主要包括了从整体角度进行的系统网络结构设计和功能模型设计两个方面。

4.3.1 系统网络结构设计

软件系统的网络结构通常分为B/S（浏览器/服务器）、C/S（客户端/服务器）以及混合式3种类型，用电信息采集子系统的网络结构采用了B/S和C/S混合式的结构。其中，系统上层软件面向用户的功能体系采用B/S结构实现，以Web服务页面的形式为电网运维人员提供功能操作接口支持，并在服务器中利用Web服务发布工具，在公司内部业务网络环境下进行服务发布。系统后台通信体系的网络结构采用C/S结构，将供电端现场的和系统有数据交互关系的通信硬件、采集点硬件、调试设备作为客户端，利用Modbus/TCP通信协议作为通信技术支持，实现用电信息采集指令、设备调试指令等下行数据的下发和采集结果、调试反馈、设备状态反馈等上行数据的上报，其中的Modbus网络通讯和以太网通讯之间的协议转换采用4.2节中给出的后台通信协议以及方案实现。因此，可以得到系统的网络结构设计如图4-6所示。

图4-6 用电信息采集子系统网络结构

按照图4-6所示，系统前台和后台的服务器采用集成服务主机实现，在其中安装Web服务发布工具，作为前台网络结构的服务器，本系统采用的Web服务发布工具为Tomcat软件。同时，在系统后台采用自定义研发的基于TCP/IP套接字的网络通信功能组件，和供电端现场的硬件体系进行上行数据和下行数据的交互。前台与后台之间的数据交互基于自定义中间件实现，在其中主要处理下行指令的下发、上行数据的解析以及上述处理过程中的后台数据库的相关操作等。

4.3.2 系统功能框架设计

用电信息采集子系统的功能框架是指从上层软件的角度出发，采用功能组件结构以及逻辑模型的方式，对系统进行软件层面的整体结构设计。由于系统中面向用户的软件功能体系采用了Java Web开发技术，目前常用的支持Java Web应用开发模型数量众多，本系统在设计和研发工作中采用了目前较为常用的开源SSM开发模式，采用其中的SpringMVC组件实现系统前台应用交互体系和后台Web服务功能之间的视图映射及响应功能；采用Spring组件实现对Web服务器中的用于响应客户端Web请求的JavaBean组件的调度管理；同时采用MyBatis组件实现系统后台数据库的基于SESSION会话机制和数据对象机制的持久化操作功能。因此可以得到系统的功能框架设计如图4-7所示。

图4-7 用电信息采集子系统功能框架

按照图4-7所示，通过将系统功能需求中提出的具体开发需求项分别进行封装，以功能模块的方式进行功能组织，在SpringMVC框架中以JSP页面的方式为用户提供系统前台访问功能支持，以及Web服务器后台的页面调度、映射等功能。同时，将系统各个功能模块后台的JavaBean采用Spring组件进行管理维护，和SpringMVC中的服务机制共同组成系统的Web服务发布以及响应功能体系。在后台数据库操作过程中，采用MyBatis组件中的sqlSessionFactory组件为数据库的操作提供SESSION会话管理机制，同时采用Mapper映射管理器以及系统内部自定义的数据对象实现Oracle数据库中的业务数据的持久化操作支持。采用SSM模式对系统的功能框架进行设计，能够充分发挥出SSM开源框架模式的健壮性优势，并且能够利用其中大量的已发布的功能机制实现本系统Web服务中的通用性功能管理，降低开发难度。

4.4 系统功能模块设计

在用电信息采集子系统的功能框架中将系统内部的软件功能划分为定时任务管理、采集质量检查、设备监测管理以及手动采集管理4个功能模块，本节对上述功能模块的内部结构及逻辑框架进行设计分析。

4.4.1 定时任务管理功能设计

定时任务管理功能模块为电网运维人员提供了对大型专变用户、中小型专变用户、三相工商用户、单相工商用户、居民用户、公用配变用户等不同类型的用电用户进行用电信息周期性采集的管理功能，在其中采用定时任务的方式进行采集活动管理。按照该模块的功能需求，其功能结构中主要包括了定时任务的创建、编辑、删除以及上报管理4个方面，如图4-8所示。

图4-8 定时任务管理模块功能结构

从逻辑角度来看，定时任务管理模块中的创建、删除、修改等子模块针对的操作对象均为静态的任务数据，而上报管理则是将已创建的定时任务正式提交执行，结合系统的整体功能框架以及开发技术选择，可以得到定时任务管理模块的功能逻辑框架如图4-9所示。

图4-9 定时任务管理模块逻辑框架

在图4-9中可以看到，定时任务管理模块的前台交互操作采用任务管理的JSP页面实现，并通过对应的后台JavaBean类结构在SpringMVC组件的支持下实现前后台的Web服务映射与调度处理。在该模块内部，采用定时任务集合的方式对电网运维人员创建的定时任务进行管理维护，并且在创建过程中通过后台数据库存储的用电用户类型数据、终端设备数据、任务参数数据等作为创建过程中的参数选择支持，在此基础上为用户提供已创建任务的删除以及修改操作等。同时，对于任务的上报处理操作，系统采用类似的任务集合将所有上报成功的定时任务进行统一调度管理，按照其中的任务参数设置，通过和后台的现场硬件通信管理功能组件进行周期性调度交互，通过以太网TCP/IP协议的Socket套接字组件和供电端的采集点设备进行通信交互，实现用电信息的采集管理。所有采集得到的用电信息采用MyBatis组件以及对应的数据对象，基于SESSION会话机制和对象映射机制实现持久化存储。

4.4.2 采集质量检查功能设计

在采集质量检查模块中为电网运维人员提供了系统内部所有采集到的用电信息的质量分析与检查功能，按照其功能需求，在该模块中主要包括了采集任务检查、采集任务补召、抄表成功率检查和采集成功率检查4个子模块。采集质量检查模块的功能结构如图4-10所示。

图4-10 采集质量检查模块功能结构

按照图4-10所示，电网运维人员可以在采集质量检查模块中利用采集任务检查功能对指定时间内的某供电单位或全部供电单位的失败定时任务进行查看，随后利用采集任务补召功能对失败任务进行重新数据召测。在抄表成功率和采集成功率检查功能中，系统按照所有定时任务的执行情况，在后台计算和统计对应的抄表成功率以及采集成功率，计算方式如下：

1. 抄表成功率=（成功电表数/电表总数）×100%

2. 采集成功率=（通信成功次数/通信总次数）×100%

电网运维人员可以对系统在后台计算得到的成功率信息，以及采集过程中的通信总次数、成功次数、失败次数、电表总数、成功电表数、暂停电表数、失败电表数等信息按照供电单位进行查看、导出和在线打印操作。

在采集质量检查模块的逻辑框架设计中，按照该模块的内部功能结构，其中的采集任务以及成功率检查功能均基于系统后台保存的采集结果数据进行统计分析，任务补召功能则通过手动下发采集指令的方式，基于后台通信组件和供电端现场的采集点设备进行交互，实现对失败采集任务的手动重新执行处理，具体的功能框架如图4-11所示。

图4-11 采集质量检查模块逻辑框架

按照图4-11所示，在采集质量检查模块的逻辑框架中，通过将任务检查以及成功率查看的相关功能进行封装，以成功率管理组件的方式为用户提供采集成功率、抄表成功率的后台计算、结果查看以及导出、打印等后台功能支持；同时，将手动数据召测处理过程中的召测指令管理、后台通信、采集结果接收等操作封装为数据召测处理组件，该组件通过和后台通信组件进行交互，从供电端现场硬件中按照用户指定的参数进行手动用电信息的采集，并且利用MyBatis组件的功能接口支持，将现场返回的用电信息进行持久化保存。

4.4.3 设备监测管理功能设计

设备监测管理模块中实现了对供电端现场的硬件设备进行远程维护、监测、调试管理等基本功能，是电网运维人员在公司内部业务环境下确保用电信息采集现场硬件体系可靠性的重要功能支持。

按照设备监测管理功能的需求分析，其中包括的子模块主要有终端异常告警、实时工况查询、设备批量巡检3个方面，具体的功能结构设计如图4-12所示。

图4-12 设备监测管理模块功能结构

在图4-12中所示的功能结构中，终端异常告警子模块实现了从现场设备接收其自动上报的异常、人工现场巡检得到的异常数据的录入功能，同时还为电网运维人员提供设备异常现场处理结果的更新，以及异常告警功能。

在实时工况查询功能中实现了对现场设备的远程调试及运行状态查看功能。在设备批量巡检功能中，电网运维人员可以通过选择指定终端设备，向其发送巡检指令，将所选终端设备的指定运行状态在电力通信专网环境下进行远程获取和返回。

在逻辑框架设计中，设备监测管理模块的内部功能主要集中在和现场硬件设备的各类通信交互处理方面，利用后台通信功能组件的支持，实现对现场设备的远程监测管理，因此可以得到该模块的功能框架设计如图4-13所示。

图4-13 设备监测管理模块逻辑框架

按照图4-13所示，在设备监测管理模块的内部逻辑框架中，通过将设备监测管理的子模块分别封装为独立的功能组件，采用JavaBean的形式对电网运维人员提交的设备监测管理请求进行后台响应，并基于MyBatis组件以及设备异常数据、设备基本数据等，为设备监测管理请求的响应提供数据支持。其中，终端异常告警管理组件通过后台通信组件，接收现场设备上报的异常信息，同时还包括了电网运维人员手动录入的现场巡检检测到的设备异常信息。在此基础上，系统通过终端异常告警管理组件为用户提供现场设备异常报警之后的异常处理结果信息的录入和更新功能支持。在实时状态查看管理组件中，系统通过和调试设备进行远程交互，基于后台通信功能组件按照用户提交的查看参数，对现场设备进行远程调试，得到其实时的运行状态，并将其进行后台保存和交互展示。在批量巡检管理组件中，系统基于后台通信组件和现场的采集点设备进行状态采集交互，按照指定的参数将所选的所有采集点设备的相关状态进行远程巡检和更新。

4.4.4 手动采集管理功能设计

手动采集管理模块为电网运维人员提供了定时任务之外的用电信息手动采集的功能支持，能够按照用户的随机采集需求，在后台通过与供电端现场的采集点设备进行数据交互，按照指定参数将对应的用电信息进行手动实时采集处理。按照手动采集管理功能的需求分析，在其中主要包括了穿透抄表管理、电表数据采集和终端数据采集3个子模块，具体的功能结构如图4-14所示。

图4-14 手动采集管理模块功能结构

在图4-14中，穿透抄表管理子模块主要针对电网运维人员提交的智能电表中记录的各项用电信息采集请求，直接向指定的智能电表发送数据采集指令，将所选的用电信息进行远程实时手动采集。电表数据采集和终端数据采集子模块分别针对设备自身的运行状态，以数据召测的方式对供电端现场终端设备的和用电信息相关的自身运行状态数据进行远程采集管理。因此，手动采集管理模块为电网运维人员提供了更为灵活和便利的用电信息自动化采集的功能支持，是系统自动定时采集操作的重要补充。由于手动采集管理模块中的各项功能在逻辑结构上具有较高的共性，都是通过按照用户在前台JSP页面中提交的手动采集请求，在后台基于后台通信功能组件和供电端的现场硬件进行交互，在此过程中基于MyBatis组件实现逻辑操作所需的各项数据库操作处理，因此可以得到系统的手动采集管理模块的逻辑框架设计如图4-15所示。

图4-15 手动采集管理模块逻辑框架

按照图4-15中所示，在手动采集管理模块中将穿透抄表、电表数据采集和终端数据采集过程中的采集参数解析、交互命令处理的功能封装为采集参数管理组件，并将与后台通信功能组件进行现场交互的相关逻辑封装为采集管理组件。电网运维人员通过JSP页面提交的手动采集请求首先下发到采集参数管理组件中进行解析等处理，随后采集管理组件按照参数解析结果，通过MyBatis组件将后台交互过程中所需的相关参数进行检索，并提交到后台通信组件中进行具体的远程信息采集操作。在现场数据采集完成之后，采集管理组件利用MyBatis组件按照采集类型将现场返回的采集结果进行持久化更新保存。

4.5 系统数据库设计

用电信息采集子系统的后台数据库管理系统采用Oracle数据库，并且由于本系统是公司电网运维中心中的业务子系统，所以系统的数据库采用了和中心其他信息软件共享数据库的方式进行设计。本节按照实际的数据库设计工作以及系统的功能研发情况，对数据库中的主要数据表结构进行设计和介绍。在用电信息采集子系统中处理的业务数据主要是以用电信息的采集结果（包括用电信息采集结果、手动采集管理中的电表采集结果和终端采集结果3种类型）、采集任务、设备状态、异常告警等动态数据为核心进行数据库设计，同时为了实现系统的各项功能，还需要大量的辅助性静态数据，例如终端设备信息（包括采集点、通讯设备、调试设备、智能电表等）、设备类型信息、设备操作指令、设备调试指令、用电用户信息、用电用户类型信息、电网运维人员信息，上述静态数据在本系统中不进行更改操作，仅通过后台检索作为用电信息采集过程中的辅助性数据，并且在维护过程中是通过公司的用电用户业务管理平台中的其他软件工具实现，本系统直接通过后台数据库只读的方式进行数据读取即可。本节以其中的定时采集任务数据表、用电信息采集结果数据表、终端设备异常数据表、电表数据采集结果、终端数据采集结果为例，对数据库的结构设计进行介绍。

（数据表具体结构设计略）

4.6 本章小结

本章对所在供电公司组织研发的用电信息采集子系统进行了详细的功能设计，研究的内容主要包括了系统的设计原则介绍，系统后台的Modbus协议通信功能设计，系统各个功能模块的内部结构设计以及系统的后台数据库设计等。

声明：本站毕业论文范文资源均由鼎诚文创收集于互联网，如有侵权，请联系删除！