管线智能化管理平台构建项目技术方案.docx
《管线智能化管理平台构建项目技术方案.docx》由会员分享,可在线阅读,更多相关《管线智能化管理平台构建项目技术方案.docx(46页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、管线智能化管理平台构建项目技 术 文 件 2015 年 10 月 26 日目 录 o 1-3 h z u 1.项目概述与总体需求分析11.1.项目背景11.2.项目建设目标11.2.1.总体目标11.2.2.试点具体目标21.3.项目业务需求21.3.1.管道三维展示与管理21.3.2.海量数据整合查询需求21.3.3.业务系统整合需求31.3.4.应急响应与辅助决策需求31.3.5.业务应用分层定制需求31.3.6.系统集成需求42.系统总体方案及特点42.1.建设依据42.2.建设原则42.3.系统总体设计62.3.1.系统建设架构62.3.2.系统部署72.3.3.关键技术路线72.3.
2、4.系统性能指标72.3.5.应用灵活性设计82.3.6.系统安全设计92.4.实施阶段及进度102.5.构建地理信息场景102.5.1.数字地球102.5.2.三维地形122.6.管道基础数据可视化展示系统122.6.1.图层控制132.6.2.权限控制142.6.3.三维空间量算152.7.内检测数据可视化展示系统212.8.第三方施工可视化系统232.8.1.需求分析232.8.2.系统特点232.9.阴极保护数据可视化展示系统252.10.地质灾害可视化展示系统272.11.管道风险评价可视化展示292.11.1.数据批量导入292.12.管道应急管理302.12.1.管道应急管理系统
3、特点302.12.2.应急资源三维展示312.12.3.三维可视化预案322.12.4.应急模拟演练352.13.外系统集成362.13.1.系统集成372.13.2.系统集成372.14.数据资源建设整合372.14.1.数据整合372.14.2.管线基础信息采集382.14.3.管线周边环境应急资源信息整合392.14.4.三维场景建设422.14.5.管道采集数据的整理分析与转换入库482.14.6.历史数据资料整理分析与转换入库483.系统实施方案493.1.项目组织计划及实施方案493.2.保密方案494.技术标书响应说明501. 项目概述与总体需求分析1.1. 项目背景酒泉分公司管
4、辖范围内管线跨度广、距离长,针对管道管理业务建立了较多业务系统,由于各业务系统相对独立,数据相互割裂,某些业务应用上存在一定局限。且管道保护业务、完整性管理业务产生的大量数据,如内外检测、完整性评价、地质灾害评估等数据,缺乏有效的整合。目前基础地理信息数据已覆盖管道全线,数据精度不一,针对重点部位或工程其数据精度可能难以满足业务需求。大部分数据已在系统中入库,数据的准确性有待验证;缺失的数据可以从施工记录、竣工测量记录中获取,需人为提取。因此,有必要建立一套智能化管线管理平台,整合各类数据与系统,可视化综合查询与智能分析,有效提升管道管理工作效率。考虑酒泉分公司管辖范围内管线数量长,牵涉业务较
5、多,为降低实施风险,以及满足现阶段主要需求,管线智能化管理系统选取试点管段(西气东输二线甘肃段46#阀室到桩1953#桩段,全长约342公里)开展部分业务的试点实施。该管段数据质量相较其他管段比较完整,以此段为试点段最终形成酒泉分公司的智能化管线产品标准,未来基于该系统进行全线业务拓展与推广实施,逐步完善。1.2. 项目建设目标1.2.1. 总体目标充分利用云计算、物联网、大数据分析、移动应用等信息化最新技术,按照平战结合的思路,遵循“定位清晰、安全高效、功能灵活、集成度高、扩展性强”的原则进行管道信息系统建设,为管道信息共享、现场操作、风险监控、快速维抢、完整性管理和决策提供全方位的信息支撑
6、,最终实现管控一体化,决策智能化。1.2.2. 试点具体目标(1)建立酒泉分公司管道一张图管理,对管道基础宏观信息进行查看,主要是分公司管道整体态势管理。(2)三维场景可视化,将管线走向、本体及附属设施在三维场景中进行可视展示,便于分公司宏观了解查看。(3)可视化应用功能开发,针对试点项目的业务应用开发相应应用功能,满足实际业务需求。(4)应急辅助决策,系统具有丰富的辅助决策功能,可根据事故发生地点和资源情况自动匹配生成疏散路径和救援路线。并提供相关灾情应急处理的全息展示或应急预案行动方案的三维展示,为救援指挥提供参考。(5)生产数据集成,通过集成系统的数据,将管道及设施运行过程中的动态数据(
7、如温度、压力、浓度等信息)结合真实的场景展现出来,为管道日常安全监管、应急指挥决策提供实时数据支持。1.3. 项目业务需求1.3.1. 管道三维展示与管理建立与现实情况一致的管道三维场景,从而实现对于管道所有的细节信息“一目了然”。利用管道走向能够三维展现具体某段管线在地下埋设的管体情况,并可宏观查看沿线管道的附属设施及周边地形地貌等信息。1.3.2. 海量数据整合查询需求管道设施从设计到建设,持续产生了大量的数据,管道投入运行后的维护信息、运行信息以及内外检测信息更是海量增加,这些数据对于管道的运行调度、完整性管理和管道应急抢修都具有重要意义。然而,目前各类信息以不同形式记录在不同的介质或信
8、息系统中,需要查询某一对象的具体信息时,需要花费很长时间去收集和整理,严重影响了工作效率,甚至会因为某些信息获取不及时导致严重后果。1.3.3. 业务系统整合需求管道运营管理业务所需数据纷繁复杂,且分散在各个业务部门中。在日常工作中关注某一管段或设备时,可能需要查询图纸、施工记录、维检修记录和当前工况参数等,就需要到多个部门调阅资料或登陆多个系统去查询,工作极为不便。上述数据来自不同的单位或系统,数据格式、参照系等不尽相同。要打破“信息孤岛”,将各类数据进行有效整合,需要建立具备强大数据兼容和处理能力的信息平台。1.3.4. 应急响应与辅助决策需求管线途径地势较为复杂,沿途穿越情况复杂,给应急
9、抢维修或突发事故的处理带来挑战。在管道上任何一处出现险情时,都需要查询各方面信息作为决策依据,要求能够在应急状态时快速、准确地查询所关注的各类信息,特别是周边的人居分布、管道沿线高后果区分布和详细情况等信息,并将这些信息直观的展现出来,例如:事发点周边居民区分布情况、人口数量、需要疏散的范围、地形情况、疏散交通线路、应急资源分布等。在发生事故后进行应急抢修时快速了解事故造成后果和影响区域,对敏感目标和脆弱目标进行快速救援、保护。当泄露、地质灾害等灾情出现时,决策人员需要进行快速的响应,准确科学地判断灾情未来发展趋势,这些业务仅靠管线坐标或平面影像图不能满足需求的,要求结合三维可视化场景将应急处
10、置所关注的各类信息、流程、分析结果进行综合呈现。1.3.5. 业务应用分层定制需求针对作业区及基层站队的职责,进行需求分析和重构,定制满足实际业务需求的平台,在日常管理业务中,作业区、基层站队所关注的工作内容不同,如酒泉分公司需要查看基于管道全生命周期的部分或全部数据,作业区、基层站队需要进行数据分析、后台管理等。1.3.6. 系统集成需求暂先预留与系统、系统集成的接口,待今后接入。本项目系统与系统进行集成对接,所需要的管道基础数据来源于系统,集成对接后,该系统只负责查询与展示完整性数据,数据的更新维护均在系统中完成,但两系统的数据实现同步更新。若考虑对接周期,可在集成对接未完成之前,该系统也
11、提供一定的数据维护功能。2. 系统总体方案及特点2.1. 建设依据1) 长距离输油输气管道测量规范0055-20032) 1:500 1:1000 1:2000 地形图图式7929-19953) 石油工程制图标准0003-20034) 工程测量规范 50026-935) 基础地理信息要素分类与代码 13923-20066) 输气管道系统完整性管理6621-20057) 1:5000、1:10000、1:25000、1:50000、1:100000地形图要素分类与代码15660-19958) 1:500,1:1000,1:2000地形图数字化规范17160-19979) 计算机软件产品开发文件编
12、制指南 8567-198810) 计算机软件需求规格说明规范 9385-200811) 计算机软件测试规范 15532-20082.2. 建设原则为实现上述本系统的建设目标,数字化管道系统建设遵循统筹规划、分步实施、先进适用的原则。具体表现如下:1) 实用性的原则采用国际先进的软件技术,结合国内外最佳实践,开发符合广东天然气管网业务需求的数字化系统平台,解决其建设和运营期的业务问题,并且保证系统稳定性和易用性。2) 可扩展性的原则系统具有很强的可扩展性,随着新管道工程的建设,系统数据库能够随之扩展;同时随着业务需求的增加、技术的进步,系统能够增加新的功能子系统、功能模块,从而满足业务的需求。3
13、) 可靠性的原则采用成熟、可靠的经过实际验证的技术和方案,从而保证数据采集的精度,以及系统的可靠性。4) 标准化的原则符合国家、行业、中海油企业内部的数字化建设和数据采集的标准规范。5) 先进性的原则保证可靠,实用的前提下,选用成熟先进的成果和技术,通过技术改造与更新,保证系统5-10年内的先进性。6) 开放性的原则采用通用、开放的协议、数据格式、数据库类型从而保证系统的开放型,保证系统的方便扩展和升级,同时考虑为各种应用开发提供接口支持。7) 安全性的原则采用全方位的系统安全保障,从系统单点一体化集成、单点登录、主机保护、访问用户身份识别、多级授权、病毒防护和入侵攻击检测等多方面保证数字化系
14、统的安全。8) 重视过程管理的原则应针对天然气管道建设特点,考虑到工程建设的不可逆性,对数据采集、审核、质量管理、管理方法、技术支持等相关工作提出具体工作方案,确保质量合格。2.3. 系统总体设计2.3.1. 系统建设架构项目采用成熟的三维平台,平台应充分考虑到系统的灵活性和未来的扩展性,支持对更多类型的管道数据、数据、业务数据的扩展,同时还支持在平台上开发更多的业务功能。因此,该平台具备将酒泉分公司成果纳入的能力,并能为后续管道运营管理、安全应急管理提供业务支撑。系统架构图2.3.2. 系统部署基于网络传输模式,系统服务器部署建议集中部署在酒泉分公司,作业区和基层站队分别部署客户端,通过网络
15、传输模式进行远程登录访问。2.3.3. 关键技术路线平台通过内容综合、形式统一的空间数据库,统一采集存贮和管理二维、三维地理信息及管线三维模型,实现大场景站线的二三维一体化管理,为各应用系统提供空间操作、空间分析、数据导航、三维展示、专题应用等空间数据处理、显示、计算、存储、共享与分发服务,满足后期二次开发进行应用扩展的需求。2.3.3.1. 组件化、面向对象的设计开发模式1) 组件化设计“软件组件化”是一种理想的软件开发理念,它主张软件产品的开发应当像制造工业产品那样,首先通过专业化分工生产出不同功能的“零部件”,然后再将这些“零部件”合理地组装起来,形成所需的产品。“软件组件化”,真正实现
16、了软件复用和组件化生产,极大节约软件产品的开发时间和开发成本。组件技术与面向对象的开发方法不同的是,面向对象的技术强调对个体的抽象,组件则更推广了对象封装的内涵,侧重于复杂系统中组成部分的协调关系,强调实体在环境中的存在形式。 为了说明组件化为什么是软件工厂的技术基础,我们先来看看组件的基本属性。从广义上来说,组件有如下的几个基本属性: 组件是可独立配置的单元,因此组件必须自包容; 组件强调与环境和其他组件的分离,因此组件的实现是严格封装的,外界没机会或没必要知道组件内部的实现细节; 组件可以在适当的环境中被复合使用,因此组件需要提供清楚的接口规范,可以与环境交互; 组件不应当是持续的,即组件
17、没有个体特有的属性,理解为组件不应当与自身副本区别。(1) 基本组件描述1) 全息支撑组件 提供空间地理信息数据的组织、分类、编辑和管理服务。 提供空间数据及虚拟现实交互式显示服务。2) 系统管理组件该组件是整个平台的核心控制与管理模块,是平台其它模块构建的基础。 提供海量数据分发管理,依据数据存储及管理的特点,采取相应优化策略,提供三维分析、路由分析、数据处理等底层计算服务。 提供网络智能负载、部署、管理服务,提高系统性能。3) 数据管理组件对本地各类三维模型数据和空间数据进行管理和支持。4) 数据交换组件提供专业的数据转换处理器,可以对不同类型、不同精度、不同坐标系的数据进行转换处理。5)
18、 业务逻辑组件提供企业业务逻辑拓扑关系的定义、维护、检索及组织管理服务。6) 场景显示组件专用于三维场景中管理镜头特效、摄像机角度位置编辑,可以支持多媒体合成。7) 场景编辑组件提供场景可视化编辑、模型节点处理,物件关系编辑等工具。(2) 外系统集成组件已建成果的集成分两个层次,一种是简单集成,通过链接网站或执行程序的方式;一种是深度整合,通过集成已建成果的数据、界面、操作方式等,实现已建成果相关信息能及时在数字化系统中显示。针对以上两个层面的集成,可采用三种集成方式:数据库方式、网络通信方式、控件方式。 可作为外系统集成通讯网关,提供接口服务。 支持基于J2的信息管理配置服务。(3) 标准化
19、二次开发组件平台提供二次开发组件,支持扩展应用。支持基于、等技术体系的二次开发。扩展应用通过接口,可直接调用平台提供的数据服务、显示服务、计算服务,完善其业务应用。2) 面向对象面向对象是一种自下而上的程序设计方法,不像过程式设计那样一开始就要用概括出整个程序,面向对象设计往往从问题的一部分着手,一点一点地构建出整个程序。面向对象设计以数据为中心,类作为表现数据的工具,是划分程序的基本单位,而函数在面向对象设计中成为了类的接口。面向对象设计自下而上的特性,允许开发者从问题的局部开始,在开发过程中逐步加深对系统的理解。这些新的理解以及开发中遇到的需求变化,都会再作用到系统开发本身,形成一种螺旋式
20、的开发方式。在这种开发方式中,对于已有的代码,常需要运用技术来做代码重构以体现系统的变化。2.3.3.2. 基于面向服务()架构搭建基础平台在理解管线只能化管理平台构建项目功能需求的基础之上,我们认为应采用基于面向服务的体系结构( )完成系统之间整合的标准模式。将应用系统的不同功能单元(称为“服务”)通过服务之间定义良好的接口和契约联系起来。接口是采用中立的方式定义的,与实现服务的厂商、硬件平台、操作系统和编程语言无关,这样就可以使异构平台上实现的各种业务功能,可以以统一和通用的方式,互相调用和交换信息。采用架构有利于项目的建设,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、
21、组合和使用。服务层是的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。在基于架构的系统中,具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件(也就是)组合构建起来的。架构模型如下图所示:架构模型图本项目将基于架构模型进行系统的规划、设计与建设。应用系统采用架构的优点如下表:特点描述优点,应用性能以及注解松散耦合服务提供者和消费者可以用定义良好的接口来独立开发。服务实现者可以更改服务中的接口、数据或者消息版本,而不对消费者造成影响。松散耦合消除了对系统两端进行紧密控制的需要。就系统的性能、可伸缩性以及高可用性而言,每个系统都可以实现独立管理。它并没有消除任何的
22、运行时依赖性。它可以划分众多服务提供者的依赖性,但如果该运行时系统需要 24x7 的可用性以及每秒 50000 的吞吐量的话,那么对服务提供者的这些需求必须得到满足。实现的改变被隐藏了起来。松散耦合给服务提供者和消费者提供了独立性,但要求基于标准的接口和中间物来积极地管理和代理终端系统之间的请求。基于行业标准真正的行业标准是由技术旗舰如、W3C 以及 所认可的。 由于其可以用基于标准的技术来实现,所以它被广泛接受。消除了拥有私有客户的需要。使用基于标准的技术可打破行业垄断并促进供应商产品的最优组合。松散耦合层的概念依赖于在内部和外部对标准的广泛支持。可重用的服务由于服务是在目录中发布并且在整个
23、网络中都可用,所以它们变得更加容易被发现和重用。如果某个服务不能被重用,那么它可能根本不需要服务接口。为了不同的目的再次将服务组合,这种方式也可以实现服务的重用。服务重用避免了重复开发之苦,同时提高了实现中的一致性。 服务的重用比起组件或者类的重用更容易实现,在过去曾尝试过组件和类的重用,但很少成功。同步服务调用 ( 方式)在同步服务调用中,调用方进行调用、传递所需的参数、中断并等待响应。如果服务提供者可用,那么同步服务调用可为请求提供立即响应。 同步服务对于要求实时响应的应用程序来说是至关重要的,例如 或者 。异步服务调用(文档方式)在异步服务调用中,调用方向消息收发服务发送一个包含完全上下
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 管线 智能化 管理 平台 构建 项目 技术 方案
限制150内