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

综合能源平台EMSV1.3概要设计说明书 目 录 1 引言 7 1.1 编写目的 7 1.2 项目背景 7 1.3 定义 8 1.4 参考资料 8 2 任务概述 8 2.1 目标 8 2.2 运行环境 8 2.3 需求概述 9 2.3.1 功能需求 9 2.3.2 数据容量需求 10 2.3.3 性能及其他 10 2.4 条件与限制 11 3 总体设计 11 3.1 总体结构 11 3.2 部署方案 11 3.3 数据模型 11 3.3.1 统计对象模型 11 3.3.2 数据源模型 12 3.3.3 算法模型 12 3.3.4 第三方接口模型 12 3.4 模块功能 12 3.4.1 系统配置相关（林） 12 3.4.2 系统权限 13 3.4.3 系统日志 13 3.4.4 告警相关业务（陈安靖、郭健、王文杰） 13 3.4.5 能耗模型及算法处理 14 3.4.6 报表报告业务相关 14 3.4.7 邮件短信推送服务 15 3.4.8 平台层通用WebService 15 3.4.9 Redis通用消息总线 15 3.4.10 数据加工服务 16 3.4.11 配电智能照明FLEX 16 3.4.12 移动APP 16 3.4.13 进程守护和监控（看门狗） 16 3.4.14 WEB业务模块 16 4 接口设计 17 4.1 外部接口 17 4.2 内部接口 17 5 数据结构设计 17 5.1 公共常量定义 17 5.1.1 模块命名前缀定义 17 5.2 独立数据库设计 17 5.2.1 物理结构设计 18 5.2.2 逻辑结构设计 18 6 运行设计 19 6.1 运行模块的组合 20 16 20 6.2 运行控制 21 6.3 运行时间 21 7 错误处理设计 21 7.1 系统级故障与错误 21 7.1.1 采集数据缺失或异常 21 7.1.2 网关通信中断 22 7.1.3 网关软硬件异常 22 7.1.4 服务器软硬件故障 22 7.1.5 数据访问和存储能力 23 7.2 容错处理对策 23 7.2.1 通信心跳与链路保持 23 7.2.2 看门狗服务 23 7.2.3 数据缓存与重传修复 24 8 安全保密设计 24 8.1 网关通信 24 8.2 开放服务接口 24 9 维护设计 24 9.1 日志系统 24 9.2 数据库备份 25 9.3 软件产品安装和自动升级 25 9.4 运行监测与报警 25 1 引言 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 平台层通用WebService 2.4.8.1 内部系统WebService 2.4.8.2 外部