能源管理系统EMS典型概要设计说明书

能源管理系统EMS3 概要设计说明书 目 录 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）项目经理、系统工程师、研发工程师等研发侧的相关人员，用于理解软件系统组成、模块接口、数据模型以及整体技术要求，为后续详细设计和系统开发提供基础和依据； （3）测试工程师和品质管理人员，用于理解软件系统边界、组成和模块关系，确定测试方案和测试计划，进行软件质量管理。 1.2 项目背景 拟开发系统名称：本文档规范的软件系统是南京能源管理系统V1.3，本项目简称EMSV1.3系统 项目提出者：南京 项目开发者：南京研发中心 本项目重点提供实现能耗监测、配电、智能照明、计费系统为一体的能源管理系统平台。同时对现有的1.2系统，进行整体业务框架和系统运行配置上深度优化。 1.3 定义 名词/缩略语 英文 中文含义 1.4 参考资料 1、本项目的经核准的计划任务书或合同、上级机关的批文； （1）《EMSV1.30-开发任务书》 （2）《EMSV1.3能源管理软件 V1.3 需求规格说明书》 2、属于本项目的其他已发表的文件 暂无。 3、其他参考的文件、资料和标准 无 2 任务概述 2.1 目标 公司基于“平台战略”提出了能源管理系统软件平台，目标是建立一个高度开放的，可扩展的，集配电、能耗监测、用能计费、智能照明为一体的综合性系统，即能源管理系统平台。在整体战略的驱动下，EMSV1.3系统研发的目标定位是将现有的能耗监测、配电、智能照明、用能计费各个子系统合为一体，可分可合，同时将现有的1.X的底层架构设计的更合理和稳定以及对现有系统的配置进行优化。 2.2 运行环境 本小节规定本项目开发和目标平台，以及测试部署使用的软硬件运行环境。本项目部分软硬件产品具备平台移植能力，通过微调和重新编译可适应新的软硬件平台。 序号 子系统 设备 要求 1 前置通讯 硬件 低功耗工控机，ARM9处理器及以上，内存不低于64M，外存空间不低于512M，百兆网卡，485串口4-10口，具备硬件看门狗。软件支持重编译移植到PowerPC平台。 2 操作系统 嵌入式Linux 3 数据库 主流嵌入式数据库，如Sqlite 4 Web系统和9000平台 硬件 服务器2台（数据库服务器、应用程序服务器），内存不低于4G，外存空间不低于500G（不包括数据存储空间）,百兆/千兆网卡 5 操作系统 Windows Server2008 及以上版本 32位服务器版 6 数据库 关系数据库系统 SqlServer2008 及以上版本 2.3 需求概述 2.3.1 功能需求 本项目设计研发的EMSV1.3系统功能需求概述见图，其中可分为三个层次： 1、数据加工底层模块优化 考虑到EMSV1.2系统在现场项目高并发的极端场景下，数据入库会出现延迟和锁表的故障。本系统在此次的开发任务中将对现有的系统进行优化，新增消息总线的机制，保证系统在数据加工业务模块的稳定。 2、所有子系统的权限和配置整合 分析现有的能耗监测子系统、照明子系统、配电子系统、用能计费子系统。将现有的几个子系统全部以B/S的方式集成为一体，将其中的用户和权限进行统一的规划设计，完成权限的整合。 对现有各个子系统中的配置进行梳理，整理出通用必须的配置和各个模块的特定的业务配置。通过场景的方式对配置业务模块进行统一的规划和设计。 3、 基础业务功能的实现 完成EMSV1.3需求说明书中的功能需求。 图1 EMSV1.3功能需求模型 2.3.2 数据容量需求 系统数据容量计算： 数据采样周期：支持最小数据采集周期为5分钟，上层应用提供的时间周期可选10分钟、15分钟、20分钟、30分钟、1小时、天、月、年。 本系统的业务规模，最大设计支持的采集点数量为100,000，支持主备处理和分布式扩展，保留向更高容量扩展的能力。 2.3.3 性能及其他 本项目设计研发的EMSV1.3系统对应的关键性能及其他方面的需求如下： （1）安全可靠千兆接入网络，支持大规模并发数据流量接入; （2）对主要数据和功能进行安全隔离； （3）具备统一的运行监管功能，对主要模块的运行状态进行统一监管，要求具有良好的运行监测、负载监控管理、流量监控、故障分析和故障恢复能力； （4）智慧运维，整体方案中数据处理协议和关键业务数据算法模块支持升级替换，利于第三方接入和投资保护； （5）数据安全保护，支持安全加密，完善的数据备份和容灾备份方案。 更加详细的功能需求，性能需求以及其他需求参见本项目的需求规格说明书。 2.4 条件与限制 本文档仅针对EMSV1.3系统的需求开发，本文档中的“本系统”一词通指EMSV1.3系统。 开发时间要求为2015.03-2015.7，即在2015年7月31日前完成规定任务的设计、研发和测试第一轮工作。 3 总体设计 3.1 总体结构 3.2 部署方案 3.3 数据模型 3.3.1 统计对象模型 3.3.2 数据源模型 3.3.3 算法模型 3.3.4 第三方接口模型 3.4 模块功能 3.4.1 系统配置相关（林） 3.4.1.1 平台通用配置 3.4.1.2 能耗监测子系统业务配置 3.4.1.3 配电子系统业务配置 3.4.1.4 用能计费子系统业务配置 3.4.1.5 智能照明子系统业务配置 3.4.2 系统权限 3.4.2.1 菜单权限 3.4.2.2 能耗监测子系统业务数据权限 3.4.2.3 配电子系统业务数据权限 3.4.2.4 智能照明子系统业务数据权限 3.4.2.5 能耗监测子系统业务数据权限 3.4.3 系统日志 3.4.3.1 需求目标 日志记录组件负责系统运行期间，记录系统运行和用户操作业务以及系统运行的异常日志。考虑到日志组件的复用性，项目中大数据量操作和业务操作的复杂性，要求日志组件具有以下特点： 1.         业务日志记录、输出和查询; 2.         所输出的日志应该从业务、运行和异常三个大维度进行分类。其中业务日志分类需要细化到模块级，异常日志需要分为错误（程序运行错误）和告警（因为配置的问题产生），以支持更加灵活的日志分类检索； 3. 模板个性化：业务日志的输出内容格式需要根据业务功能的关注点进行模板化的定制； 4.         支持多线程：业务日志组件会在多线程环境中使用，需要确保线程安全性; 5.         稳定性：业务日志组件必须保持高度的稳定性，不能因为组件内部错误导致业务代码的崩溃； 6.         高性能：业务日志组件需要提供高速的日志记录功能以应对大请求流量下业务系统的正常运转； 7.         松耦合：业务日志组件需要在多个开发语言的业务系统中调用，故需要设计以SOA的方式进行调用； 涉及的需求用例图如下： （图3.4.3.1-1） 3.4.3.2 设计思路 1.         方便检索的业务需求限制了日志输出介质必须为数据库或是某种支持快速检索的存储媒介。 2.         为了满足稳定性和高性能的需求，可以采用异步消息来处理日志信息的输出，但会带来一系列编码实现的难度和复杂度。 3.         日志记录切入点，为了减少业务编码过程中过度关注日志记录过程，采用AOP拦截器处理大部分的系统运行日志。 4.         日志组件尽可能提供简单的接口，以方便业务方法中调用。同时为了避免业务方法记录日志时每次手工编码获取当前操作人，当前类名，方法名等信息，应设计某种机制自动获取类似信息。 5.         考虑到日志检索和效率和日志的膨胀速度，有必要存在一个的日志清理机制。 3.4.3.3 设计方案 总体组件图如下： （图3.4.3.3-1） 系统运行的日志一般信息量比较大，且系统正常运行态时一般无需关心，故采用文件的方式存储。在系统初次搭建时，提供存放的磁盘路径的配置，默认的磁盘路径是C:\NTSLogs\应用程序名称\。 业务操作信息主要是记录的日常业务模块的操作记录，这类日志的特点是跟业务结合的较为紧密，需要进行统计和查询，故采用数据库的存储方式。 系统运行的异常信息主要记录的是系统中每一个模块在实际项目运行中出现的错误和警告。这类日志的特点是需要集中式管理，并能进行故障快速定位查询，故采用数据库的存储方式。 针对3种日志的特点，处理的解决方案如下： 系统运行的日志处理 系统设计一个日志处理的中间件（