综合能源平台EMSV1.3概要设计说明书

综合能源平台EMSV1.3概要设计说明书目 录1 引言71.1 编写目的71.2 项目背景71.3 定义81.4 参考资料82 任务概述82.1 目标82.2 运行环境82.3 需求概述92.3.1 功能需求92.3.2 数据容量需求102.3.3 性能及其他102.4 条件与限制113 总体设计113.1 总体结构113.2 部署方案113.3 数据模型113.3.1 统计对象模型113.3.2 数据源模型123.3.3 算法模型123.3.4 第三方接口模型123.4 模块功能123.4.1 系统配置相关（林）123.4.2 系统权限133.4.3 系统日志133.4.4 告警相关业务（陈安靖、郭健、王文杰）133.4.5 能耗模型及算法处理143.4.6 报表报告业务相关143.4.7 邮件短信推送服务153.4.8 平台层通用WebService153.4.9 Redis通用消息总线153.4.10 数据加工服务163.4.11 配电智能照明FLEX163.4.12 移动APP163.4.13 进程守护和监控（看门狗）163.4.14 WEB业务模块164 接口设计174.1 外部接口174.2 内部接口175 数据结构设计175.1 公共常量定义175.1.1 模块命名前缀定义175.2 独立数据库设计175.2.1 物理结构设计185.2.2 逻辑结构设计186 运行设计196.1 运行模块的组合2016 206.2 运行控制216.3 运行时间217 错误处理设计217.1 系统级故障与错误217.1.1 采集数据缺失或异常217.1.2 网关通信中断227.1.3 网关软硬件异常227.1.4 服务器软硬件故障227.1.5 数据访问和存储能力237.2 容错处理对策237.2.1 通信心跳与链路保持237.2.2 看门狗服务237.2.3 数据缓存与重传修复248 安全保密设计248.1 网关通信248.2 开放服务接口249 维护设计249.1 日志系统249.2 数据库备份259.3 软件产品安装和自动升级259.4 运行监测与报警251 引言1.1 编写目的本文档是在“能源管理系统EMSV1.3“需求规格说明的基础上，进行详细需求分解和技术应对后得出的概要设计说明书，旨在明确目标系统的总体结构、接口形式、数据模型，以及重要业务流程和对象的设计，并明确需求用例的各个功能点在架构中的体现，为后续的详细设计、编码实现以及产品测试等工作提供指导性规范。1.2 需求概述1.2.1 功能需求本项目设计研发的EMSV1.3系统功能需求概述见图，其中可分为三个层次：1、数据加工底层模块优化考虑到EMSV1.2系统在现场项目高并发的极端场景下，数据入库会出现延迟和锁表的故障。本系统在此次的开发任务中将对现有的系统进行优化，新增消息总线的机制，保证系统在数据加工业务模块的稳定。2、所有子系统的权限和配置整合分析现有的能耗监测子系统、照明子系统、配电子系统、用能计费子系统。将现有的几个子系统全部以B/S的方式集成为一体，将其中的用户和权限进行统一的规划设计，完成权限的整合。对现有各个子系统中的配置进行梳理，整理出通用必须的配置和各个模块的特定的业务配置。通过场景的方式对配置业务模块进行统一的规划和设计。3、 基础业务功能的实现完成EMSV1.3需求说明书中的功能需求。图1 EMSV1.3功能需求模型1.2.2 数据容量需求系统数据容量计算：数据采样周期：支持最小数据采集周期为5分钟，上层应用提供的时间周期可选10分钟、15分钟、20分钟、30分钟、1小时、天、月、年。本系统的业务规模，最大设计支持的采集点数量为100,000，支持主备处理和分布式扩展，保留向更高容量扩展的能力。1.2.3 性能及其他本项目设计研发的EMSV1.3系统对应的关键性能及其他方面的需求如下：（1）安全可靠千兆接入网络，支持大规模并发数据流量接入;（2）对主要数据和功能进行安全隔离；（3）具备统一的运行监管功能，对主要模块的运行状态进行统一监管，要求具有良好的运行监测、负载监控管理、流量监控、故障分析和故障恢复能力；（4）智慧运维，整体方案中数据处理协议和关键业务数据算法模块支持升级替换，利于第三方接入和投资保护；（5）数据安全保护，支持安全加密，完善的数据备份和容灾备份方案。更加详细的功能需求，性能需求以及其他需求参见本项目的需求规格说明书。1.3 条件与限制本文档仅针对EMSV1.3系统的需求开发，本文档中的“本系统”一词通指EMSV1.3系统。开发时间要求为2015.03-2015.7，即在2015年7月31日前完成规定任务的设计、研发和测试第一轮工作。2 总体设计2.1 总体结构2.2 部署方案2.3 数据模型2.3.1 统计对象模型2.3.2 数据源模型2.3.3 算法模型2.3.4 第三方接口模型2.4 模块功能2.4.1 系统配置相关（林）2.4.1.1 平台通用配置2.4.1.2 能耗监测子系统业务配置2.4.1.3 配电子系统业务配置2.4.1.4 用能计费子系统业务配置2.4.1.5 智能照明子系统业务配置2.4.2 系统权限2.4.2.1 菜单权限2.4.2.2 能耗监测子系统业务数据权限2.4.2.3 配电子系统业务数据权限2.4.2.4 智能照明子系统业务数据权限2.4.2.5 能耗监测子系统业务数据权限2.4.3 系统日志2.4.3.1 需求目标日志记录组件负责系统运行期间，记录系统运行和用户操作业务以及系统运行的异常日志。考虑到日志组件的复用性，项目中大数据量操作和业务操作的复杂性，要求日志组件具有以下特点： 1.         业务日志记录、输出和查询; 2.         所输出的日志应该从业务、运行和异常三个大维度进行分类。其中业务日志分类需要细化到模块级，异常日志需要分为错误（程序运行错误）和告警（因为配置的问题产生），以支持更加灵活的日志分类检索； 3. 模板个性化：业务日志的输出内容格式需要根据业务功能的关注点进行模板化的定制； 4.         支持多线程：业务日志组件会在多线程环境中使用，需要确保线程安全性; 5.         稳定性：业务日志组件必须保持高度的稳定性，不能因为组件内部错误导致业务代码的崩溃； 6.         高性能：业务日志组件需要提供高速的日志记录功能以应对大请求流量下业务系统的正常运转； 7.         松耦合：业务日志组件需要在多个开发语言的业务系统中调用，故需要设计以SOA的方式进行调用；涉及的需求用例图如下：（图3.4.3.1-1）2.4.3.2 设计思路1.         方便检索的业务需求限制了日志输出介质必须为数据库或是某种支持快速检索的存储媒介。2.         为了满足稳定性和高性能的需求，可以采用异步消息来处理日志信息的输出，但会带来一系列编码实现的难度和复杂度。3.         日志记录切入点，为了减少业务编码过程中过度关注日志记录过程，采用AOP拦截器处理大部分的系统运行日志。4.         日志组件尽可能提供简单的接口，以方便业务方法中调用。同时为了避免业务方法记录日志时每次手工编码获取当前操作人，当前类名，方法名等信息，应设计某种机制自动获取类似信息。5.         考虑到日志检索和效率和日志的膨胀速度，有必要存在一个的日志清理机制。2.4.3.3 设计方案总体组件图如下：（图3.4.3.3-1）系统运行的日志一般信息量比较大，且系统正常运行态时一般无需关心，故采用文件的方式存储。在系统初次搭建时，提供存放的磁盘路径的配置，默认的磁盘路径是C:Logs应用程序名称。业务操作信息主要是记录的日常业务模块的操作记录，这类日志的特点是跟业务结合的较为紧密，需要进行统计和查询，故采用数据库的存储方式。系统运行的异常信息主要记录的是系统中每一个模块在实际项目运行中出现的错误和警告。这类日志的特点是需要集中式管理，并能进行故障快速定位查询，故采用数据库的存储方式。针对3种日志的特点，处理的解决方案如下：系统运行的日志处理系统设计一个日志处理的中间件（支持C+和C#2种语言接口），所有的应用在运行中产生的日志都调用日志中间件进行记录和保存。日志中间件根据不同日志应用的来源，将日志保存到不同的文件路径下。日志保存的规则如下：（1）日志信息统一采用文件方式保存，每个模块每天产生一个或多个日志信息（根据日志文件大小），日志文件的命名方式采用如下形式：模块名.日志创建日期（空格）日志创建时间，模块名采用字符串，长度不定。日志创建日期采用4位年份、2位月份和2位日期表示，年月日之间无隔断，日志创建时间采用2位小时，2位分钟和2位秒钟组成，时分秒之间无隔断，而日期与时间之间采用空格隔开，如“20150315 113000”。（2）日志内容采用如下形式日志时间级别(模块或文件名) 日志详细内容其中日志时间采用2位小时，2位分钟，2位秒钟以及3位毫秒组成，时分秒之间采用冒号:隔开，秒和毫秒之间采用点号.隔开。日志支持的级别至少包含以下四种ERROR：错误WARN：警告INFO：信息记录DEBUG：调试追踪日志中间件负责定时对历史的日志文件进行清理，清理的时间信息可以配置，默认清理的周期为7天。业务操作和系统异常的日志处理系统设计一个统一处理的日志处理接口（对C+和C#2种语言接口），所有的应用的业务日志都调用日志中间件进行记录和保存，最终按照针对2种分类保存到系统的数据库中。接口采用C#来实现，对C+采用webservice的方式供其调用，C#本身采用接口的方式调用。所有的业务日志和异常日志都在WEB界面进行查询。数据表中日志内容包含的信息如下：产生日志的子系统名称、产生日志的模块名称、日志的类型、日志的等级、日志发生的时间、日志的详细内容、日志的操作者。日志中间件负责定时对历史的日志的记录进行清理，清理的时间信息可以配置，默认清理的周期为60天。2.4.4 告警相关业务（陈安靖、郭健、王文杰）2.4.4.1 平台告警2.4.4.2 业务告警2.4.4.3 WEB告警展示2.4.5 能耗模型及算法处理2.4.5.1 负荷预测算法2.4.5.2 业务告警算法2.4.5.3 能效分析算法2.4.5.4 数据修复算法2.4.5.5 关联分析算法2.4.5.6 第三方对接系统算法（空调等）2.4.6 报表报告业务相关相关的模块总体文字说明2.4.6.1 报表设计器2.4.6.2 报表报告模板文件管理2.4.6.3 报表报告查询导出业务2.4.7 邮件短信推送服务2.4.8 平台层通用WebService2.4.8.1 内部系统WebService2.4.8.2 外部