建筑节能监测子系统软件架构设计书文档格式.docx
《建筑节能监测子系统软件架构设计书文档格式.docx》由会员分享，可在线阅读，更多相关《建筑节能监测子系统软件架构设计书文档格式.docx（27页珍藏版）》请在冰豆网上搜索。
3.2服务端模块20
3.3客户端功能模块39
3.4子系统/单元分解39
3.5组件/模块分解40
3.6进程分解40
3.7数据分解40
4功能实现原理40
5依赖性描述41
5.1组件/模块间依赖描述41
5.2进程间依赖描述41
5.3数据依赖41
6接口描述41
6.1组件/模块间接口41
6.2进程间接口41
7系统集成41
7.1系统集成顺序41
7.2软硬件环境42
8其他44
附录A词汇表45
附录B参考文献45
附录C架构模型45
1引言
当前，公共建筑节能监测信息管理系统开始兴起。
作为这类系统的数据采集功能实现的建筑物节能监测子系统（以下简称“本系统”）,其重要性愈发突出。
通过本系统，实现对数据采集单元的数据进行采集，并进行汇总、展示等。
1.1目的
本文从子系统/单元、组件/模块、接口、进程和数据等角度对系统进行分解，构建了建筑能耗在线监测系统的设计架构。
本文以软件需求规格书为基础，提出建筑能耗在线监测系统的高层设计，本文也是开展单元设计和集成测试的依据。
1.2预期的读者和阅读建议
本项目组的全体人员均需阅读本文，本文预期的读者还包括以建筑能耗在线监测系统构建的系统为基础或者与该系统相关的任何其它研发项目的系统分析员及开发人员。
建议开发人员以系统分解描述和依赖性描述为阅读重点，集成测试人员则以接口描述和系统集成为阅读重点。
其它项目组的人员应以本架构描述的对外交互接口作为阅读重点。
1.3文档范围
本文适合于建筑能耗在线监测系统，后续工作（包括：
子系统设计、单元设计、集成测试等）应遵循本文描述的架构，并在必要时维护更新本文的内容。
本文也是日后产品升级的重要参考。
以建筑能耗在线监测系统为基础的或者与该系统相关的任何研发项目将受到本文描述架构的影响。
2设计策略
本系统是新设计的系统。
在设计中参考了大量的数据采集系统以及SCADA系统，充分考虑功能需求、项目规模以及与客户端的通信技术的变化等因素进行功能设计，而研发的重点则放在应用功能的展示、人机交互方面。
同时设计出一套较好服务与应用界面的总体框架平台，以有利于后续规约和功能扩展，并尽快推向市场。
本系统设计中参照了国家住房和城乡建设部颁发的《软件开发指导说明书》，符合《能耗检测技术导则》的系统设计要求。
2.1网络架构
2.1.1功能要求
Ø
实现与公共建筑节能监测信息管理系统市级数据中心的网络互联。
接入GPRS公网通信信道。
接入本地串口信信道。
2.1.2网络规划拓扑图
2.1.3网络详细架构设计
系统整个网络根据网络功能细化为主网段网络、终端通信网、信息发布网。
2.1.3.1主网段网络设计
主网段部分运行1~2台服务器，并向上与市级数据中心连接。
数据流量不大，但数据实时交换要求较高，所以采用百兆以太网。
主网络通过前置服务和通信网络进行通信。
主网络无法直接对通信网络进行通信，保证通信网和其它网络间隔离。
与公司其它系统不与此系统进行连接。
主网络向上通过VPN或其他通信方式与市级数据中心相连；
2.1.3.2通信网网络设计
此网络是面向客户现场终端的通信，实现数据采集和控制，管理系统通信资源，接入各类客户侧终端设备，主要由串口信道、GPRS公网信道等组成。
其中串口信道在设备较多时，通过通道切换箱接入终端服务器然后接入主站通讯服务器。
GPRS信道通过路由器进行网络地址段和通信网地址段的路由进行通信。
在路由器上设置终端（外部地址）只能访问通信网内部的网络地址。
系统针对公网前置机可使用均衡器，用以平衡网络流量。
鉴于无线公网终端通道的特点，通信网络通过防火墙隔离前置机和终端间的通信。
防火墙上严格设置了终端可访问安全区内前置机的IP地址和访问端口。
通过设置，无线公网终端只能访问特定IP地址机器的特定端口，从而保证了通信网与无线公网通信的安全性，规避无线公网终端通信可能带来的危害。
基于此网络的架构，终端信道的接入只和前置服务器有关联，只要修改前置服务的通信适配层就可以完成新终端信道的接入，不会对已经接入的信道产生任何影响。
2.1.3.3信息发布网络设计
系统应用在发布时采用防火墙进行隔离，使发布服务器处于安全区，对外发布时采用NAT技术。
NAT技术可以把内部网络地址通过网络设备转换为外部网络可路由地址的网络技术。
NAT技术不仅可以隐藏内部网络拓扑、节省合法IP地址,而且对客户机是透明的,无需客户机作特殊的设置。
各个地市电力公司操作人员通过本单位信息办公网访问服务器，进行业务操作。
系统针对发布服务器使用均衡器，用以平衡网络流量。
负载均衡器主要完成以下任务：
解决网络拥塞问题，服务就近提供，实现地理位置无关性；
为用户提供更好的访问质量；
提高服务器响应速度；
提高服务器及其他资源的利用效率；
避免了网络关键部位出现单点失效，而且网络负载均衡对外只需提供一个IP地址。
当网络负载均衡中的一台或几台服务器不可用时，服务不会中断。
网络负载均衡自动检测到服务器不可用时，能够迅速在剩余的服务器中重新指派客户机通讯。
这项保护措施能够帮助你为关键的业务程序提供不中断的服务，并可以根据网络访问量的增加来相应地增加网络负载均衡服务器的数量。
2.2技术架构
本系统的技术架构采用本公司的专有技术与流行的通用组件技术相结合的方式进行设计的。
一方面，从系统特性上看其属于自动化系统，并具有较高的实时性要求，它需要集成公司现有高水平的电力自动化平台成果，如：
实时数据库、进程监控等，这些技术都将在本系统的服务平台中得到应用。
另一方面，本系统是重要的公共建筑节能信息监测管理系统的组成部分，因此需要一套能够快速适应能耗监测的人机交互架构来满足这种需求。
所以本系统的应用框架采用了现在较为流行的.Net架构作为人机交互的基础架构，所有的操作人员只需要使用办公计算机自带的IE浏览器就可以完成相关的业务操作。
如果营销业务发生变化，只需要在服务端更新业务逻辑即可完成对整个系统的业务更新。
同时为了更好满足系统显示性能和开发效率本系统在展示平台上还使用了Ajax架构作为系统开发的基础架构。
2.2.1服务平台架构
建筑能耗在线监测系统不但是一个复杂的能耗信息采集的业务系统也是一个实时的数据采集的自动化系统，它需要集成现在高水平的电力自动化平台成果，主要的技术成果有实时数据库、进程监控。
先进的电力自动化平台是本系统的服务平台的主要技术架构基础。
自动化平台主要技术架构的框架图如下所示：
2.2.1.1实时数据库
实时数据库专门用来提供高效的实时数据存取，实现工况监视、负荷管理和电网分析，其高效性主要通过下列机制来实现：
1、数据库服务进程采用多进程和多线程机制，当有多个数据库服务请求同时发出时，数据库服务进程会产生新的进程或线程来响应这些请求，以提高系统的并发性，达到快速响应的目的。
2、设计了一套分布式的数据库管理系统，来优化管理全网分布式数据库，当用户访问数据时，由分布式数据库管理系统来自动判断数据在本机还是在异机，如果在本机则采用快速的内存访问方法，如果在异机则通过网络通信的方法去访问。
实时数据库管理具有下列特性：
1、实时性：
具有良好的实时响应性能，访问时间为毫秒级。
2、数据的多样性：
能够建立多种数据集，用于不同的运行模式等。
3、有效性：
通过限值判断和合法性校验等，具有检查数据有效性的能力，任何无效的数据都不接受。
2.2.1.2图形应用平台
图形应用平台主要包括自定义图形平台应用。
自定义图形的图形平台，是实现基本线路图的绘制的平台。
此平台主要用于对主站设备监控、主站服务模块监控等功能应用提供图形方面的公共服务，主要包括图形绘制以及图形展示两大部分，在本系统中的图形展示将采用B/S方式。
该平台具有如下特点：
1、充分考虑了各类操作系统之间的差异，并对这种差异进行了透明的处理和包装，使上层应用不必修改代码就可以移植到不同的操作系统之上，并且使得上层应用可以在不同的设备和操作系统之上实现互连、互通、互操作。
2、为上层应用提供了一个统一的、可扩展的、分布的开发平台，使得仅仅单一系统的可编程转变为多种系统的可编程，对上层应用而言，开发者只需要将更多的精力放到业务流程和业务规则上，开发应用仅仅依托于分布式系统运行平台所提供的一系列的编程接口和服务。
3、根据本系统的特点，对开发上层应用所需的关键任务集中进行包装处理，形成了一系列软件包，为上层应用提供实用的、统一的、完善的编程接口和服务。
在系统将来扩展或与其它系统进行集成时，不影响操作系统已有的分布式操作平台，通过提供完善的接口和服务，完成系统的扩展或与其它系统平台间的无缝集成。
2.2.1.3进程监控
本系统的进程管理模块能够管理与其同在一台机器上运行的服务和系统服务程序进程，并能够显示所有的应用进程的运行情况。
该管理系统应具有如下功能：
1、进程监控
当在某设定时间内检测出被监视应用的异常状态，并采取相应的措施：
如杀死进程、重启程序等，并以报警的形式提示用户。
及时汇报各进程的运行状态，检测重要进程的非正常退出，如网络通信中断，扫描进程出错等，并用报警的形式提示用户及自动重启。
实现进程之间的控制和通信。
2、应用进程的启动和退出
进程管理模块启动时缺省以预先配置的启动序列启动各被监视的应用进程，也可以通过命令行参数选择进程管理模块启动时不启动被监视的应用进程。
进程管理模块可以通过管理界面进行退出，模块退出时缺省不退出管理的应用进程，也可以通过参数配置一起退出各应用进程。
用户可以通过进程管理模块的管理界面启动和停止特定的监视应用或所有监视应用进程。
对于正常退出的监视应用进程，进程管理模块应当不再重启它。
3、进程管理
配置各应用进程的启动序列，以及应用启动时的命令行及相应的启动参数。
配置各应用进程异常退出或被强制杀死后的重启时间间隔。
4、能够监控的进程包括以下几部分：
主站运行应用服务模块的监控：
前置服务
实时库服务
数据处理服务
事项服务
2.2.2展示平台架构
本系统是一个多层次应用的分布式系统，数据类型复杂、各类数据的数据密度小，数据量巨大，相关系统的信息交互频繁，因此，在系统的性能、互联方便性、移植性等方面有特殊的要求，需要有良好的技术体系结构来实现。
基于以上考虑本系统展示平台采用.Net架构进行设计，所有的用户体验界面采用纯B/S架构进行设计，即所有与操作客户需要交互的应用功能界面都使用浏览器作为UI界面。
同时考虑到本系统的业务功能复杂、涉及到开发人员较多因此整个开发架构采用MVC架构，将模型、控制、界面分开，由不同开发人员开发不同的框架。
为了提高整个系统的交互性能，将部分功能界面的提交方式采用局部提交的方式进行设计，从某种程度上减少了传统的Web界面需要整体提交而造成的性能压力和操作不便。
对于局部递交本系统采用现在较为流行的Ajax技术的进行开发。
下面对展示平台的所采用的架构进行简单介绍
2.2.2.1.Net架构
.NET框架设计为一个集成环境，可以在Internet、桌面（如Windows窗体），甚至移动设备（使用精简框架CompactFramework）上无缝地开发和运行应用。
其主要目标是:
提供一个覆盖整个应用范围的、一致的面向对象环境;
提供一个环境，将困扰Windows（COM）程序员的版本冲突（“DLLHell”，即DLL地狱）问题最小化，简化代码的发布/安装过程;
基于公认的标准，提供一个可以在任意操作系统上运行的可移植环境。
实际上，C#和.NET运行时的一个主要部分，即通用语言基础设施（CommonLanguageInfrastructure，CLI），已经得到了ECMA的标准化。
ECMA国际（ECMAInternational）全名是欧洲计算机制造协会（EuropeanComputerManufacturersAssociation），简写作ECMA。
提供一个可管理的环境，在这个环境中，可以很容易地验证代码，以保证程序安全运行。
为了实现上述目标，.NET框架设计者们最后确定了以下体系结构，将框架分解为两部分:
通用语言运行时CLR和框架类库FCL，其结构如下图所示。
CLR是Microsoft对CLI标准的具体实现，它处理代码执行及所有相关任务:
编译、内存管理、安全、线程管理、强制类型安全和类型使用。
在CLR中运行的代码称为托管代码（ManagedCode），以区别于不在CLR中运行的非托管代码（unmanagedcode），如基于COM或WindowsAPI的组件。
.NET的另一个主要部分是框架类库FCL，对于在.NET中运行的应用来说，它是一个可重用的类型（类、结构等）代码库。
正如图中所示，它包含了涉及数据库访问、图形、与非托管代码互操作、安全、Web和Windows窗体等类。
只要是遵循.NET框架的语言，都会使用这个公共类库。
因此，只要知道了如何使用这些类型，不论你选择用哪一种.NET语言编写程序，这些知识都可以用上。
Microsoft.NET和CLI标准
如果开发人员下决心花时间来学习C#和.NET，很自然地会想到，能否将获得的知识应用于其他平台上。
更明确地说，Microsoft的.NET产品是否仅限于Windows操作系统?
或者，它是不是一个可移植的运行时和开发平台，可以在多个操作系统上实现?
要回答这个问题，有必要先了解Microsoft.NET、C#和CLI标准之间的关系。
CLI定义了一个与平台无关的虚拟代码执行环境。
由于未指定任何操作系统，所以操作系统可以是Windows，更可以是Linux。
该标准的核心是定义了一个通用中间语言（CommonIntermediateLanguage，CIL）和一个类型系统，遵循CLI的编译器必须生成CIL，而类型系统则定义了遵循CLI的所有语言都支持的数据类型。
下一节将会讲到，这种中间代码将编译为其主机操作系统的本地语言。
CLI还包含了由Microsoft开发并大力推行的C#语言的标准，因此，C#是.NET事实上的标准语言。
图1ˉ2CLI规范定义的架构但后来，其他厂商也很快采纳了CLI标准，并开发了诸多语言，如Python、Pascal、Fortran、Cobol和Eiffel.NET编译器。
图1ˉ1所示的.NET框架是Microsoft对CLI标准的实现。
需要注意的最重要的一点是，这个实现中包含的大量特性并不是CLI架构所要求的。
为了说明这一点，图1ˉ2给出了CLI标准架构，你可以与图1ˉ1做一个比较。
概括起来，CLI定义了两个实现:
一个是最小实现，称为内核概要（KernelProfile），另一个提供了更多特性，称为精简概要（CompactProfile）。
内核概要包含遵循CLI的编译器所需要的类型和类，其中基类库包括基本的数据类型类，还包括提供简单文件访问、定义安全属性以及实现一维数组的其他类。
精简概要添加了3个类库:
定义简单XML解析的XML库、提供HTTP支持和端口访问的网络库，以及支持反射（程序通过元代码实现自检的一种方法）的反射库。
本书介绍的是Microsoft的CLI实现，但如果只介绍CLI规范中定义的内容，那么本书的篇幅可能就小多了。
倘若如此，我们就不会特别加入章节来介绍ADO.NET（数据库类）、ASP.NET（Web类）或Windows窗体等内容，而有关XML的各章也将大幅削减。
你应该会想到，这些库的功能依赖于底层WindowsAPI。
另外，.NET允许程序使用一种互操作（Interop）特性来调用Win32API，也就是说，.NET开发人员不仅能访问Win32API，还能访问遗留应用和组件（COM）。
由于如此倚重于Windows，Microsoft的.NET实现更称得上是一个透明环境，而不只是一个虚拟环境，这并没有什么不好。
对于转向.NET的开发人员来说，利用Microsoft的.NET实现，能够充分结合.NET组件和原来已有的代码来创建混合应用。
也就是说，无需将.NET实现代码移植到其他操作系统。
CLI开源组织正在着力采纳Microsoft增加的这些特性，对开发人员（以及本书读者）来说，这自然是一个好消息。
作为CLI主要项目之一的Mono，就已经包含了
诸如ADO.NET、Windows窗体、全部XML类，以及大量集合（Collection）类等主要特性。
这确实非常重要，因为这意味着，如果你在使用Microsoft.NET的过程中积累了一些知识和技能，那么这些知识对于Linux、BSD、Solaris平台上的.NET实现也同样适用。
2.2.2.2MVC架构
MVC模式是"
Model-View-Controller"
的缩写，中文翻译为"
模型-视图-控制器"
。
MVC应用程序总是由这三个部分组成。
Event（事件）导致Controller改变Model或View，或者同时改变两者。
只要Controller改变了Model的数据或者属性，所有依赖的View都会自动更新。
类似的，只要Controller改变了View，View会从潜在的Model中获取数据来刷新自己。
模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。
如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。
因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。
这实际上是一种模型的变化-传播机制。
模型、视图、控制器三者之间的关系和各自的主要功能，如下图所示。
它适于开发复杂的Web应用系统，具有代码重用度高，代码移植性良好和代码可插拔等优点。
本系统主站是一个复杂的系统，同时，业务变化较快，需要不断的扩充和维护，因此适于采用MVC结构。
基于上面的描述本系统采用了基于MVC思想开发出的开源的MVC框架进行开发。
2.2.2.3Ajax架构
Ajax（AsynchronousJavaScriptandXML）是一组技术的组合，其核心是JavaScript对象XmlHttpRequest。
该对象在InternetExplorer5中首次引入，它是一种支持异步请求的技术。
简而言之，XmlHttpRequest使您可以使用JavaScript向服务器提出请求并处理响应，而不阻塞用户。
AJAX技术使浏览器可以为用户提供更为自然的浏览体验。
在Ajax之前，Web站点强制用户进入提交/等待/重新显示范例，用户的动作总是与服务器的“思考时间”同步。
Ajax提供与服务器异步通信的能力，从而使用户从请求/响应的循环中解脱出来。
借助于Ajax，可以在用户单击按钮时，使用JavaScript和DHTML立即更新UI，并向服务器发出异步请求，以执行更新或查询数据库。
当请求返回时，就可以使用JavaScript和CSS来相应地更新UI，而不是刷新整个页面。
最重要的是，用户甚至不知道浏览器正在与服务器通信：
Web站点看起来是即时响应的。
2.3数据架构
2.3.1设计依据与假设
●《关于加强国家机关办公建筑和大型公共建筑节能管理的实施意见》（建设部、财政部：
建科[2007]245号）
●《国家机关办公建筑和大型公共建筑能耗监测系统建设实施方案》
●《国家电子政务工程建设项目管理暂行办法》（中华人民共和国国家发展和改革委员会令第55号）
●住房与城乡建设部2008年6月发布的《国家机关办公建筑和大型公共建筑能耗监测系统分项能耗数据采集技术导则》
●住房与城乡建设部2008年6月发布的《国家机关办公建筑和大型公共建筑能耗监测系统分项能耗数据传输技术导则》
●住房与城乡建设部2008年6月发布的《国家机关办公建筑和大型公共建筑能耗监测系统建设、验收与运行管理规范》
●住房与城乡建设部2008年6月发布的《国家机关办公建筑和大型公共建筑能耗监测系统数据中心建设与维护技术导则》
●住房与城乡建设部2008年6月发布的《国家机关办公建筑和大型公共建筑能耗监测系统楼宇分项计量设计安装技术导则》
●DL/T645—1997多功能电表通信规约
●CJ/T188—2004户用计量仪表数据传输技术条件
●GB/T
19582-2008基于Modbus协议的工业自动化网络规范
●GB9254-1998信息技术设备的无线电骚扰限值和测量方法
●GB/T17168-1998信息技术设备抗扰度限值和测量方法
●GB/T17626-1998电磁兼容
试验和测量技术
●GB9361－88计算站场地安全要求
●BMZZ1-2000涉及国家秘密的计算机信息系统保密技术要求
●GB50173－93电子计算机机房设计规范
●GB2887－89计算站场地技术条件有关标准。
采集数据项如下：
序号
数据采集单元
项目
备注
1
单相电表
电能量数据
一般每个采集点安装1块表.
每天96点正向有功电能示值曲线以及日冻结电能示值总。
2
多功能电表
一般每栋楼安装1块表。
3
水表
天然气表
冷气表
暖气表等
表码值
一般每栋楼或每层安装1块表；
仅表码值。
2.3.2存储记录数计算
根据上面的数据假设一天产生的数据记录按一个量测一条记录，则记录数计算如下：
每幢建筑有20个数据采集点，每15分钟采集1次，每个点上送1次的数据量约为200个字节（Byte），那么每套系统的1天的最大能耗数据量约为（20*96*200）字节。
每个地区数据中心1年的上传数据量约为（20*96*200*30*365）字节。
本系统数据需在线存储15年，则总数据存储量约为（20*96*200*30*365*15）字节，约合58.74GB数据。
一年数据（一个月30天）：
1920*30（天）*12（月）=691,200条
较大的建筑要应该比中型建筑大4到5倍。
2.3.3数据存储设计
本系统数据主要由前置通信服务模块负责采集，为了使前置通信模块可灵活部署及组合，前置通信服务模块不直接存盘，而是把采集到的数据通过网络发送到数据处理模块，由数据处理模块负责数据的统一存储及后续处理。
考虑到系统的数据采集具有集中、量大的特点，要求数据处理具有快速的响应、处理机制。
2.3.3.1数据表空间设计
由于本系统的数据库存储的数据规模相对较大，因此，将历史数据采用年表的方式设计。
从而保证整个数据库的响应速度。
2.3.3.2数据表设计
对于历史
升级会员 