管线智能化管理平台构建项目技术方案样本.docx
《管线智能化管理平台构建项目技术方案样本.docx》由会员分享，可在线阅读，更多相关《管线智能化管理平台构建项目技术方案样本.docx（62页珍藏版）》请在冰豆网上搜索。
管线智能化管理平台构建项目技术方案样本
管线智能化管理平台构建项目
技术文件
年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-
2）《1:
5001:
10001：
地形图图式》GB/T7929-1995
3）《石油工程制图原则》SY/T0003-
4）《工程测量规范》GB50026-93
5）《基本地理信息要素分类与代码》GB/T13923-
6）《输气管道系统完整性管理》SY/T6621-
7）《1：
5000、1：
10000、1：
25000、1：
50000、1：
100000地形图要素分类与代码》GB/T15660-1995
8）《1：
500，1：
1000，1：
地形图数字化规范》GB/T17160-1997
9）《计算机软件产品开发文献编制指南》GB/T8567-1988
10）《计算机软件需求规格阐明规范》GB/T9385-
11）《计算机软件测试规范》GB/T15532-
2.2.建设原则
为实现上述本系统建设目的，数字化管道系统建设遵循统筹规划、分步实行、先进合用原则。
详细体现如下：
12）实用性原则
采用国际先进软件技术，结合国内外最佳实践，开发符合广东天然气管网业务需求数字化系统平台，解决其建设和运营期业务问题，并且保证系统稳定性和易用性。
13）可扩展性原则
系统具备很强可扩展性，随着新管道工程建设，系统数据库可以随之扩展；同步随着业务需求增长、技术进步，系统可以增长新功能子系统、功能模块，从而满足业务需求。
14）可靠性原则
采用成熟、可靠通过实际验证技术和方案，从而保证数据采集精度，以及系统可靠性。
15）原则化原则
符合国家、行业、中海油公司内部数字化建设和数据采集原则规范。
16）先进性原则
保证可靠，实用前提下，选用成熟先进成果和技术，通过技术改造与更新，保证系统5-内先进性。
17）开放性原则
采用通用、开放合同、数据格式、数据库类型从而保证系统开放型，保证系统以便扩展和升级，同步考虑为各种应用开发提供接口支持。
18）安全性原则
采用全方位系统安全保障，从系统单点一体化集成、单点登录、主机保护、访问顾客身份辨认、多级授权、病毒防护和入侵袭击检测等多方面保证数字化系统安全。
19）注重过程管理原则
应针对天然气管道建设特点，考虑到工程建设不可逆性，对数据采集、审核、质量管理、管理办法、技术支持等有关工作提出详细工作方案，保证质量合格。
2.3.系统总体设计
2.3.1.系统建设架构
项目采用成熟三维平台，平台应充分考虑到系统灵活性和将来扩展性，支持对更多类型管道数据、GIS数据、业务数据扩展，同步还支持在平台上开发更多业务功能。
因而，该平台具备将酒泉分公司成果纳入能力，并能为后续管道运营管理、安全应急管理提供业务支撑。
系统架构图
2.3.2.系统布置
基于网络传播模式，系统服务器布置建议集中布置在酒泉分公司，作业区和基层站队分别布置客户端，通过网络传播模式进行远程登录访问。
2.3.3.核心技术路线
平台通过内容综合、形式统一空间数据库，统一采集存贮和管理二维、三维地理信息及管线三维模型，实现大场景站线二三维一体化管理，为各应用系统提供空间操作、空间分析、数据导航、三维展示、专项应用等空间数据解决、显示、计算、存储、共享与分发服务，满足后期二次开发进行应用扩展需求。
2.3.3.1.组件化、面向对象设计开发模式
1）组件化设计
“软件组件化”是一种抱负软件开发理念，它主张软件产品开发应当像制造工业产品那样，一方面通过专业化分工生产出不同功能“零部件”，然后再将这些“零部件”合理地组装起来，形成所需产品。
“软件组件化”，真正实现了软件复用和组件化生产，极大节约软件产品开发时间和开发成本。
组件技术与面向对象开发办法不同是，面向对象技术强调对个体抽象，组件则更推广了对象封装内涵，侧重于复杂系统中构成某些协调关系，强调实体在环境中存在形式。
为了阐明组件化为什么是软件工厂技术基本，咱们先来看看组件基本属性。
从广义上来说，组件有如下几种基本属性：
✧组件是可独立配备单元，因而组件必要自包容；
✧组件强调与环境和其她组件分离，因而组件实现是严格封装，外界没机会或没必要懂得组件内部实现细节；
✧组件可以在恰当环境中被复合使用，因而组件需要提供清晰接口规范，可以与环境交互；
✧组件不应当是持续，即组件没有个体特有属性，理解为组件不应当与自身副本区别。
（1）基本组件描述
1）全息支撑组件
Ø提供空间地理信息数据组织、分类、编辑和管理服务。
Ø提供空间数据及虚拟现实交互式显示服务。
2）系统管理组件
该组件是整个平台核心控制与管理模块，是GIS平台其他模块构建基本。
Ø提供海量数据分发管理，根据数据存储及管理特点，采用相应优化方略，提供三维分析、路由分析、数据解决等底层计算服务。
Ø提供网络智能负载、布置、管理服务，提高系统性能。
3）数据管理组件
对本地各类三维模型数据和空间GIS数据进行管理和支持。
4）数据互换组件
提供专业数据转换解决器，可以对不同类型、不同精度、不同坐标系数据进行转换解决。
5）业务逻辑组件
提供公司业务逻辑拓扑关系定义、维护、检索及组织管理服务。
6）场景显示组件
专用于三维场景中管理镜头特效、摄像机角度位置编辑，可以支持多媒体合成。
7）场景编辑组件
提供场景可视化编辑、模型节点解决，物件关系编辑等工具。
（2）外系统集成组件
已建成果集成分两个层次，一种是简朴集成，通过链接网站或执行程序方式；一种是深度整合，通过集成已建成果数据、界面、操作方式等，实现已建成果有关信息能及时在数字化LNG系统中显示。
针对以上两个层面集成，可采用三种集成方式：
数据库方式、网络通信方式、控件方式。
Ø可作为外系统集成通讯网关，提供接口服务。
Ø支持基于J2EEB/S信息管理配备服务。
（3）原则化二次开发组件
GIS平台提供二次开发组件，支持扩展应用。
支持基于.NET、JAVA等技术体系二次开发。
扩展应用通过接口，可直接调用平台提供数据服务、显示服务、计算服务，完善其业务应用。
2）面向对象
面向对象是一种自下而上程序设计办法，不像过程式设计那样一开始就要用main概括出整个程序，面向对象设计往往从问题一某些着手，一点一点地构建出整个程序。
面向对象设计以数据为中心，类作为体现数据工具，是划分程序基本单位，而函数在面向对象设计中成为了类接口。
面向对象设计自下而上特性，容许开发者从问题局部开始，在开发过程中逐渐加深对系统理解。
这些新理解以及开发中遇到需求变化，都会再作用到系统开发自身，形成一种螺旋式开发方式。
在这种开发方式中，对于已有代码，常需要运用Refactoring技术来做代码重构以体现系统变化。
2.3.3.2.基于面向服务（SOA）架构搭建基本平台
在理解管线只能化管理平台构建项目功能需求基本之上，咱们以为应采用基于面向服务体系构造（Service-OrientedArchitecture）完毕系统之间整合原则模式。
将应用系统不同功能单元（称为“服务”）通过服务之间定义良好接口和契约联系起来。
接口是采用中立方式定义，与实现服务厂商、硬件平台、操作系统和编程语言无关，这样就可以使异构平台上实现各种业务功能，可以以统一和通用方式，互相调用和互换信息。
采用SOA架构有助于项目建设，它可以依照需求通过网络对松散耦合粗粒度应用组件进行分布式布置、组合和使用。
服务层是SOA基本，可以直接被应用调用，从而有效控制系统中与软件代理交互人为依赖性。
在基于SOA架构系统中，详细应用程序功能是由某些松耦合并且具备统一接口定义方式组件（也就是service）组合构建起来。
SOA架构模型如下图所示：
SOA架构模型图
本项目将基于SOA架构模型进行系统规划、设计与建设。
应用系统采用SOA架构长处如下表：
特点
描述
长处，应用性能以及注解
松散耦合
服务提供者和消费者可以用定义良好接口来独立开发。
服务实现者可以更改服务中接口、数据或者消息版本，而不对消费者导致影响。
松散耦合消除了对系统两端进行紧密控制需要。
就系统性能、可伸缩性以及高可用性而言，每个系统都可以实现独立管理。
它并没有消除任何运营时依赖性。
它可以划分众多服务提供者依赖性，但如果该运营时系统需要24x7可用性以及每秒50000吞吐量话，那么对服务提供者这些需求必要得到满足。
实现变化被隐藏了起来。
松散耦合给服务提供者和消费者提供了独立性，但规定基于原则接口和中间物来积极地管理和代理终端系统之间祈求。
基于行业原则
真正行业原则是由技术旗舰如BEA、IBM、Microsoft、Sun、Sql-Server、W3C以及Oasis所承认。
SOA由于其可以用基于原则技术来实现，因此它被广泛接受。
消除了拥有私有客户需要。
使用基于原则技术可打破行业垄断并增进供应商产品最优组合。
松散耦合层概念依赖于在内部和外部对原则广泛支持。
可重用服务
由于服务是在目录中发布并且在整个网络中都可用，因此它们变得更加容易被发现和重用。
如果某个服务不能被重用，那么它也许主线不需要服务接口。
为了不同目再次将服务组合，这种方式也可以实现服务重用。
服务重用避免了重复开发之苦，同步提高了实现中一致性。
服务重用比起组件或者类重用更容易实现，在过去曾尝试过组件和类重用，但很少成功。
同步服务调用（RPC方式）
在同步服务调用中，调用方进行调用、传递所需参数、中断并等待响应。
如果服务提供者可用，那么同步服务调用可为祈求提供及时响应。
同步服务对于规定实时响应应用程序来说是至关重要，例如Portal或者Query。
异步服务调用（文档方式）
在异步服务调用中，调用方向消息收发服务发送一种包括完全上下文消息，收发服务将该消息传递给接受者。
接受者解决该消息并通过消息总线向调用方返回响应。
在消息正在解决过程中，调用方不会中断。
由于粗粒度消息和消息收发服务使用，可以对服务祈求进行排队并以最适当系统速度来解决它们。
这种办法具备高度可伸缩性，因素是队列容许长度是多少，消息收发系统就可以对多少祈求进行排队。
调用方并不在解决过程当中保持网络连接，并且由于调用方并不会中断，因此它们不会受解决延迟负面影响，也不会受异步服务执行中所存在问题负面影响。
本实现采用回调支持，这自身并不是Web服务原则一某些。
无干扰开发（通过使用既有软件组件来开发服务）
既有软件组件并不需要修改就可以将其功能作为服务提供出来。
服务是用组件接口定义开发或生成。
消除了修改、测试以及维护既有软件需要。
有了组合服务，来自既有投资功能可以被重用并重新组合来为公司创造新价值。
方略管理
当把共享服务应用于应用程序中时，针对每个应用程序所特有规则被外化为方略。
在设计和运营时，必要就每个服务进行方略管理和应用。
基于方略计算可以增进普通可重用服务创立。
随着特定应用程序服务定制外化，应用程序实现变化被减少到了最低限度。
普通实行方略是一种组织操作和支持小组，并非开发小组。
如果不使用方略话，应用程序开发人员以及操作和支持小组不得不在应用程序开发过程中并肩工作来实现并测试方略。
方略使用使得开发人员可以集中精力于应用逻辑，而使操作和支持小组专注于规则。
数据访问服务
数据访问、集成、转换以及重用服务。
隐藏数据源复杂性，同步加强跨数据源一致性、完整性以及安全性。
组合服务
组合服务将新既有应用程序逻辑和事务解决进行了合并。
充分运用既有IT投资。
合用于绿地和遗留实现。
装配或者编排产品简化了异构系统集成。
共享或公司基本架构服务
基于SOA构建所有应用程序所使用公共服务称为共享基本架构服务。
使用共享基本架构来提供公共服务可以避免每一种应用程序构建类似服务。
使用共享基本架构服务可提供一致性，并容许单点管理。
其她共享服务（例如与安全有关服务）可以通过将既有产品作为服务直接提供出来方式创立。
细粒度服务
细粒度服务实现最小功能，同步消耗并返回最小量数据。
细粒度服务可以用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/DataBaseServer计算模型中，要完毕功能在浏览器、Web应用服务器和数据库服务器之间进行划分。
硬件Browser/WebServer/DataBaseServer构造，普通是指某项祈求任务在浏览器或Web应用服务器和数据库服务器之间进行分派，其中浏览器用来发送祈求和前端表达解决，Web应用服务器解决来自浏览器祈求，数据库服务器解决数据查询逻辑解决。
对逻辑系统体系来说，分为表达层、商业逻辑解决层、和数据解决层三层客户\服务器构造。
鉴于两层构造（C/S）在设计和应用局限性，将复杂业务数据解决提出，将复杂业务数据解决提出，将系统逻辑构造和物理构造分离，形成三层构造客户\服务器构造，运用基于组件分布式技术，从构造上就避免两层构造局限性。
2）顾客服务（客户层）
顾客服务层是应用顾客接口某些，是顾客与系统间交互信息窗口。
它重要功能是检查顾客输入数据，显示系统输出数据。
如果顾客服务层需要修改时，只需改写显示控制和数据校验程序，而不影响其她两层。
检查内容也只限于数据格式和取值范畴，不涉及关于业务自身解决逻辑。
3）商业服务（中间层）
崭新一层是商业服务层，它是应用主体，它涉及了应用中所有业务解决程序。
除了输入/输出在顾客服务层、数据库在数据服务层外，所有记录、汇总、分析、打印功能所有封装在商业服务层。
它一方面起传递数据作用，一方面进行强大数据解决。
该层还承担安全性检查任务。
4）数据服务（数据库）
数据服务层就是数据库管理系统（DBMS），负责管理对数据库数据读写。
DBMS能迅速执行大量数据更新和检索。
普通商业服务层通过发送SQL命令来操作数据库数据。
5）采用B/S/D架构优势
浏览器Browser/WEB服务器Server/数据库服务器Database是解决公共信息服务以及交互相应动态服务最合用一种应用模型。
实现了真正意义上瘦客户，大大简化了应用系统分发、配备管理和版本管理工作。
2.3.3.4.使用AJAX技术实现页面级数据质量控制和逻辑校验
Web应用交互如Flickr，Backpack和Google在这方面已有质奔腾。
这个术语源自描述从基于网页Web应用到基于数据应用转换。
在基于数据应用中，顾客需求数据如联系人列表，可以从独立于实际网页服务端获得并且可以被动态地写入网页中，给缓慢Web应用体验着色使之像桌面应用同样。
许多重要技术和AJAX开发模式可以从既有知识中获取。
例如，在一种发送祈求到服务端应用中，必要包括祈求顺序、优先级、超时响应、错误解决及回调，其中许多元素已经在Web服务中包括了，就像当前SOA。
AJAX开发人员拥有一种完整系统架构知识。
同步，随着技术成熟还会有许多地方需要改进，特别是UI某些易用性。
AJAX开发与老式CS开发有很大不同。
这些不同引入了新编程问题，最大问题在于易用性。
由于AJAX依赖浏览器JavaScript和XML，浏览器兼容性和支持原则也变得和JavaScript运营时性能同样重要了。
这些问题中大某些来源于浏览器、服务器和技术组合，因而必要理解如何才干最佳使用这些技术。
综合各种变化技术和强耦合客户服务端环境，AJAX提出了一种新开发方式。
AJAX开发人员必要理解老式MVC架构，这限制了应用层次之间边界。
同步，开发人员还需要考虑CS环境外部和使用AJAX技术来重定型MVC边界。
最重要是，AJAX开发人员必要禁止以页面集合方式来考虑Web应用而需要将其以为是单个页面。
一旦UI设计与服务架构之间范畴被严格区别开来后，开发人员就需要更新和变化技术集合了。
2.3.3.5.基于二三维一体化GIS技术
由于本系统是基于GIS数据管理和业务应用系统，因而GIS技术将是本系统核心技术，通过统一二三维一体化GIS平台完毕有关业务操作，详细技术办法体现为：
（1）采用大型关系数据库Sql-Server作为属性数据、业务数据和空间数据存储和管理平台；
（2）使用业主单位原有GIS作为海量空间数据引擎，连接和访问Sql-Server存储空间数据，进行空间数据管理、组织和访问；
2.3.4.系统性能指标
2.3.4.1.响应时间
1）业务查询最大耗时不超过3秒，平均不超过2秒（不涉及打印时间）；
2）报表呈现等系统其他操作最大耗时不超过8秒，平均不超过4秒；
3）信息检索时间最大不能超过3秒，平均速度不能超过1秒；
4）其他页面打开速度平均速度不能超过3秒；
5）批解决时间最大耗时控制在5秒内。
2.3.4.2.稳定性指标
系统持续运营时间为7×24小时不间断运营。
2.3.4.3.吞吐量指标
1）外网同步在线顾客数≧200人；并发顾客数≧20人。
2）内网同步在线顾客数≧200人；并发顾客数≧50人。
2.3.4.4.数据量指标
1）系统支持存储量≥1T。
2）系统支持单次增量备份数据量≥1G。
3）系统数据单次备份时间≤7天。
2.3.5.应用灵活性设计
1）需求及流程变化
顾客在使用系统一段时间后，也许会对既有工作流程提出新需求，本系统工作流程是可维护，对工作流环节和节点内容可以进行修改，删除、新增等操作。
通过工作流管理模块可以保障在顾客需求发生变动时，能及时修改工作流满足顾客使用。
2）操作方式变化
顾客可以通过系统定制功能，将自己惯用功能，将自己操作习惯和惯
升级会员 