管线智能化管理优质方案平台构建项目技术规划精选方案docx.docx
《管线智能化管理优质方案平台构建项目技术规划精选方案docx.docx》由会员分享，可在线阅读，更多相关《管线智能化管理优质方案平台构建项目技术规划精选方案docx.docx（67页珍藏版）》请在冰豆网上搜索。
管线智能化管理优质方案平台构建项目技术规划精选方案docx
管线智能化管理平台构建项目
技术文件
2015年10月26日
1.项目概述与总体需求分析
1.1.项目背景
酒泉分公司管辖范围内管线跨度广、距离长，针对管道管理业务建立了较多业务系统，由于各业务系统相对独立，数据相互割裂，某些业务应用上存在一定局限。
且管道保护业务、完整性管理业务产生的大量数据，如内外检测、完整性评价、地质灾害评估等数据，缺乏有效的整合。
目前基础地理信息数据已覆盖管道全线，数据精度不一，针对
重点部位或工程其数据精度可能难以满足业务需求。
大部分数据已在
PIS系统中入库，数据的准确性有待验证；缺失的数据可以从施工记
录、竣工测量记录中获取，需人为提取。
因此，有必要建立一套智能化管线管理平台，整合各类数据与系统，可视化综合查询与智能分析，有效提升管道管理工作效率。
考虑酒泉分公司管辖范围内管线数量长，牵涉业务较多，为降低实施风险，以及满足现阶段主要需求，管线智能化管理系统选取试点管段（西气东输二线甘肃段46#阀室到桩1953#桩段，全长约342公里）开展部分业务的试点实施。
该管段数据质量相较其他管段比较完整，以此段为试点段最终形成酒泉分公司的智能化管线产品标准，未来基于该系统进行全线业务拓展与推广实施，逐步完善。
1.2.项目建设目标
1.2.1.总体目标
充分利用云计算、物联网、大数据分析、移动应用等信息化最
新技术，按照平战结合的思路，遵循“定位清晰、安全高效、功能灵
活、集成度高、扩展性强”的原则进行管道信息系统建设，为管道信
息共享、现场操作、风险监控、快速维抢、完整性管理和决策提供全
方位的信息支撑，最终实现管控一体化，决策智能化。
1.2.2.试点具体目标
（1）建立酒泉分公司管道一张图管理，对管道基础宏观信息进行查看，主要是分公司管道整体态势管理。
（2）三维场景可视化，将管线走向、本体及附属设施在三维场景中进行可视展示，便于分公司宏观了解查看。
（3）可视化应用功能开发，针对试点项目的业务应用开发相应应用功能，满足实际业务需求。
（4）应急辅助决策，系统具有丰富的辅助决策功能，可根据事故发生地点和资源情况自动匹配生成疏散路径和救援路线。
并提供相关灾情应急处理的全息展示或应急预案行动方案的三维展示，为救援指挥提供参考。
（5）生产数据集成，通过集成SCADA系统的数据，将管道及设施运行过程中的动态数据（如温度、压力、浓度等信息）结合真实的场景展现出来，为管道日常安全监管、应急指挥决策提供实时数据支持。
1.3.项目业务需求
1.3.1.管道三维展示与管理
建立与现实情况一致的管道三维场景，从而实现对于管道所有
的细节信息“一目了然”。
利用管道走向能够三维展现具体某段管线
在地下埋设的管体情况，并可宏观查看沿线管道的附属设施及周边地
形地貌等信息。
1.3.2.海量数据整合查询需求
管道设施从设计到建设，持续产生了大量的数据，管道投入运
行后的维护信息、运行信息以及内外检测信息更是海量增加，这些数
据对于管道的运行调度、完整性管理和管道应急抢修都具有重要意义。
然而，目前各类信息以不同形式记录在不同的介质或信息系统中，需
要查询某一对象的具体信息时，需要花费很长时间去收集和整理，严
重影响了工作效率，甚至会因为某些信息获取不及时导致严重后果。
1.3.3.业务系统整合需求
管道运营管理业务所需数据纷繁复杂，且分散在各个业务部门
中。
在日常工作中关注某一管段或设备时，可能需要查询图纸、施工
记录、维检修记录和当前工况参数等，就需要到多个部门调阅资料或
登陆多个系统去查询，工作极为不便。
上述数据来自不同的单位或系
统，数据格式、参照系等不尽相同。
要打破“信息孤岛”，将各类数
据进行有效整合，需要建立具备强大数据兼容和处理能力的信息平台。
1.3.4.应急响应与辅助决策需求
管线途径地势较为复杂，沿途穿越情况复杂，给应急抢维修或
突发事故的处理带来挑战。
在管道上任何一处出现险情时，都需要查询各方面信息作为决策依据，要求能够在应急状态时快速、准确地查询所关注的各类信息，特别是周边的人居分布、管道沿线高后果区分布和详细情况等信息，并将这些信息直观的展现出来，例如：
事发点周边居民区分布情况、人口数量、需要疏散的范围、地形情况、疏散交通线路、应急资源分布等。
在发生事故后进行应急抢修时快速了解事故造成后果和影响区域，对敏感目标和脆弱目标进行快速救援、保护。
当泄露、地质灾害等灾情出现时，决策人员需要进行快速的响应，准确科学地判断灾情未来发展趋势，这些业务仅靠管线坐标或平面影像图不能满足需求的，要求结合三维可视化场景将应急处置所关注的各类信息、流程、分析结果进行综合呈现。
1.3.5.业务应用分层定制需求
针对作业区及基层站队的职责，进行需求分析和重构，定制满
足实际业务需求的平台，在日常管理业务中，作业区、基层站队所关
注的工作内容不同，如酒泉分公司需要查看基于管道全生命周期的部
分或全部数据，作业区、基层站队需要进行数据分析、后台管理等。
1.3.6.系统集成需求
暂先预留与PIS系统、SCADA系统集成的接口，待今后接入。
本项目系统与PIS系统进行集成对接，所需要的管道基础数据来源于PIS系统，集成对接后，该系统只负责查询与展示完整性数据，数据的更新维护均在PIS系统中完成，但两系统的数据实现同步更新。
若考虑对接周期，可在集成对接未完成之前，该系统也提供一定的数据维护功能。
2.系统总体方案及特点
2.1.建设依据
1）《长距离输油输气管道测量规范》SY/T0055-2003
2）《1:
5001:
10001:
2000地形图图式》GB/T7929-1995
3）《石油工程制图标准》SY/T0003-2003
4）《工程测量规范》GB50026-93
5）《基础地理信息要素分类与代码》GB/T13923-2006
6）《输气管道系统完整性管理》SY/T6621-2005
7）《1：
5000、1：
10000、1：
25000、1：
50000、1：
100000
地形图要素分类与代码》GB/T15660-1995
8）《1：
500，1：
1000，1：
2000地形图数字化规范》
GB/T17160-1997
9）《计算机软件产品开发文件编制指南》GB/T8567-1988
10）《计算机软件需求规格说明规范》GB/T9385-2008
11）《计算机软件测试规范》GB/T15532-2008
2.2.建设原则
为实现上述本系统的建设目标，数字化管道系统建设遵循统筹规划、分步实施、先进适用的原则。
具体表现如下：
1）实用性的原则
采用国际先进的软件技术，结合国内外最佳实践，开发符合广东天然气管网业务需求的数字化系统平台，解决其建设和运营期的业务问题，并且保证系统稳定性和易用性。
2）可扩展性的原则
系统具有很强的可扩展性，随着新管道工程的建设，系统数据库能够随之扩展；同时随着业务需求的增加、技术的进步，系统能够增加新的功能子系统、功能模块，从而满足业务的需求。
3）可靠性的原则
采用成熟、可靠的经过实际验证的技术和方案，从而保证数据采集的精度，以及系统的可靠性。
4）标准化的原则
符合国家、行业、中海油企业内部的数字化建设和数据采集的标准规范。
5）先进性的原则
保证可靠，实用的前提下，选用成熟先进的成果和技术，通过技术改造与更新，保证系统5-10年内的先进性。
6）开放性的原则
采用通用、开放的协议、数据格式、数据库类型从而保证系统的开放型，保证系统的方便扩展和升级，同时考虑为各种应用开发提供接口支持。
7）安全性的原则
采用全方位的系统安全保障，从系统单点一体化集成、单点登录、主机保护、访问用户身份识别、多级授权、病毒防护和入侵攻击检测等多方面保证数字化系统的安全。
8）重视过程管理的原则
应针对天然气管道建设特点，考虑到工程建设的不可逆性，对数据采集、审核、质量管理、管理方法、技术支持等相关工作提出具体工作方案，确保质量合格。
2.3.系统总体设计
2.3.1.系统建设架构
项目采用成熟的三维平台，平台应充分考虑到系统的灵活性和
未来的扩展性，支持对更多类型的管道数据、GIS数据、业务数据的
扩展，同时还支持在平台上开发更多的业务功能。
因此，该平台具备
将酒泉分公司成果纳入的能力，并能为后续管道运营管理、安全应急
管理提供业务支撑。
地理信
管道基
系工
内
第三方
管道
管道
统
息与全
施工
阴极保
地灾害
价
应用层
一
数据
具与基
可化
急管理
息化
可化
可化展示
可化展示
可化
显
展示
本功能
展示
可化
景展示
展示
展示
示
睿-Pipe平台
平台层
睿-Engine（引擎）
调用现
空GIS数
周社
生
急知
施、
运行
日常管理
有GIS
会
、
据
料等基
数据
流数据
控数据
数据库层
数据
要素
源数据
数据
空GIS数据
静数据
数据
Intranet
网络层
独
SCADA
其他信息
立
PIS系
运
系
系⋯
行
系统架构图
2.3.2.系统部署
基于网络传输模式，系统服务器部署建议集中部署在酒泉分公
司，作业区和基层站队分别部署客户端，通过网络传输模式进行远程
登录访问。
2.3.3.关键技术路线
平台通过内容综合、形式统一的空间数据库，统一采集存贮和管
理二维、三维地理信息及管线三维模型，实现大场景站线的二三维一
体化管理，为各应用系统提供空间操作、空间分析、数据导航、三维
展示、专题应用等空间数据处理、显示、计算、存储、共享与分发服
务，满足后期二次开发进行应用扩展的需求。
2.3.3.1.组件化、面向对象的设计开发模式
1）组件化设计
“软件组件化”是一种理想的软件开发理念，它主张软件产品的开发应当像制造工业产品那样，首先通过专业化分工生产出不同功能的“零部件”，然后再将这些“零部件”合理地组装起来，形成所需的产品。
“软件组件化”，真正实现了软件复用和组件化生产，极大节约软件产品的开发时间和开发成本。
组件技术与面向对象的开发方法不同的是，面向对象的技术强调对个体的抽象，组件则更推广了对象封装的内涵，侧重于复杂系统中
组成部分的协调关系，强调实体在环境中的存在形式。
为了说明组件化为什么是软件工厂的技术基础，我们先来看看组件的基本属性。
从广义上来说，组件有如下的几个基本属性：
组件是可独立配置的单元，因此组件必须自包容；
组件强调与环境和其他组件的分离，因此组件的实现是严格封装的，外界没机会或没必要知道组件内部的实现细节；
组件可以在适当的环境中被复合使用，因此组件需要提供清楚的接口规范，可以与环境交互；
组件不应当是持续的，即组件没有个体特有的属性，理解为组件不应当与自身副本区别。
（1）基本组件描述
1）全息支撑组件
提供空间地理信息数据的组织、分类、编辑和管理服务。
提供空间数据及虚拟现实交互式显示服务。
2）系统管理组件
该组件是整个平台的核心控制与管理模块，是GIS平台其它模块
构建的基础。
提供海量数据分发管理，依据数据存储及管理的特点，采取相应优化策略，提供三维分析、路由分析、数据处理等底层计算服务。
提供网络智能负载、部署、管理服务，提高系统性能。
3）数据管理组件
对本地各类三维模型数据和空间GIS数据进行管理和支持。
4）数据交换组件
提供专业的数据转换处理器，可以对不同类型、不同精度、不同
坐标系的数据进行转换处理。
5）业务逻辑组件
提供企业业务逻辑拓扑关系的定义、维护、检索及组织管理
服务。
6）场景显示组件
专用于三维场景中管理镜头特效、摄像机角度位置编辑，可以支
持多媒体合成。
7）场景编辑组件
提供场景可视化编辑、模型节点处理，物件关系编辑等工具。
（2）外系统集成组件
已建成果的集成分两个层次，一种是简单集成，通过链接网站或执行程序的方式；一种是深度整合，通过集成已建成果的数据、界面、操作方式等，实现已建成果相关信息能及时在数字化LNG系统中显示。
针对以上两个层面的集成，可采用三种集成方式：
数据库方式、网络通信方式、控件方式。
可作为外系统集成通讯网关，提供接口服务。
支持基于J2EE的B/S信息管理配置服务。
（3）标准化二次开发组件
GIS平台提供二次开发组件，支持扩展应用。
支持基于.NET、JAVA等技术体系的二次开发。
扩展应用通过接口，
可直接调用平台提供的数据服务、显示服务、计算服务，完善其业务
应用。
2）面向对象
面向对象是一种自下而上的程序设计方法，不像过程式设计那样一开始就要用main概括出整个程序，面向对象设计往往从问题的一部分着手，一点一点地构建出整个程序。
面向对象设计以数据为中心，类作为表现数据的工具，是划分程序的基本单位，而函数在面向对象设计中成为了类的接口。
面向对象设计自下而上的特性，允许开发者从问题的局部开始，在开发过程中逐步加深对系统的理解。
这些新的理解以及开发中遇到的需求变化，都会再作用到系统开发本身，形成一种螺旋式的开发方式。
在这种开发方式中，对于已有的代码，常需要运用Refactoring技术来做代码重构以体现系统的变化。
2.3.3.2.基于面向服务（SOA）架构搭建基础平台
在理解管线只能化管理平台构建项目功能需求的基础之上，我们
认为应采用基于面向服务的体系结构（Service-OrientedArchi-
tecture）完成系统之间整合的标准模式。
将应用系统的不同功能单
元（称为“服务”）通过服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式定义的，与实现服务的厂商、硬件平台、操作
系统和编程语言无关，这样就可以使异构平台上实现的各种业务功能，
可以以统一和通用的方式，互相调用和交换信息。
采用SOA架构有利
于项目的建设，它可以根据需求通过网络对松散耦合的粗粒度应用组
件进行分布式部署、组合和使用。
服务层是SOA的基础，可以直接被
应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合
并且具有统一接口定义方式的组件（也就是service）组合构建起来的。
SOA架构模型如下图所示：
SOA架构模型图
本项目将基于SOA架构模型进行系统的规划、设计与建设。
应用系统采用SOA架构的优点如下表：
特点描述优点，应用性能以及注解
服务提供者和消费者可以用定义良
松散耦合消除了对系统两端进行紧密
好的接口来独立开发。
服务实现者可
控制的需要。
就系统的性能、可伸缩性
以更改服务中的接口、数据或者消息
以及高可用性而言，每个系统都可以实
版本，而不对消费者造成影响。
现独立管理。
它并没有消除任何的运行
时依赖性。
它可以划分众多服务提供者
的依赖性，但如果该运行时系统需要
松散耦合
24x7的可用性以及每秒
50000的吞
吐量的话，那么对服务提供者的这些需
求必须得到满足。
实现的改变被隐藏了
起来。
松散耦合给服务提供者和消费者
提供了独立性，但要求基于标准的接口
和中间物来积极地管理和代理终端系
统之间的请求。
真正的行业标准是由技术旗舰如
使用基于标准的技术可打破行业垄断
BEA、IBM、Microsoft、Sun、
并促进供应商产品的最优组合。
松散耦
基于行业标
Sql-Server、W3C以及Oasis所认
合层的概念依赖于在内部和外部对标
准
可的。
SOA由于其可以用基于标准
准的广泛支持。
的技术来实现，所以它被广泛接
受。
消除了拥有私有客户的需要。
由于服务是在目录中发布并且在整
服务重用避免了重复开发之苦，
同时提
个网络中都可用，所以它们变得更加
高了实现中的一致性。
服务的重用比
容易被发现和重用。
如果某个服务不
起组件或者类的重用更容易实现，
在过
可重用的服
能被重用，那么它可能根本不需要服
去曾尝试过组件和类的重用，但很少成
务
务接口。
为了不同的目的再次将服务
功。
组合，这种方式也可以实现服务的重
用。
在同步服务调用中，调用方进行调
如果服务提供者可用，那么同步服务调
同步服务调
用、传递所需的参数、中断并等待响
用可为请求提供立即响应。
同步服务
用（RPC
方
应。
对于要求实时响应的应用程序来说是
式）
至关重要的，例如Portal
或者Que-
ry。
在异步服务调用中，调用方向消息收发服务发送一个包含完全上下文的消息，收发服务将该消息传递给接收者。
接收者处理该消息并通过消息总线向调用方返回响应。
在消息正在处
异步服务调
理的过程中，调用方不会中断。
用（文档方
式）
由于粗粒度消息和消息收发服务的使用，可以对服务请求进行排队并以最合适的系统速度来处理它们。
这种方法具有高度可伸缩性，原因是队列允许的长度是多少，消息收发系统就能够对多少请求进行排队。
调用方并不在处理过程当中保持网络连接，并且由于调用方并
不会中断，所以它们不会受处理延迟的负面影响，也不会受异步服务执行中所存在问题的负面影响。
本实现采用回调的支持，这本身并不是
Web服务标准的一部分。
无干扰
开发（通过
使用现有的
软件组件来
开发服务）
策略管
理
现有的软件组件并不需要修改就可消除了修改、测试以及维护现有软件的
以将其功能作为服务提供出来。
服务需要。
是用组件的接口定义开发或生成的。
有了组合服务，来自现有投资的功能可
以被重用并重新组合来为企业创造新
的价值。
当把共享的服务应用于应用程序中
基于策略的计算可以促进普通的可重
时，针对每个应用程序所特有的规则
用服务的创建。
随着特定应用程序服务
被外化为策略。
在设计和运行时，
定制的外化，应用程序实现的变化被减
必须就每个服务进行策略的管理和
少到了最低限度。
应用。
通常实施策略的是一个组织的操作和
支持小组，并非开发小组。
如果不使用
策略的话，应用程序的开发人员以及操
作和支持小组不得不在应用程序开发
过程中并肩工作来实现并测试策略。
策
略的使用使得开发人员能够集中精力
于应用逻辑，而使操作和支持小组专注
于规则。
数据访
问服务
组合服
务
共享的
或企业的基
础架构服务
数据访问、集成、转换以及重用服务。
组合服务将新的现有的应用程序逻辑和事务处理进行了合并。
基于SOA构建的所有应用程序所使用的公共服务称为共享的基础架构服务。
使用共享的基础架构来提供公共服务可以避免每一个应用程序构建类似的服务。
隐藏数据源的复杂性，同时加强跨数据源的一致性、完整性以及安全性。
充分利用现有的IT投资。
适用于绿地
和遗留实现。
装配或者编排产品简化了异构系统的集成。
使用共享的基础架构服务可提供一致性，并允许单点管理。
其他的共享服务（例如与安全相关的服务）可以通过将现有的产品作为服务直接提供出来的方式创建。
细粒度服务实现最小的功能，同时消
细粒度服务的优点是可在粒度级实施
耗并返回最小量的数据。
严格的安全和访问策略。
细粒度
细粒度服务可以用
Web服务来实
实现和单元测试很简单，而且相互独
服务
RMI、.Net或
立。
现，也可以利用基于
者CORBA的分布式对象来实现。
粗粒度
服务
粗粒度服务比细粒度服务实现更多粗粒度服务不需要通过网络多次调用
的功能，并消耗不同数量的结构化数来提供有意义的业务功能。
据或者消息。
它们返回类似的数据或
者消息，可能还含有内嵌的上下文。
2.3.3.3.基于J2EE技术框架及三层结构开发应用系统
整体技术体系上选用J2EE技术，采用Browser/WebServer/DataBaseServer三层结构进行应用系统的开发。
Browser/WebServer/DataBaseServer三层结构如上图所示，下
面对B/S/D三层结构作详细的阐述。
实现数据与应用逻辑分离。
1）数据与应用逻辑分离的特征
Browser/WebServer/DataBaseServer结构指硬件的体系结构，
也有相应的逻辑的体系结构相对应。
在Browser/WebServer/Data
升级会员 