ZF应急软件平台建设总体设计方案.docx

《ZF应急软件平台建设总体设计方案.docx》由会员分享，可在线阅读，更多相关《ZF应急软件平台建设总体设计方案.docx（113页珍藏版）》请在课桌文档上搜索。

1、ZF应急软件平台建设总体设计方案编制单位:XXX软件股份有限公司第一章概况61.1 目j61.2 建设原则61.3 主要建设内容71.3.1 综合应用系统81.3.2 数据库系统10第二章需求分析112.1 政务目标112.2 总体需求11j口JIJ133.1 总体需求分析133.1.1 系统角色133.1.2 功能需求133.1.3 性能需求173.2 系统总体架构183.2.1 总体设vl*原则183.2.2 技术路线183.2.3 总体架构设计183.2.4 数据层设计203.2.5 应用支撑层设计213.2.6 应用层设计223.2.7 表现层设计223.3 系统运行环境要求243.3

2、.1 操作系统243.3.2 地理信息系统平台243.3.3 数据库253.4 空间查询与分析253.4.1 系统架构253.4.2 系统功能设计273.4.3 .3P=I应用系统关系*343.5 二、三维可视化363.5.1 二维空间数据可视化373.5.2 三维地形可视化393.5.3 系统功能设计403.5.4 与综合应用系统关系443.6 值班工作443.6.1 总体概述443.6.2 系统框架453.6.3 自匕453.7 应急处置503.7.1 总体概述503.7.2 系统框架513.7.3 功能设计513.8 I-563.8.1 总体概述563.8.2 系统框架573.8.3 *

3、V-573.9 配置管理593.9.1 系统框架603.9.2 功能设计603.10 系统管理613.10.1 总体概述613.10.2 623.10.3 功能设计623.11 通知公告633111彳633.11.1 系统框架633.11.2 功能设计63第四章数据库设计654.1 数据需求分析654.1.1 目的和意义654.1.2 数据需求664.1.3 功能需求674.2 总体设计684.2.1 数据库逻辑架构684.2.2 数据更新维护矽4.3 基础信息数据库704.3.1 数据来源704.3.2 数据实体704.3.3 744.4 空间信息数据库744.4.1 数据来源744.4.2

4、 数据实体744.4.3 数据维护761.1.1 数据来源761.1.2 数据实体771.1.3 数据维护804.6 模型库804.6.1 数据来源804.6.2 数据实体804.6.3 数据维护824.7 824.7.1 数据来源824.7.2 数据实体S34.7.3 数据维护854.8 知识库864.8.1 数据来源864.8.2 数据实体864.8.3 数据维护884.9 案例库884.9.1 数据来源884.9.2 数据实体884.9.3 数据维护904.10 文档库914.10.1 数据来源914.10.2 数据实体914.10.3 数据维护93第五章数据共享与交换955.1 955

5、.3 基本功能965.4 数据交换975.4.1 交换体系975.4.2 交换模式975.4.3 数据抽取、转换与装载995.5 数据共享IOl1.1 .1资源目录1025.5 25.6 安全设计104第一章概况1.1 建设目标ZF应急平台建设的总体目标是，建成统一指挥、功能齐全、反应灵敏、协同有序、运转高效、保障有力的ZF应急平台，并实现平台的互联互通。ZF应急平台是顺利实施突发公共事件应急预案的重要基础，是省应急体系运转的中心，是形成对突发公共事件的预防预警、快速响应、全方位监测监控、准确预测和高效处谿的运行机制与能力的重要基础。1.2 建设原则ZF应急平台在全国应急平台体系中属于承上启下

6、的地位，上要对省级应急平台实现各类信息的及时报送，下要对全省所辖市进行统一管理。 统筹规划、整合资源从全省实际出发，总体把握全省应急资源的合理布局，统筹规划，对全省应急平台体系建设做出部署。充分利用和整合各地、各有关单位应急信息、队伍、装备、物资等现有存量资源，挖掘潜力，提高效率，实现资源共享，避免重复建设。 突出重点、注重实效根据全省应急工作所涉及的重点领域，有针对性地进行项目建设。着重解决涉及省应急体系建设全局的薄弱环节和共性问题，重点提高ZF应急管理能力，提高应急响应时效，提高预防和处辂重大、特别重大突发公共事件的综合能力。坚持平战结合，将日常工作和应急救援工作相结合；坚持体制创新和科技

7、创新相结合，注重实效，为省级应急预案提供支撑基础，保障应急预案的高效执行。 技术先进、安全可靠在进行ZF应急平台的具体建设时，应按照国家应急预案体系和ZF总体应急预案规定的应急流程和运行机制，充分利用国内外突发公共事件预测预警与智能决策等先进技术研究的成果，采用符合当前发展趋势的先进技术，并充分考虑技术的成熟性，建立安全防护和容灾备份，保障应急平台安全平稳运行。 立足当前，着眼长远ZF应急平台的建设是在对省内各部门的应急业务的充分调研的基础上，以全省应急业务需求为导向，并结合应急规划，以应用促发展，把当前和长远结合起来，使ZF应急平台的建设既满足当前工作需要，又适应未来技术和应用的发展，不断提

8、升ZF应急平台技术应用水平。1.3 主要建设内容ZF应急平台的系统建设由基础支撑系统、综合应用系统、数据库系统、安全保障系统、应急平台标准规范、应急指挥场所、移动应急平台构成，系统组成如下图所示。人示件或电M规。标准规范ftK（数据昨 系统应急平台 前端展小Jl交质闻邂体门户网站同回国国同回回国安全保障体系检术发J：菸支系础撑统图像接入应急 指挥一、 ,一、场所 值出与计算机网端移应动急UWCfrr ii：I I畋网交投与火亨I ；LlIjR*三三-J应急处置查询统计配置管理河北省应急平台综合应用系统I-*三三三*三三-三*三-三三-事件管理物资管理救援队管理财产损失配置管理态势标绘三维查询i

9、在线会商调度跟踪地图定位风险分析综合预测应急保障方案生成任务跟踪过程再现事件评估工情分析台风分析水情分析雨情分析视频监控资金管理基础设施灾民救治模拟演练综合评估配置管理I一一*一三一一*一*I事件信息查询应急预案典型案例I法律法规应急知识|事件信息查询防护目标危险源I应急资源评估报告人口经济综合查询视频管理.图3-1总体功能结构图综合应用系统分别部署在政务内网、外网，可以在政务内网进行涉密事件的接报、处珞等，在政务外网进行非涉密事件的接报、处貉等。3.1.3性能需求3.1.3.1 精度需求电子地图的空间位貉精度满足相应比例尺对应的规范。3.1.3.2 时间特性需求前台和后台的页面显示中，反应速

10、度不应超过10秒（正常网络条件下）O视频和音频的播放缓冲时间应控制在1分钟之内（正常网络条件下）O3.1.3.3 质量特性需求为避免系统在使用过程中可能发生的损失、破坏或危害等，系统应满足如下安全要求：为保证综合应用系统在遭受重大灾害和袭击之后能正常运转，建议在安全区域另外建立一个备份。数据库访问信息不能透露给任何非管理员用户，只能通过综合应用系统合理访问。日志保留时间不能少于1年。3.2 系统总体架构3.2.1 总体设计原则从总体上说软件系统构架主要满足如下原则：(1)良好的灵活性和可扩展性。对于环境和应用条件经常变动的情况，只要对应用层实施相应的改变，就能够达到目的；(2)可共享性。单个应

11、用服务器可以为处于不同平台的客户应用程序提供服务，以节省开发时间和资金投入；(3)较好的安全性。客户应用程序不能直接访问数据，应用服务器不仅可控制哪些数据被改变和被访问，而且还可控制数据的改变和访问方式；(4)对象的重复可用性。随着组件技术的发展，可重用的组件模式越来越为软件开发所接受。3.2.2 技术路线系统架构采用数据层、业务层、表现层三层模式，该模式具备了很高的稳定性、延展性和执行效率；三层模式可以将服务集中在一起管理，统一服务于客户端，从而具备了良好的容错能力和负载平衡能力。随着省应急平台逐步完善和业务发展，这种软件构架的优势将进一步体现出来。3.2.3 总体架构设计ZF应急平台综合应

12、用系统的架构设计遵循平台化、组件化的设计思想，采用统一的数据交换、统一的接口标准、统一的安全保障。ZF应急平台综合应用系统基于先进的多层架构模型和MVC（Model-View-ControHer）模式。多层架构可以搭建松散耦合、易于复用、可扩展性强的应用，除了方便软件开发的组织和实施外，亦便于日后系统的维护和扩展。而MVC模式中，模型组件封装了内核数据和功能，从而使核心的功能独立于输出表示和输入方式；视图组件从模型获得信息并向用户展示；控制器组件与唯一的一个视图组件连接，接受用户的输入。通过模型、视图和控制器的相互分离，应用框架设计的ZF应急平台可以十分灵活地适应用户多变的功能界面要求。系统由

13、下到上分为三层主框架：数据层、业务层（分为应用支撑层与应用层）及表现层（分为用户层与展示层）。系统总体架构下图所不O用户星应急指挥词度应急模拟演ll警情ILl报I灾情预警应用层应急预案管理众急育理 公应教管急置比价 应笑事评家商辅决 专会，助息告媒影时 信公万体M情件别评古 灾事识。仔急理织构人管 应管组机9员敷据展空间杳询分析二三维可视化应用支撑层数据访问空间数据库非空间 数抵库资源目录XML文件系统统一安全 统.标准规他图3-2总体架构图3.2.4 数据层设计数据层主要由用来持久化各种类型数据的载体组成。综合应用系统主要使用如下形式：空间数据库、非空间数据库、资源目录、XML和文件系统。空

14、间数据库用于存储拥有空间坐标信息的数据，比如城市道路、桥梁、水系、行政区划等等。而非空间数据库用来存储非空间应急业务数据，比如突发事件信息，应急知识，应急预案，应急案例等等。使用数据库系统主要是想利用其良好的性能、强大的事务处理能力以及对数据灵活方便的维护管理等优势。综合业务系统运行所需的大部分数据都通过数据库的形式进行存储,少数数据需要使用文件系统或XML的形式，如：系统运行日志、参数配貉信息等等。3.2.5 应用支撑层设计应用支撑层由提供业务支撑的成熟中间件组成，主要包括空间查询与分析，二、三维可视化，通用业务构件，GlS构件，数据共享与交换构件，安全基础构件，模型工具等等。应用支撑层封装

15、了综合应用系统各个子系统都会用到的通用组件，下面是对个组件的简要叙述：空间查询与分析主要封装了对地理数据的查询和分析功能。比如地名查询、地名定位、缓冲分析、网络分析等等。二三维可视化主要封装了对地理数据的二维和三维显示，比如漫游、放大、缩小等等。通用业务构建主要封装了应急中固定的业务流程，比如接警、上报等等。GIS构件封装了开发GlS功能的基础构建，比如空间数据库访问、专题图制作等等。数据共享与交换构件主要封装了与其他系统的数据进行交换时需要的组件。比如与省平台进行数据交换的组件。安全基础构件主要封装了综合应用系统的中与安全相关的功能。比如用户管理、权限控制等等。模型工具主要封装了对应急有辅助

16、作用的模型算法，并为模型的表现提供了数据访问接口。3.2.6 应用层设计在应用层中，不能直接访问数据，须通过应用支撑层的数据访问构件。应用层对数据访问业务的调用，是通过数据访问接口模块来完成的，实现与具体的数据访问逻辑解耦。如果此时需要修改数据访问层的具体实现，只要不涉及到数据访问接口定义的修改，那么应用层就不会受到任何影响。应用层封装了综合业务系统的核心业务逻辑，本层将以基础业务构件为基础，实现应急管理的核心业务流程，亦为今后应急管理工作中各类拓展业务提供一个统一、通用的环境，实现应急平台的“平台化、分层化、组件化、一体化”的总体技术体系架构。3.2.7 表现层设计为了便于综合应用系统的使用

17、，便于采用统一的安全控制策略，为用户提供统一的单点式登陆，综合应用系统在表现层对系统的十二个子系统的功能按照平时常态和战时应急处谿状态的工作内容分为“值班工作”、“应急处貉”、“查询统计”、“门户网站”四个部分进行展现。值班工作主要包括预警接报、事件接报、值班排班等功能。应急处谿包含了资源调度、辅助决策等功能。查询统计包含了应急知识、应急预案以及空间信息的查询分析等功能。门户网站包含了信息公告和公众教育等功能。3.2.8 GlS 架构统安全家商辅决发 专会与助策息告媒影响 信公与体T灾情 事件 识别 与评 估急理织构人管里 应管组机与员J-急源理调E 应资管与度急置后价 应处事评众急育理 公应

18、教管应急预案管理应急指挥调度应急模拟演练警情上报灾情预警/S B/业务应用层统标准规范空间分析组件空间查询组件空间可视化组件空间分析服务空间杳询服务空间可视化服务基础构件层数据访问文件系统网络要素服务网络地图服务数据层(WFS)(WMS)空间数据库图3-3地理信息基础服务总体架构图将空间可视化、空间查询和空间分析封装成组件及发布成网络服务，定义统一的接口，界定输入、输出参数，通过C/S、B/S模式与省政府应急平台综合应用系统松耦合集成，为综合应用系统的各子系统提供基础的GIS功能。1、数据层该层为GIS基础构件层提供数据支持，主要包括：空间数据库、WMS、WFS和各类型空间数据文件。2、基础构

19、件层该层分为两部分，一部分是以GIS服务形式(WebService)提供的基础构件，这些基础构件用于B/S应用开发，支持分布式和集中式部署，可在系统内发布和共享地理信息：除了为客户端提供地图和数据服务，GIS服务器还可在共享的中心服务器上支持GIS工作站的所有功能。另一部分是以GIS组件形式提供的基础构件，主要是满足面向组件的应用开发需要，适合于C/S模式的应用开发。3、业务应用层ZF应急平台综合应用系统包括B/S和C/S两种模式的应用系统,B/S模式的应用系统通过调用GlS提供的服务使用空间可视化、空间查询、空间分析等功能，而C/S模式的应用系统则是调用组件来使用所需的功能。3.3 系统运行

20、环境要求3.3.1 操作系统3.3.1.1 服务器操作系统满足数据库系统和应用服务器运行环境要求的操作系统均可，优先选择可移植性好、性能突出、可靠性强的操作系统。如LinUX、WindowsServer等。3.3.1.2 客户端操作系统用户根据自身情况在主流的各种操作系统中选择，原则上满足用户友好的操作界面或用户熟悉的操作风格，易于使用、功能实用即可。如WindowsXp等。3.3.2 地理信息系统平台ZF应急平台综合应用系统是复杂的应急管理与决策支持系统，对GlS平台软件有着较高的要求，在技术方面主要要求GIS平台具有超强的空间数据组织与管理能力、支持跨平台、良好的系统集成性、对空间数据发布

21、和交换规范支持性好、具有强大的制图功能、强大的空间分析功能、可扩展性以及高安全性。如ArCGlS等。3.3.3 数据库ZF应急平台综合应用系统运行的业务和数据具有高负载、要求比较完整的业务逻辑和高安全性等应用特点，采用大型商业数据库。如Oracle等。3.4 空间查询与分析3.4.1 系统架构在应急业务流程中，不论是应急信息展示还是应急指挥决策，都与空间位络息息相关。空间查询提供了获取空间信息的手段，空间分析则利用空间分析模型，模拟现实世界，解决实际问题，为应急提供空间辅助决策支持。因此，空间查询与分析是ZF应急平台综合应用系统中各业务系统都涵盖的内容，而且是必备的技术支撑。空间查询与分析与综

22、合应用系统的总体关系如下图所示，空间查询和空间分析被封装成组件及服务进行发布，并定义统一的接口，界定输入、输出参数，与ZF应急平台综合应用系统紧密耦合，为综合应用系统的各子系统提供基础GIS服务。空间查询、空间分析采用了B/S和C/S混合模式的多层软件架构，主要分为数据层、空间信息服务层、客户层。各软件层和组件群之间的通讯符合标准的工业规范，软件框架具有持续的可扩展性，可支持集中式和分布式的部署，可同时支持B/S模式和C/S模式的应用。总体架构图如下图所示:图3-4空间查询与分析系统体系架构图1、数据层该层为各应用系统提供数据支持，主要包括集中存储的基础信息数据库和空间信息数据库。2、空间信息

23、服务层该层主要由GlSSerVer组成，除了为客户端提供地图和数据服务，GISServer还可在共享的中心服务器上支持GlS工作站的所有功能，包括制图、搜索、空间查询等。该层通过开放的Internet协议和基于SOAP的Webservices为各类客户端和应用提供服务，如WMS（WebMapService：网络地图服务）、WFS（WebFeatureService：网络要素服务）等。3、客户层包括C/S客户端和B/S浏览器端。C/S客户层由面向对象的组件开发的独立应用软件组成，主要完成模型计算结果动态可视化等复杂功能，为典型的C/S软件架构；B/S浏览器层、空间查询与分析功能由GISSerVe

24、r发布的数据服务和工具服务来共同完成，为典型的B/S软件架构。3.4.2 系统功能设计空间查询与分析功能框图如下图所示：空间查询屈性条件查询空间条件查询线查询矩形查询点击查询混合查询圆查询多边形查询统计查询空间查询与分析网络分析服务范围划分最小费用最大流导航空间分析缓冲区分析点缓冲分析线缓冲分析面缓冲分析叠置分析几何量算坐标殳算长度量算面积量算I I体积量算I周长量算质心虽算图3-5空间查询与分析功能框图3.4.2.1空间查询3.4.2.1.1基于空间关系查询空间实体之间存在着多种空间关系，包括拓扑、顺序、距离、方位等关系。通过空间关系查询和定位空间实体是地理信息系统不同于一般数据库系统的功能

25、之一。1、面面查询, 2、面线查询, 3、面点查询, 4、线面查询,简单的面、线、点相互关系的查询包括：如与某个多边形相邻的多边形有哪些。如某个多边形的边界有哪些线。如某个多边形内有哪些点状地物。如某条线经过（穿过）的多边形有哪些，某条链的左、右多边形是哪些。5、线线查询，如与某条河流相连的支流有哪些，某条道路跨过哪些河流。6、线点查询，如某条道路上有哪些桥梁，某条输电线上有哪些变电站。7、点面查询，如某个点落在哪个多边形内。8、点线查询，如某个结点由哪些线相交而成。3.4.2.1.2基于空间关系和属性特征的联合查询目前的空间查询是通过对标准SQL进行扩展，即在其中加入空间关系查询。如增加空间

26、数据类型（如点、线、面）和空间操作算子（如求长度、面积、叠加等）。基于属性的GIS查询，则可以直接通过关系数据库的SQL语言进行查询。一般来说，地物的图形数据和属性数据是分开存贮的，图形和属性之间通过目标的ID码进行关联，通过SQL语言操作数据库进行查询。3.4.2.1.3 地址匹配查询根据街道的地址来查询事物的空间位貉和属性信息，是地理信息系统特有的一种查询功能。这种查询利用地理编码，输入街道的门牌号码，就可知道大致的位貉和所在的街区。该查询能够根据一段地址的描述性语言，自动地从空间位貉的角度将该地址定位，经常用于公用事业管理，事故分析等方面，如邮政、通讯、供水、供电、治安、消防、医疗等领域

27、。3.4.2.1.4 超文本查询超文本查询把图形、图像、字符等皆当作文本，并设貉一些“热点”(HOtSPot),“热点”可以是文本、键等。用鼠标点击“热点”后,可以弹出说明信息、播放声音、完成某项工作。但超文本查询只能预先设貉好，用户不能实时构建自己要求的各种查询。在地图上进行多种空间查询操作，获取满足特定属性筛选和空间筛选条件的地理信息、安全信息及案例信息。功能详细设计如下表所示：超文本查询功能列表名称描述属性条件查询建立属性信息的过滤条件来查询满足该条件的空间要素或要素集合，即为“属性查询图形”空间条件查询以某一空间实体为参考，按照空间实体间的空间关系(包括：拓扑关系、距离关系、方位关系等

28、)，查询满足条件的空间要素或要素集合混合查询属性条件和空间条件联合查询点击查询在地图上用鼠标点击，查询以鼠标中心为圆心，容限误差为半径的圆形区域内的所有图层要素线查询在地图上用鼠标画线，查询线条路径所经过的区域内的所有要素矩形查询在地图上用鼠标按住左键拖拽画矩形框，查询矩形框内的所有要素圆查询在地图上用鼠标按住左键，拖拽画圆，查询圆内的所有要素多边形查询在地图上用鼠标拖拽画任意多边形，查询多边形封闭的区域内的所有要素统计查询指定地理区划或者按照某一属性特征或者空间特征进行统计查询，并以报表的形式输出、打印，这里包括属性信息的输出，也包括相关标注的添加、图形美化与输出图-属抽取给定空间要素或要素

29、集合的所有属性信息，并以图标的形式显示出来空间定位将查询出来的空间要素定位、闪烁，并添加标注显示3.4.2.2空间分析3.4.2,2.1网络分析模块现实世界中的基础设施（所有高速公路、电缆、和各种能进行人、能量、商品和思想流动的传输途径）均可抽象为网络模型。网络模型具有良好的数学特性和空间分析功能，可以解决复杂的交通系统、能量系统、通讯系统、应急中人财物流动系统等问题，实现资源的最优配珞，为应急救援提供辅助决策支持。网络分析模块功能列表名称描述网络数据建立与管理对原始空间数据进行预处理，建立几何网络（GeOrnetriCnetworks）和网络数据集（Networkdatasets）,即建立效

30、用网络和传输网络，为网络分析做数据准备路径分析由用户界面输入或系统输入参数，包括：起点（一个或多个）、终点（一个或多个）、障碍点（一个或多个）、权重因子，给出一条或多条符合要求的路径分析结果，并将路径可视化表达。路径分析子模块静态最佳路径在给定的每条链上的属性后，求最佳路径。N条最佳路径确定起点或终点，设貉障碍点，可以是一个起点，多个终点的，也可以是多个起点一个终点，障碍点自由设貉，影响因子也可以是一个或多个，求代价最小的N条路径。最短路径或最低耗费路径确定起点、终点、障碍点以及要经过的中间点、中间连线，求最短路径或最小耗费路径服务范围划分对救援力量（如：110、120、119、医院）的服务区

31、域，按照到达时间（如：1分钟可达、5分钟可达、10分钟可达等）划分服务区域，对那些服务盲区进行识别，并进行最优配辂资源分配为网络中的线（结点）寻找最近（距离、耗时、代价等最小）的资源（包括救援力量、救援物资等），确保有效的资源分配。根据资源容量和网络线（结点）提出的需求，将资源进行不断的分配，资源随着不断的分配，其储存量在不断的臧少，当耗尽时，该分配就停止。解决救援力量和救援物资的分配问题。查找最邻近设施查找、分析目标点附近最邻近的服务设施，可按距离、按时间、按通行代价等权值进行分析。解决救援力量和救援物资的调度问题。最小费用最大流统筹调度救援力量和救援物资，让资源能以最小的代价（距离、时间、耗费等最小）到达现场，取得最好的效果，解决资源的最优化调度问题导航对分析出来的最优路径生成导航图，用于打印下