基于物联网的网格化大城管平台供热节能平台软件技术方案Word格式.docx
《基于物联网的网格化大城管平台供热节能平台软件技术方案Word格式.docx》由会员分享，可在线阅读，更多相关《基于物联网的网格化大城管平台供热节能平台软件技术方案Word格式.docx（27页珍藏版）》请在冰点文库上搜索。
2.1.1建设区概况
目前,昌平区供热系统存在分散独立的监管对象、缺少统一监管平台的问题，昌平区市政市容管理委员会监控中心、昌平区供热管理服务中心、昌平区永安热力大屏展示中心这三个部门之间相互独立，没有任何的信息关联和相互直接配置另外一方工作的平台机构。
系统内部组织结构关系如下图所示：
2.1.2管网工艺简介
2.1.2.1供热产锅炉监控
包括南环4台锅炉，北环4台锅炉，昌盛园4台锅炉，水库路4台锅炉，胡庄2台锅炉，昌科东区3台锅炉。
2.1.2.2换热站监控
包括南环59个换热站，北环51个换热站，昌盛园39个换热站，水库路28个换热站，胡庄6个换热站，昌科西区3个换热站，昌科东区5个换热站，郝庄5个换热站。
2.1.2.3管网工艺
总管网工艺
、
北环管网工艺
南环管网工艺
水库路管网工艺
昌盛园管网工艺
2.1.3现有系统存在的问题
2.1.3.1分散独立的监管对象、缺少统一监管平台
昌平区市政市容管理委员会监控中心
昌平区供热管理服务中心
昌平区永安热力大屏展示中心
调研现状三个部门上述三个部门之间相互独立，没有任何的信息关联和相互直接配置另外一方工作的平台机构。
2.1.3.2分散的数据源，没有一个统一的监控服务平台
永安热力监控中心数据源（企业的数据上传）不完整；
目前监控总的数据点数1.5万点数据，8个热源厂（燃煤锅炉）
供热计量收费监管平台的数据比较分散（11家抄表厂家），无统一的管理分析模式；
人工手工统计的数据无法正常录入系统；
2.1.3.3供热系统与物联网大平台无关联
昌平区物联网的网络大平台系统需要融合统计相关的供热的整体监管数据。
2.2基本监控功能需求
系统的基本需求主要包括数据的采集与存储以及数据的展示与分析，使系统平台能够满足日常的工艺流程监控、数据实时采集、数据海量存储、超限数值报警等客户的基本需要。
全面地监控生产概况
显示热网、热源、热表、热计量等所需数据，数据实时、准确，工艺流程展示形象满足视觉需求，工艺画面主要包括换热站、锅炉等生产单位，各层逻辑关系清晰，画面跳转方便。
快速地采集实时数据
实时采集下层8个锅炉房，远程抄表系统以及新增的热量表的数据，保证系统与系统间，系统与设备间数据的同步性与准确性。
准确地存储历史数据
实现所有历史数据的海量存储，数据库保证一定的数据检索速率，且可存储几年甚至长达十年的供热历史数据。
直观地展示数据信息
各数据均可显示实时趋势曲线，并可通过查询条件查询到任意数据，任意历史时段的趋势曲线，历史趋势曲线可进行曲线的放缩。
并有曲线、棒状图、饼状图等多种形式，以实现数据间的对比展示。
灵活地通知报警信息
能够对所有工艺运行参数设置高低限值报警，当运行参数超限时可通过报警栏，报警数值跳变，报警短信或语音发送等多种形式完成数据报警。
便捷地发布Web网页
具有Web发布功能，可用网页形式对当前各运行画面、展示画面、分析画面进行浏览。
并具备一定的安全性设置。
2.3上层分析功能需求
热量累计统计
可根据历史数据自动生成日表、月表、年表，并汇总报表数据进行统计。
能耗分析功能
能够对数据的统计分析、计算分析、对比分析，得出供热系统各工艺环节的能耗比例，得出不同换热站的热负荷、热效率等，能够清晰的获知成本消耗的详细情况，并提供各种数据的对比分析图，为管理决策提供重要依据。
具体功能需求主要包括热力站能耗分析需求，热源、热力站同期热耗对比分析需求，热源、热力站流量分析需求、管网热量损耗分析需求，热网温度分布分析需求、热源成本分析需求等。
并将各种需求结果使用棒状图，饼状图曲线对比的形式展示出来。
热负荷预测功能
根据天气预报和历史气象绘制出日热负荷曲线图。
全网平衡分析
开发相应控制算法或控件，在数据支持下完成全网平衡功能，以实现调控现场阀门等设备的目的。
气象管理
分析相关数据，完成天气预报和历史气象信息的记录。
2.4数据交互功能需求
原关系库数据转存
能够将现有各子系统关系库中的数据实时，准确得转存入工业库中，并能及时清除过期数据，保证数据能够持久、顺利的进行转存。
转发物联网大数据库
能够将该平台系统中的历史、实时数据通过特定转发工具接入进大城管平台中，并保证查询的准确性与快速性。
Webservice接口
可在大城管网页平台中灵活调用该平台系统中的监控画面。
3系统功能设计
3.1系统基本功能
3.1.1数据采集
将现在的金房系统与正在进行整合工作的硕人系统中存于SQLServer关系
库中的数据，通过特定的转发工具，定时、批量地转入KH工业库中，经过分析计算后通过曲线、棒图的形式进行集中展示。
针对暂未归入系统的数字仪表、PLC、RTU等采集设备，使用IOServer采集工具进行实时、准确地数据采集，并同样将数据信息存入工业库中，再以组态画面和组态图表的形式表现出来。
3.1.1.1供热单位数据采集
通过对供热厂供热各流程中的瞬间热量、累计热量、瞬间流量、累积流量流量进行实时采集。
用于进行各供热厂内、厂间进行热量统计与对比。
对供热厂的锅炉设备，进行供水压力、供水温度、回水压力、回水温度、流量、炉排功率、炉膛温度等重要参数进行实时采集与展示。
并可以对数值上下限进行设置报警，以实现安全生产。
3.1.1.2换热站单位数据采集
通过对各换热站一次供水、回水，二次供水、回水的压力、温度，一次瞬、一次累，二次瞬、二次累流量、热量进行集中采集、展示、分析，实现生产运行状况的统计、对比与预测。
3.1.1.3用户热量表数据采集
以各耗热用户为单位，通过对各供热末端热表数据的采集，数值的统计，结合供热厂、换热站相关数据汇总。
可实现管网损耗分析、负荷预测、平衡分析等各种智能分析功能。
3.1.2数据存储
由于所需数据大多存储在现有金房、硕人子系统的数据库中，因此工业库主要采用数据转存的形式来进行数值的获取。
现有系统将数据按照约定的格式，定时转存入专用的SQLServer关系库中，工业库通过特定的SQLToKH转发工具，定时将关系库中的数据进行转存，同时将已进行转存的数据进行及时删除。
在通讯中断时将数据累积保存在关系库中，恢复后按照存储时间悉数转存入KH中，如此既实现了断点续存的功能，用避免的关系库在数据累积后负载过重的隐患。
3.1.3报表和曲线
数据报表是生产过程中至关重要的一个部分，通过数据报表，可以清晰、直观、有效得了解与掌握各生产单元的生产情况，有助于职能单位对当前的油气生产情况进行宏观的把握和全局的统筹。
目前许多单位仍采用人工巡表、手工抄表、人力送表的数据上报机制。
自动报表的生成，极大改善了操作人员到现场看表、抄表的现状，很大程度的解放了劳动力。
通过油田管控系统的数据自动采集功能，实现了数据的实时采集与监测、报表的自动生成与上报。
以便操作人员投入更多精力在提高生产效率方面。
同时自动报表系统支持数据的存储、实时与历史数据查询以及数据趋势曲线与比对功能，与纸质的报表相比，更能准确、快捷的体现生产情况。
3.1.4Web发布
Web发布功能是为了让地理上分布在不同区域的计算机和设备一起工作，以便为用户提供各种各样的服务。
用户可以控制要获取信息的内容、时间、方式，而不必像现在这样在无数个信息孤岛中浏览，去寻找自己所需要的信息。
系统可以将整个工程进行打包发布，也可以对个别画面进行单独发布。
3.1.5运行展示
油所有监控系统的首要任务，都是确保生产运行的安全。
直观、形象的对生产单位（供热厂锅炉房、换热站）进行3D场景复现，生产数据实时展示，使操作人员在调度室就可以对生产单位的情况一目了然。
供热厂
通过各供热厂管辖区域的管网图，可对整个区域进行宏观的掌握。
点击相应生产单位，进入具体的生产流程监控界面。
换热站
点击各换热站点，进行具体站内生产监控。
管道的不同颜色流动代表冷、热水。
3.1.6采集冗余
为了保证整个数据系统的高可靠性和高可用性，IOServer采用双冗余采集机制，正常情况主采集器工作，完成采集工作，当系统检测到主采集出现问题或者网络连接不通时，自动更换到从采集器继续工作。
3.1.7工程模板化
对于锅炉、换热站等内部生产设备对象、图形、组态工程进行模板化，该模板包含所有需要采集、监控等功能，后续实例化便捷开发。
3.1.8智能预警
预警是生产过程中至关重要的一部分，也是监控系统中重要组成部分；
当现场的数据超出正常范围时，系统会以信息弹出、报警栏闪烁等形式将报警信息通知相关工作人员，工作人员接收到报警信息后会对报警做出相应的处理；
同时本系统提供基于历史数据的分析报警。
此外系统提供了强大的报警操作功能：
报警存储功能、报警打印功能、报警显示功能等等，为了方便用户实现对报警事件的查询、记录和打印等操作。
3.2上层分析功能
3.2.1热量累计统计
对8个供热厂的累计热量进行日、月、年报表查询。
对单个供热厂各时/日/月的热量数值进行曲线统计展示。
对某一时刻/某一日/某个月的8个供热厂热量进行棒图形式的数值对比。
3.2.2耗能分析功能
各换热站单位面积平均日/月/年耗能量棒状图对比。
指定换热站一天内/一月内/一年内的耗能趋势曲线展示。
各供热厂管网损耗饼状分布图，包括一次网管损，换热器热损，二次网管损，实际热负荷及其他。
各供热厂（锅炉房）平均日/月/年单位面积供热量棒状图对比。
指定供热厂（锅炉房）一天内/一月内/一年内的供热趋势曲线展示。
3.2.3热负荷预测功能
根据气象局提供的温度信息，查找历史数据库中具有相同温度值标签的符合预测曲线进行平均化操作，再作为负荷预测曲线形式进行展示。
3.2.4全网平衡分析
采用控件嵌入的方式，由操作人员输入机组类型，实际供热面积，采暖热指标，一次网设计供回水温差，人工给定修正系数等，由系统实时提供二次网供回水温度、反馈流量等，通过专业的算法计算出流量偏差值，根据偏差自动调节阀门开度或提供平衡建议，从而实现供热温度的全网平衡。
3.2.5气象信息管理
根据提供的气象信息或者气象数据接口，完成天气预报和历史气象信息的记录。
注：
最终分析系统展示内容视可获取数据信息多少而定。
3.3数据交互功能
目前数据分散储存在两个子监控系统和下位的测量仪表中，系统既要实现将所需数据实时、准确得转存入工业库中，又要实现工业库的数据按条件存入大城管系统的关系库中。
同时系统的web发布功能，使在大城管网页平台中可以灵活调用该平台系统中的监控画面。
4系统整体设计
4.1整体架构
供热平台监控系统包括数据采集与分析、数据传输、数据存储、综合分析应用几个部分。
该系统通过数据采集、通讯传输、展示、分析计算等方法，实现对供热服务区内所有锅炉房和换热站的数据统计和整体监管。
实现对多个分散独立对象的统一监管、整合服务平台，完成供热数据、设备状态信息的统一管理的控制；
完成分散数据源的整合、实现统一的管理分析模式，搭建规范、统一的数据监控平台；
最后实现供热系统与物联网大平台的数据关联，进一步提高供热数据展示的及时性和广泛性。
供热监控总体架构如下图所示：
处在前端的采集与控制子系统，主要通过自动化仪表、传感器、功率模块、RTU、PLC等设备，自动采集、存储、处理锅炉、换热站、集输管网等生产单元的生产数据；
通过ESD、控制阀等自动化控制设备，对生产过程实现自动化控制。
这些数据和信息通过数据传输子系统传输到生产管理子系统进行统一收集、汇总、综合处理和分析，并提供生产实时监控、远程计量、工况分析、预测优化、设备管理等功能。
4.2系统部署
区域监控中心是关键，现场的全部数据整合，整体功能的实现都需要在该层完成。
4.3数据流图
如图所示，区域监控中心实时采集监控现场数据，同时将数据存入工业数据库中。
在该技术方案中，数据存入实时数据库中，功能图型组件作为标准化模块应用集成在平台中使用，从实时库中读取数据，同时在SCADA和Graphic平台上展示。
5系统配置
5.1软件清单
该供热监控系统，用到了下列软件产品，具体产品应用分布及产品应用条件见下表：
亚控软件清单表
系统层级
软件名称
数量
部署位置
区域监控中心
KingSCADA完整版
1
工程师站
KingSCADA运行版
管理中心服务器
KingSCADA客户端/Web客户端
用于客户端机器/网络发布
KingGraphic
KingGraphic分析平台
KingHistorian
设备运维数据服务器
5.2配置要求
5.2.1服务器配置要求
系统所涉及到的软件及使用要求：
硬件环境要求
软件环境要求
KingSCADA
（工程师站、操作员站、web客户端）
CPU主频：
双核2.26GHz
系统内存：
4G
硬盘：
500G
操作系统：
XP、win7旗舰版系统（2003或2008Server）
32位Windows操作系统:
WindowsXP
WindowsVista专业版和旗舰版
Window7专业版和旗舰版
（不支持Home版）
Windows2003server标准版和企业版
Windows2008Server标准版和企业版
同KingSCADA
KingHistorian服务器端：
最低配置：
KingHistorian：
50000点
四核2.26GHz
存储盘阵：
1T
Server系统（2003或2008Server）
32位Windows操作系统：
WindowsVista
Windows7
5.2.2客户端配置要求
客户端/
Web客户端
KingSCADA数据库：
20000点
32位Windows操作系统，支持的操作系统语言版本：
中文简体、英文、日文
WindowsXpsp3
6系统技术参数
6.1系统主要性能指标
6.1.1系统启动
冷启动或掉电后重新启动：
300s
热启动或复位后启动：
250s
6.1.2系统性能指标和时间精度
●站控系统数据控制更新：
1s
●显示时间精度：
●时钟同步精度：
100ms
●图形画面调用：
2s
●动态数据组：
●动态数据组（干扰时）：
5s
●控制触发：
●控制发布：
3s
●窗口显示：
●目标菜单调用：
●报警一览表更新：
●报警确认：
●趋势显示更新，每幅画面至少显示8个变量趋势，更新时间：
6.1.3系统的可用性
●监控中心系统的可用性大于99.99%
6.1.4站控系统的可扩展性
站控系统的容量设计具有100％可扩展性，以满足将来工程设施扩展和增加的需要。
系统的扩展将不会涉及对已建成站控系统的有关软件、硬件设备及相关系统基本配置的变动。
6.1.5系统MTBF及MTTR
系统MTBF（MeanTimeBetweenFailure可修复产品两次相邻故障之间的平均时间）大于20万小时，MTTR（meantimetorestoration，平均恢复前时间）小于5分钟。
6.2KingSCADA
（1）兼容微软的32/64位Windows7及WindowsServer2008操作系统，提供可靠、灵活、高性能的监控系统平台,以及简单易用的配置工具；
（2）支持2D、3D图形模拟技术；
（3）数据库开放C、C++、COM、OPC、ODBC、OLEDB等主流数据交互接口；
（4）数据采集间隔时间的精度控制在10毫秒以内；
（5）支持通过RS232\RS422\RS485、电台、以太网、移动GPRS、CDMA、GSM、Zigbee网络等方式与远程现场设备进行通讯，支持与国内外主流的PLC、SCADA软硬件、DCS、PAC、IPC等设备通信与联网；
（6）支持MapInfo与ArcGIS的地图文件格式，支持组件方式集成GIS-GPS的功能；
6.3KingHistorian
资源方面
历史库对系统资源占用不高,CPU归档时刻为25%以下,非归档时刻为10%以下.变量数越多,存占用越大.10000个变量,占用内存约为90M.在64个存储客户端以内,客户端数目基本没有影响到资源的占用情况.CPU和内存占用,没有受到客户端数目的影响.
响应时间指标方面
历史库存储和查询的响应时间,跟存储和查询的记录条数有关.5000个变量存储10000条记录耗时200~300毫秒。
100个变量查询10000条记录，耗时110毫秒。
吞吐量指标方面
历史库进行存储的吞吐量,在没有查询操作干预或有较少查询操作干预的情况下,可以达到20000条记录每秒.多个查询操作的干预会较大影响历史库的存储性能.经测试,当查询客户端为48个,每个客户端按10秒频率查询时,历史库的吞吐量在5000每秒的水平上完全可以胜任.
变量点数指标方面
历史库没有对变量点数做严格的限制,但参考的变量点数为最大30000点.变量点数增加,会使内存占用增大,历史库文件增多,从而在归档时刻对数据存储和处理带来一定的影响,会使归档时刻的数据处理能力稍微下降,但不会直接严重影响数据的吞吐能力.
多客户端并发性能方面
历史库可以支持64个客户端的同时连接.经测试,64个客户端都进行存储时,历史库可以正常处理,吞吐量可以达到20000点每秒,运行不会出现存储忙等情况;
12个客户端存储,52个客户端查询,吞吐量可以达到5000点每秒,运行时不会现存储忙的情况,查询端查询可以正常返回,查询响应时间在百毫秒级。
硬件配置指标方面
历史库的性能测试是在目前主流的普通计算机上运行的,即CPU3.0G,内存1G,硬盘160G.经测试,如果计算机的磁盘的硬件指标较高,会提升历史库的存储性能,可以提高历史库的数据吞吐量。
6.4KingGraphic
无论是企业生产过程数据还是蕴藏在数据里信息，都需要通过有效的手段和多样的方式进行展示，为此提高KingGraphic数据展示产品。
KingGraphic可以从多个工业实时数据库和关系数据库中获取数据，提供丰富的图形分析组件完成各种统计分析、数据展示，整个操作过程简单方便。
KingGraphic还可以集网站建设、工程Web发布、数据Web发布多种功能为一体，用户完全定制的B/S系统，轻松完成企业实时信息发布平台的建设。
产品亮点
帮助企业及时了解生产信息，应对市场需求；
提升企业生产过程的设备运行管理，减少DOWN机时间；
快速及时的故障诊断，提高预测与分析能力；
主要功能
信息的对象化，将传统的面向标签量的系统转换为面向角色的可扩展的对象模型，方便和易于各类业务人员使用；
结合图表、趋势曲线的生产过程分析，帮助企业发现最佳实践，改进生产操作；
任意时间段的图形回放，直观形象再现历史；
超强的信息整合能力，全面支持各种工业实时数据库和关系数据库；
支持C/S和B/S客户端的架构部署模式；
支持与门户、SharePoint、WebSphere等多种应用平台集成；
6.5KingCalculation
工业库存放了海量的过程数据，然而这些过程数据并不能直接体现生产过程中蕴藏有价值的信息，也就不能成为企业决策的有效依据。
计算平台KingCalculation可以帮您将生产过程数据转化为统
升级会员 