管线智能化管理平台构建项目技术方案.doc

管线智能化管理平台构建项目技 术 文 件 2015 年 10 月 26 日管线智能化管理平台构建项目 技术文件目 录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.4.系统性能指标72.3。5。应用灵活性设计82.3。6.系统安全设计92。4.实施阶段及进度102.5。构建地理信息场景102.5。1。数字地球102.5.2.三维地形DEM122。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.管道应急管理系统特点302.12。2.应急资源三维展示312.12。3。三维可视化预案322.12。4。应急模拟演练352.13.外系统集成362.13.1。PIS系统集成372。13。2.SCADA系统集成372。14。数据资源建设整合372。14。1。GIS数据整合372。14.2。管线基础信息采集382.14.3.管线周边环境应急资源信息整合392.14。4.三维场景建设422.14.5.管道采集数据的整理分析与转换入库482。14。6.历史数据资料整理分析与转换入库483.系统实施方案493。1.项目组织计划及实施方案493。2。保密方案494.技术标书响应说明50IV1. 项目概述与总体需求分析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-20032) 1:500 1:1000 1：2000 地形图图式GB/T7929-19953) 石油工程制图标准SY/T000320034) 工程测量规范GB 50026935) 基础地理信息要素分类与代码GB/T 13923-20066) 输气管道系统完整性管理SY/T662120057) 1：5000、1：10000、1：25000、1：50000、1:100000地形图要素分类与代码GB/T15660-19958) 1:500，1:1000，1：2000地形图数字化规范GB/T17160-19979) 计算机软件产品开发文件编制指南GB/T 8567-198810) 计算机软件需求规格说明规范 GB/T 9385200811) 计算机软件测试规范GB/T 15532-20082.2. 建设原则为实现上述本系统的建设目标，数字化管道系统建设遵循统筹规划、分步实施、先进适用的原则.具体表现如下:1) 实用性的原则采用国际先进的软件技术，结合国内外最佳实践，开发符合广东天然气管网业务需求的数字化系统平台，解决其建设和运营期的业务问题，并且保证系统稳定性和易用性。2) 可扩展性的原则系统具有很强的可扩展性，随着新管道工程的建设，系统数据库能够随之扩展；同时随着业务需求的增加、技术的进步,系统能够增加新的功能子系统、功能模块，从而满足业务的需求。3) 可靠性的原则采用成熟、可靠的经过实际验证的技术和方案，从而保证数据采集的精度，以及系统的可靠性。4) 标准化的原则符合国家、行业、中海油企业内部的数字化建设和数据采集的标准规范.5) 先进性的原则保证可靠，实用的前提下，选用成熟先进的成果和技术，通过技术改造与更新，保证系统5-10年内的先进性。6) 开放性的原则采用通用、开放的协议、数据格式、数据库类型从而保证系统的开放型，保证系统的方便扩展和升级，同时考虑为各种应用开发提供接口支持。7) 安全性的原则采用全方位的系统安全保障,从系统单点一体化集成、单点登录、主机保护、访问用户身份识别、多级授权、病毒防护和入侵攻击检测等多方面保证数字化系统的安全。8) 重视过程管理的原则应针对天然气管道建设特点，考虑到工程建设的不可逆性,对数据采集、审核、质量管理、管理方法、技术支持等相关工作提出具体工作方案，确保质量合格。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系统中显示。针对以上两个层面的集成，可采用三种集成方式:数据库方式、网络通信方式、控件方式。 可作为外系统集成通讯网关,提供接口服务. 支持基于J2EE的B/S信息管理配置服务.（3） 标准化二次开发组件GIS平台提供二次开发组件，支持扩展应用。支持基于.NET、JAVA等技术体系的二次开发。扩展应用通过接口，可直接调用平台提供的数据服务、显示服务、计算服务，完善其业务应用。2) 面向对象面向对象是一种自下而上的程序设计方法，不像过程式设计那样一开始就要用main概括出整个程序,面向对象设计往往从问题的一部分着手,一点一点地构建出整个程序。面向对象设计以数据为中心,类作为表现数据的工具，是划分程序的基本单位，而函数在面向对象设计中成为了类的接口。面向对象设计自下而上的特性,允许开发者从问题的局部开始,在开发过程中逐步加深对系统的理解。这些新的理解以及开发中遇到的需求变化，都会再作用到系统开发本身，形成一种螺旋式的开发方式。在这种开发方式中，对于已有的代码，常需要运用Refactoring技术来做代码重构以体现系统的变化。2.3.3.2. 基于面向服务(SOA）架构搭建基础平台在理解管线只能化管理平台构建项目功能需求的基础之上，我们认为应采用基于面向服务的体系结构（Service-Oriented Architecture)完成系统之间整合的标准模式。将应用系统的不同功能单元（称为“服务”)通过服务之间定义良好的接口和契约联系起来.接口是采用中立的方式定义的,与实现服务的厂商、硬件平台、操作系统和编程语言无关，这样就可以使异构平台上实现的各种业务功能，可以以统一和通用的方式，互相调用和交换信息。采用SOA架构有利于项目的建设,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件(也就是service）组合构建起来的。SOA架构模型如下图所示：SOA架构模型图本项目将基于SOA架构模型进行系统的规划、设计与建设.应用系统采用SOA架构的优点如下表：第 34页，共 52页特点描述优点，应用性能以及注解松散耦合服务提供者和消费者可以用定义良好的接口来独立开发.服务实现者可以更改服务中的接口、数据或者消息版本，而不对消费者造成影响。松散耦合消除了对系统两端进行紧密控制的需要。就系统的性能、可伸缩性以及高可用性而言,每个系统都可以实现独立管理。它并没有消除任何的运行时依赖性。它可以划分众多服务提供者的依赖性,但如果该运行时系统需要 24x7 的可用性以及每秒 50000 的吞吐量的话，那么对服务提供者的这些需求必须得到满足。实现的改变被隐藏了起来.松散耦合给服务提供者和消费者提供了独立性,但要求基于标准的接口和中间物来积极地管理和代理终端系统之间的请求.基于行业标准真正的行业标准是由技术旗舰如BEA、IBM、Microsoft、Sun、SqlServer、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 / Web Server / Data Base Server计算模型中,要完成的功能在浏览器、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）采用大型关系数据库SqlServer作为属性数据、业务数据和空间数据存储和管理平台；（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. 稳定性指标系统持续运行时间为724小时不间断运行。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) 操作方式变化用户可以通过系统定制功能，将自己常用的功能，将自己的操作习惯和常用的功能模块定制成用户指定的方式。同时可以对定制后的结果进行维护。3) 机构人员变化机构人员变化后用户权限也会发生相应变化，用户浏览的数据以及使用的功能也会发生变化。通过用户权限管理功能,可以对用户使用的功能和浏览的数据进行权限维护.保障使用系统机构人员变化，能正常安全的使用系统.4) 操作系统环境变化平台采用基于SOA和JAVAEE体系设计理念，便于实现跨平台与互操作。J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。同时利用WebServices方法实现一种松散耦合的异构式环境的集成，数据功能封装成接口，构建面向服务的系统平台. 2.3.6. 系统安全设计1) 防止主机崩溃方法采用高可靠性集群是目前关键业务系统提高系统可靠性的重要手段之一。实现方式是采用多台服务器运行管理业务系统，一台服务器作为另一台的备份或者在几台服务器之间平均分布负载,以达到在一台服务器出现故障时系统仍然能够正常运行的目的。采用负载均衡动态集群技术，使用多台服务器协同服务，保证管线智能化管理平台系统稳定性.2) 防治病毒方法建立全方位的安全体系.安装防病毒软件和防火墙；通过对特定网段、服务建立的访问控制体系；建立良好的认证体系以防止攻击者假冒合法用户;通过对安全漏洞和的周期检查,即使攻击可到达攻击目标,也可使绝大多数攻击无效；通过对特定网段、服务建立的攻击监控体系，实时检测绝大多数攻击，并采取相应的行动（如断开网络连接、记录攻击过程、跟踪攻击源等）等。通过对管线智能化管理平台系统统一数据库的数据定期的查杀病毒，可以保障数据的安全性。3) 数据备份方法备份系统规划采用统一的备份策略管理，通过专业的备份软件提供SAN的自动备份系统.在备份系统中所有的服务器逻辑上分为两种:制定统一的备份策略和备份指令的发出;负责备份需求的支持和响应。从总体上来讲，备份类型主要有三种：(1) 全备份每次备份定义的所有数据,优点是恢复快，缺点是备份数据量大，数据多时做一次全备份需很长时间。(2) 增量备份备份自上一次备份以来更新的所有数据,其优点是每次备份的数据量少，缺点是恢复时需要全备份及多份增量备份。(3) 差分备份备份自上一次全备份以来更新的所有数据,其优缺点介于上两者之间。在备份类型选择时，一般的规则是：a) 对于操作系统和应用程序代码，可在每次系统更新或安装新软件时做一次全备份。b) 对于一些日常数据更新量大，但总体数据量不是非常大的关键应用数据，可每天在用户使用量较小的时候安排全备份.对于日常更新量相对于总体数据量较小，而总体数据量非常大的关键应用数据，可每隔一个月或一周安排一次全备份，再此基础上，每隔一个较短的时间间隔做增量备份。2.4. 实施阶段及进度具体实施进度按项目要求进行。2.5. 构建地理信息场景2.5.1. 数字地球通过平台，加载数字高程模型、数字正射影像图、周边矢量等信息，构建三维数字地球。系统支持大场景加载优化技术，能够加载海量数据.数字地球可显示地球大气层、星空，模拟天气变化情况，通过改变视角和相机高度,自定义显示管线三维场景及周边的彩色地景、行政区划、敏感地带及人口等信息。管道基础数据可视化展示系统、内检测数据可视化展示系统等子系统通过地理信息场景进入.数字地球天空背景天气模拟2.5.2. 三维地形DEM通过加入DEM数据参与切图,生成带有真实地形的数字地球，直观展示管道沿线的地理场景真实地貌状况，使用户有身临其境的感觉，也有助于主管单位对气田和管道环境进行监测，保障生产安全。三维地形2.6. 管道基础数据可视化展示系统管道从可研、勘察、设计、施工到运行、维护的过程中涉及到大量的基础数据、图纸资料，系统不仅可以将管线图纸资料电子化后进行分类保存，而且被授予权限的用户还可对数据进行增加、删除、更新等操作。平台还能够根据用户要求和权限，灵活地配置可见或不可见的图层，即添加用户时，可给新用户分派不同的权限,不同权限的用户可使用的系统功能不同。2.6.1. 图层控制（1)地理空间信息分层分类管理在三维场景中对各种地理空间信息进行合理地分层分类管理,可以根据用户的要求灵活地定制各种显示方案,提供对图层的符号配置、比例尺设置、信息提示等,从而为用户的图形化操作提供配置管理。图层叠加显示(2）根据地理空间数据库的设计，对空间数据进行树状分层地管理。图层管理（4)平台支持比例尺设置和地理空间信息显示样式的设置，用户可以根据需要,针对不同的地理空间信息选择合适的比例尺和显示样式。（5）可根据空间数据库中的最新数据产生新的图层设置。(6）平台支持矢量、栅格等不同数据类型的图层进行叠加且透明地显示.2.6.2. 权限控制功能模块功能分类功能描述权限管理功能点包括对用户、角色、组织机构、权限配置、角色权限配置、删除用户的管理,可进行增、删、改、查等功能日志管理功能点可查看到操作日志、在线用户的基本信息配置管理功能点可查看对系统参数配置与勘察参数配置的基本信息2.6.3. 三维空间量算本平台提供空间量测、标绘、制图等功能，包括坐标量算、直线距离量算、水平距离量算、高度量算、地表距离量算、截面积量算、断面分析、视域分析、通视分析、清除测量结果等，可在应急时进行辅助决策,也可为设计施工方便快捷的提供精确地测数据，节省大量人力和物力；同时支持企业、道路、居民区等的模拟规划，即可以在三维地景中添加建筑、道路、预量算平整土地面积等,为设计施工提供便捷的工具和方法。地面剖切地面剖切结果坐标量算地理量算断面量算截面积测量视域分析通视分析2.6.3.1. 工具条通过工具条中的按钮可以对地图的放大、缩小、漫游、清空等操作。表:工具栏图标图标说明鼠标在地图上将显示,可以移动地图,更改地图显示范围地图固定比例放大一级地图固定比例缩小一级通过鼠标点击在地图上量算任意两点之间的距离或多点间的累计距离，双击退出通过鼠标点击在地图上绘制任意的区域并量算其面积，双击退出清空地图上由于功能操作产生的图形要素将当前窗口中显示的地图输出,并以PNG图片形式保存通过鼠标点击在地图上面积，下方将会显示相应的表格。（与地图查询中的“面查询功能一致）随机在地图上取一点，将会在地图上显示离此点最近距离的站场及管线的点打开或关闭红线标注工具栏上传相关的附件进行空间分析点击方向图标,可以上、下、左、右四个方向移动地图；点击图标，可以实现全图操作；向“+的方向滑动，为放大地图;向“-”的方向滑动,为缩小地图。2.6.3.2. 多管线技术分析纵断面图选取有管线的面,在地图的下方将会显示纵断面图。点击纵断面图上的某一个点，显示其里程、埋深、管顶标高,且在地图上将高亮显示.2.7. 内检测数据可视化展示系统系统与PIS系统进行集成对接,提供内检测基本数据信息（如包括对缺陷点、特征点、内检测记录、开挖记录、内检测缺陷图成果的管理）的浏览、查询功能.将管道检测的缺陷数据、坐标测定数据与管道本体信息绑定便于查询、比对分析。并能够直观掌握内部制造缺陷、外部金属损失特征等检测结果的分布。2.7.1. 缺陷点浏览查询提供内检测基本数据信息的浏览、查询操作,还可以进行定位和专题图显示：缺陷点查询显示模板2.7.2. 内检测缺陷图提供内检测内部制造缺陷、外部金属损失特征的查询和展示，通过图中相应的缺陷点可以查看缺陷点的具体位置等详细信息，内检测缺陷图如下图所示：内检测缺陷分布图2.8. 第三方施工可视化系统2.8.1. 需求分析根据技术要求文件，系统需与PIS系统进行集成对接,提供第三方施工及违法活动信息的浏览、查询、统计功能。第三方施工可视化展示系统与P