某市应急响应联动防御系统项目建议书

《某市应急响应联动防御系统项目建议书》由会员分享，可在线阅读，更多相关《某市应急响应联动防御系统项目建议书（92页珍藏版）》请在装配图网上搜索。

1、昆明城市应急响应联动防御系统项目建议书翼博通讯有限公司2014年10月23日Version 0.0城市应急联动系统总体方案建议书目 录目 录i1概述12应急联动系统体系和信息化建设32.1与应急联动系统关联的部门32.2国内应急联动系统建设的现状分析32.2.1集权模式42.2.2授权模式42.2.3代理模式52.2.4协同模式52.2.5现有应急联动模式的不足62.3城市应急联动系统解决方案72.3.1结构与组织72.3.2应急联动中心运行机制93应急联动系统设计概述163.1应用系统设计原则163.1.1系统构架建设的基本要求173.1.2应用系统设计思路193.1.3总体应用架构223.

2、1.4应用系统的总体运行流程223.1.5总体技术方案243.1.6系统分解273.1.7系统软硬件部署304应急联动子系统设计324.1综合信息门户设计324.1.1概述324.1.2设计需求324.1.3综合信息门户架构设计324.1.4功能设计344.1.5核心功能描述374.2地理信息系统（GIS）394.2.1系统开发目标394.2.2系统体系结构404.2.3系统数据分析414.3运营支持系统(OSS)454.3.1需求分析454.3.2体系结构454.3.3功能设计454.3.4核心功能描述464.4决策支持系统（DSS）524.4.1决策支持系统概述524.4.2体系结构534

3、.4.3系统功能设计544.5数据交换平台574.5.1概述574.5.2数据交换平台的逻辑结构584.5.3数据交换标准594.5.4数据交换方法594.6系统监控与管理平台614.6.1概述614.6.2系统配置654.6.3监控管理684.6.4系统控制694.7安全管理平台724.7.1概述724.7.2安全管理模型724.7.3权限管理734.7.4安全检测764.7.5认证管理784.7.6密码管理804.7.7授权管理814.7.8安全报告84ii城市应急联动系统总体方案建议书1 概述随着我国城市建设的不断发展，政府对城市的综合管理也面临着极大的挑战。这尤其表现在处理地震、恶性流

4、行性疾病扩散、恐怖袭击、有害物质泄漏等重大灾害时。灾害发生前，如何根据收集到的信息进行及时有效的预警；灾害发生后，如何调动、指挥和协调各方面的资源，统一领导，快速行动，已经成为政府部门面临的重要课题。“911”事件、SARS、印度洋海啸等突发事件已经暴露出城市危机管理机制薄弱和应对突发事件能力缺乏是一个世界性的问题。而世界各国也都在积极建设自己的应急联动系统。我国的应急联动系统建设还处于起步阶段，没有固定的模式可寻。由于各个城市的规模、自然、人文以及信息化建设程度的不同，分别出现了以南宁为代表的集权模式，以北京为代表的代理模式，以广州为代表的授权模式和以扬州为代表的网络模式。这些模式各有优缺点

5、，而应用这些模式的应急联动系统在运营过程中，暴露出一些问题。这些问题具有相当的普遍性，是在我国建设应急联动系统所必须解决的问题：1. 如何在现有行政体制和应急联动中心之间取得平衡，获得最大的反应速度和协作效果，是当前应急联动系统面临的首要问题。应急联动需要整合政府现有各部门的资源，因此，如何定义应急联动中心在政府现有体系中的地位，并确立与其他部门的职、权、利关系，是保证应急联动中心有效运作的关键。2. 如何整合现有资源，建立以应急联动中心为核心的应急联动神经网络，是应急联动建设的核心问题。城市应急联动首先要实现信息联动，因此，多部门异构数据的集成是应急指挥系统设计的核心焦点。由于部门众多，相关

6、的信息系统也非常多，这就需要统一的基础信息交换平台，将不同部门的信息系统和应用系统有效地整合在一起。3. 如何保证应急联动系统的开放性、通用性和可扩展性。目前的应急联动业务范围主要涵盖公安、交通、消防、医疗急救、水电气、自然灾害、生产事故等，与以前的状态相比，已经有了巨大的进步。但是从系统设计的角度看，解决问题的思路还局限于就事论事的层面，缺乏通用的核心处理模型和开放的架构，因而系统的灵活性和可扩展性也就比较差。从发展的角度来看，当城市出现新问题或事件时，系统应当允许通过接入新的系统或模块以及调整流程来适应新的业务。4. 如何提供智能化的决策支持和知识管理，为应急指挥提供有效的支持。城市应急联

7、动中心真正的挑战不是来自大量的日常事件，而是来自少量的特殊事件，包括专业性强的事件、疑难事件、重大事故、敏感事件等。所有这些事件，要么不出现，一旦出现就很棘手。在高度紧急的情况下，指挥人员要能够对报警等突发事件、重要案件迅速地做出正确决策，需要掌握大量的事件专业知识和背景知识，如专业、地理、交通、法律法规、警力部署等。 因此，应急联动系统应具有知识管理和决策支持功能，以保证在紧急情况下，系统能够向指挥人员提供充分的相关知识支持和预案建议，避免出现重大差错。5. 如何保证系统的高可靠性。应急联动系统的任务是应急事务处理，因而系统自身的可靠性非常关键。从实践中得出，设备的可靠性并不等系统的可靠性。

8、国内在类似系统建设时，往往比较注重硬件设备的可靠性，但实践证明，这种做法带来的可靠性是不能完全解决问题的。因此，在系统可靠性设计中，还要强调软件系统的可靠性设计，即立足于事件处理流程，建立一种安全的的事务保护机制，避免形成对特定设备或环境的依赖，在系统的部分设备或环境发生故障时，出错的事务根据不同的场景进行及时转移、备份或暂时的降能处理，以保证相关事务的连续、并行处理，从而在应用级别上最大限度地保障可靠性。 6. 如何建立安全有效的监控与考核系统。指挥中心是一个关键任务处理中心，除了技术系统引发的风险之外，更多的风险还来自于人为的责任事故，因此，管理水平是指挥中心良好运作的关键因素。由于应急联

9、动中心的人员往往来自不同部门，有着各自的责任和利益，一旦出现责任事故，容易相互推诿。因此，系统设计要充分考虑到这些需求，提供充分的管理参数获取和管理手段。7. 如何实施应急联动系统的标准化工作。应急联动系统的建设和使用必将是一个长期过程。国外大型应用系统取得成功的重要因素是持续不断的技术标准化和业务标准化建设，各种标准在系统规划、系统设计、业务模型、技术选型过程中起到了强有力的引导作用，从而保证了一代一代的系统具有良好的继承性和一致性。应急联动的标准化需求体现在信息交换格式的标准化、通信协议的标准化、电子地图的标准等各个方面。标准化将方便各子系统接入应急联动平台，而系统的升级替换工作也会因此变

10、的简单易行。综上所述，应急联动系统需要达到高可用性、可扩展性、高可靠性、安全性、智能化、标准化这几个目标。本文将下下面章节中详细讨论如何设计和实现这些目标。 第31页城市应急联动系统总体方案建议书2 应急联动系统体系和信息化建设2.1 与应急联动系统关联的部门城市应急联动系统需要协调政府各职能部门的资源，统一指挥、统一行动。在我国，这些职能部门包括公安部门、消防部门、交通管理部门、医疗急救、煤气公司、自来水公司、电力部门、工商、城管等。而这些职能部门大部分已经建立有自己的应急服务系统，如公安部门的110报警电话、消防部门的119火警电话、医疗急救的120电话等。如何整合各部门已有的应急资源（包

11、括人力资源），达到充分高效的利用，是应急联动系统设计时要考虑的首要问题。应急联动系统需要建立以联动中心为核心，连接各职能部门的数据通道，集成各部门的数据和资源。保证在危机处理时：一方面，联动系统可以及时地得到全方位的实时数据，作为形成应急预案的基础；另一方面，保证联动中心发出的指令能够迅速下达到各单位，使整个行动能有条不紊地进行。图2.1 是应急联动中心和现有各政府职能部门的关系示意图。图2.1 应急联动中心关联部门示意图应急联动中心“战时”侧重于重大事件的协调、决策和监督，建立预案；“平时”则侧重于突发事件（如地震、流行性疾病传播等）的监测、预警和预案演练。作为决策和指挥者的联动中心，集成了

12、各职能部门的有效资源，应能在灾难发生前作出及时的预警，灾难发生后的第一时间作出准确的决策，在危机解除后给出合理的救援安排和任务移交计划，全方位地保护人民群众的生命和财产安全，将突发事件的损失降到最小。2.2 国内应急联动系统建设的现状分析应急联动系统的建设在国内还处于起步阶段。因此，目前还没有统一的建设模式。分析国内已建设的应急联动中心可以发现，国内应急联动中心大致可以分为四种类型：集权模式 、授权模式、代理模式、协同模式。2.2.1 集权模式集权模式是指整合政府和社会所有的应急资源，成立专门的应急联动中心，由该部门代表政府全权行使应急联动指挥大权。国内第一个建设“城市应急联动”的南宁市就采取

13、了集权模式。该模式所具有的特征包括：由政府牵头、政府投资、集中管理，应急联动中心是政府管理的一个部门，有专门的编制和预算；联动中心是城市应急事件处理的唯一中枢；政府将所有的指挥权归于联动中心，应急联动中心在处置紧急事时，有权调动政府任何部门；采取一级接警，一级处警，即指挥中心统一接警，统一处警；简单事件由专业组处理，出现重大事件时，由指挥长协调各专业联动处警；市政府不再设应急联动中心，出现重大事件时应急联动中心同时也是政府指挥中心，政府领导可以在指挥中心的市长指挥区参与指挥；应急联动中心同时也是应急指挥资源的管理中心，统一管理相关的应急指挥资源。优势：l 集权模式是国外应急指挥普遍采用的形式，

14、体现了城市应急联动的本质要求，是城市联动发展的方向。l 统一指挥、信息共享、资源共享，有利于实现快速反应、精确指挥。l 一级接警，统一了所有的报警信息入口，另外，一级接警减少了指挥层次，使指挥效率大大提高，有利于快速反应。风险：l 该模式几乎重构了城市应急体制，因而建设难度大，投资也大。l 在接警量大的情况下，一级处警没有多层次协作指挥，容易造成指挥中心负荷过重。2.2.2 授权模式授权模式是政府利用现有的应急指挥基础，根据城市应急联动的要求，通过局部的体制调整，授权应急基础比较好的某一部门，在该部门的牵头下，政府相关应急部门联动办公，联合行动，从而快速构建城市应急联动系统。授权模式所具有的特

15、征包括：政府将应急联动的指挥权授权给公安，以公安处警为核心，协同其他联动部门共同处警。在紧急情况下，公安代表政府调动各部门联合行动，并代表政府协调和监督紧急事务的处理。优势：l 授权模式充分利用现有基础，通过适当的投资和改造构建而成，见效快。l 充分利用公安、消防、交通、卫生等部门经验，能够快速构建相对成熟的应急指挥系统，指挥中心运行磨合期短、风险小。风险：l 授权难度大。授权要充分而又具体：授权不充分，关键时候指挥中心指挥不灵，就达不到应急联动的目的；同样授权不具体，指挥中心权力边界不明确，联动时容易出现不同理解，贻误战机。l 由于系统建设依赖公安等部门的基础设施，因而无法与政府内网或外网互

16、连，也就很难实现真正意义上的信息联动。l 同时，该模式也存在某些部门积极性不高，指挥困难的问题。2.2.3 代理模式代理模式是政府成立统一的接警中心或呼叫中心，负责接听城市的应急呼叫，根据呼叫的性质，将接警记录分配给一个或多个部门去处理，并根据各部门处理情况反馈报警人。本质上讲，这种模式并不是真正意义上的应急联动，只是向城市提供了统一的紧急呼叫入口。该模式所具有的特征包括：由政府牵头，统一了紧急呼叫的入口；各部门分头处警，各自指挥；负责向报警人反馈处理信息，监督各部门处理事件的过程。优势：l 解决了统一接听的问题，为统一指挥打下了基础。风险：l 首先是接警风险，不准确的接警必然导致不准确的处警

17、，因此，接警务求准确，而相应的接警系统也需要很多的专业知识沉淀。l 在跨部门事件处理时，形成统一的指挥核心还需要时间。l 另外，该模式还没有真正体现应急联动的理念，整体作战有赖于其他方式的协调。2.2.4 协同模式协同模式是多个不同类型、不同层次的指挥中心和执行机构通过网络组合在一起，按照约定的流程，分工协作、联合指挥、联合行动的一种应急联动模式。协同模式所具有的特征包括：应急联动机制是由多个不同类型、多层次有指挥系统构成。一般由一个政府指挥中心、多个部门指挥中心和更多基层远程协同终端构成。不同系统具有不同的职责。政府指挥中心战时侧重于重大事件的协调、决策和监督。部门指挥中心，如公安指挥中心、

18、交通指挥中心、消防指挥中心、急救调度中心等，则侧重于对紧急呼叫的快速反应，先期处置。基层远程协同终端系统则是部门指挥中心的远程终端，主要是网上快速接收指令、网上反馈，平时上传应急指挥的基础数据，在条件许可以情况下，可以由公安统一接警，也可以成立专门的接警部门。条件不成熟时，可以维持目前分部门接警的现状。优势：l 在协同模式下，政府指挥系统与部门指挥系统职能分明，各有重点，互不冲突。l 构建多层次的指挥网络，物理分离、逻辑集中、业务统一。l 政府的应急指挥系统是核心，通过该系统将过去多个分立的部门指挥系统整合成一体化的应急联动系统，大事政府牵头，小事部门负责。风险：l 区分重大事件和一般事件比较

19、困难。一旦某事件被确定为一般事件，则很难及时联动，容易贻误战机。2.2.5 现有应急联动模式的不足l 现有应急联动系统存在的核心问题是对政府各职能部门的整合不够，不能实现真正的应急联动。尤其是代理模式和授权模式，基本上是只能应急，不能联动，对突发事件的处理能力比较差。l 难以扩充。现有应急联动模式都没有突出可扩展性，没有一个开放的数据交换平台以及多种系统接入方式，以方便已经存在的和将来可能出现应急资源接入现有系统，升级潜力小。l 没有强调预警功能。大部分应急联动模式只强调了危机出现时如何接警和处警，而没有强调在危机发生前如何进行监控和预报，而这正是应急联动系统最重要的组成部分。如果不能对地震、

20、洪涝、恶性传染病流行进行早期的监控和预警，城市将遭受的损失将是难以估量的。l 一般事件占用应急通道。出现在集权模式、授权模式和代理模式中的一个主要问题是，接警处每日处理的非紧急事件在70%左右，也就是说，在真正的突发灾难事件发生时，很可能由于这些非紧急事件占用应急通道资源而造成战机的贻误。针对我国目前城市信息化建设的现状，以及国内已有应急联动系统存在的不足，我们建议采取如下方案。2.3 城市应急联动系统解决方案2.3.1 结构与组织如何在我国现有的行政体制下，协调各职能部门间的关系，建立一套适合应急联动协同作战需要的组织关系，是摆在城市应急联动系统设计前面的首要问题。而建立这样一个组织结构，则

21、一定要考虑如下问题：如何协调应急联动中心和各职能部门的关系，有效利用现有职能系统的应急响应系统，最大限度地整合现有资源，节约实施成本而又不减弱应急联动的效果。如果采取授权模式、代理模式和协同模式，势必造成一定程度上的只能应急，不能联动或不能及时联动。所以，联动中心的存在以及统一接警和处警是应急联动系统正常运行不可或缺的一部分。而采取集权模式实施成本又太高，而且也很难充分利用现有职能部门的应急响应系统。所以我们建议采取如图2.2所示的以应急联动中心为核心，其它职能部门现有应急系统为辅的分级管理模式。图2.2 应急联动系统组织结构示意图应急事件发生时，应急联动中心负责统一接警，统一处警，并收集处理

22、灾难必须的案件现场的所有实时信息（如：地理位置、下水管道位置等等），给出合理的应急预案，并根据案件情况，指挥调配相应的三级联动单位调度中心，要求立刻派出处理力量编组。平时监测时，各职能部门负责本部门职责内的监控和预警，一旦监控到可能发生的突发事件（如：地震、疫情爆发等），则在第一时间由系统自动通知应急联动中心，并由联动中心集合各职能部门的资源（如：天气、水文、出入境管理部门等），对可能发生的灾难进行评估和处理，给出防御预案，统一部署和协调各职能部门合作，在第一时间采取预防行动。市委市政府作为最高指挥机构，一般情况下可不进入应急联动中心。一旦发生重大应急事件，市委市政府则可直接进驻联动指挥中心，

23、利用联动中心的设备进行现场指挥和调度。该组织结构方案充分利用了现有各职能部门的应急资源，并真正意义上实现了应急联动，能够对可能出现的灾难做出快速行动，灾难发生时，又能合理配置和运用社会各部分资源，对突发事件做出及时有效地处理。在面对重大事件时，市委市政府可以在一线坐镇，负责指挥和协调，充分发挥现有行政体制的作用。应急联动中心 我们建议城市应该设立一个独立的应急联动中心。该中心作为应急事件处理的大脑中枢，应该与政府各职能部门的信息系统相连，集成城市中所有必要的信息资源，在应急事件发生时，统一指挥各职能部门的行动。 我们建议该中心应具有统一接警和同一处警功能。前期，应派驻在各职能部门应急系统中有丰

24、富工作经验的接警人员入驻（如：110，120，119接警员）。对接警员进行接警培训，设立操作规范，对不同的灾难情况，准确而全面地询问报案者相关信息，并进行分类整理，便于处警员统一处理。 我们建议该中心应具有开放性和高可扩展性。前期可只接入有接入条件的职能部门系统，一旦有新的职能部门需要加入，该中心系统能不必修改现有代码的情况下，方便地接入。 我们建议该中心应能提供智能化的决策支持和知识管理功能。可以为决策人员体统全方位的信息（如：地理信息、煤气管道信息等），协助决策人员完成应急预案和行动方案的指定。 我们建议该中心应具有高可靠性。不但提供硬件的可靠性，更要提供软件的可靠性。由于应急响应的特殊要

25、求，该中心需要实时可靠的数据传输。所有的数据必须一次传输，绝不丢失。公安指挥中心、交通指挥中心、消防指挥中心、急救调度中心等公安指挥中心、交通指挥中心、消防指挥中心、急救调度中心等三级应急联动中心应负责本中心的应急事件预警工作，并通过可靠的网络接入到应急联动中心，实时地向应急联动中心报告。三级联动单位调动中心同时负责向联动中心传送本单位的实时数据，为中心的统筹安排提供信息支持。三级联动单位负责接收联动中心的调度指令，并委派本单位的处置力量编组执行。2.3.2 应急联动中心运行机制从监测到响应：对可预测灾难的处理应急联动系统的一个重要任务就是在突发事件发生时，能够非常迅速地应对。这种突发事件不管

26、是疾病爆发，自然灾害，还是人为酿成的祸害。因此，必须具备完善预警及应急机制。这样一个完整的机制在图2.3中充分显示出来。从流程角度来看，他必须包括从监测（Detection）到响应（Response）的各个环节。而在范围上，具体包括各个功能单元：监控与监测、计划与协调、应急资源管理、沟通、超负荷能力、培训和公众意识。图 2.3：可预测灾难处理：从监测到响应与城市应急机制流程相吻合，所有这些功能属于两大类系统：应急事件监控系统（Surveillance System）和指挥与控制系统（Command and Control System）。应急时间监控系统：为减轻中心压力，降低中心建设和运营成本

27、，可考虑将现有各职能部门的相关监控预警系统和中心的应急事件监控系统相连，形成如图2.4所示的分级应急监控系统。图 2.3：分级应急监控示意图联动中心应急事件监控系统与现有职能部门的监控系统（如：地质部门的地震预测系统， 卫生局的公共卫生预警系统等）通过可靠的网络相连。一旦这些系统发现可能出现的灾难，则通过各自系统与应急事件监控系统的接口向中心自动报警，并传输与该事件相关的所有消息。联动中心一旦收到报警，将立即通知指挥与控制系统（Command and Control System），并采集调用与该事件相关的一切其它实时信息，对事件的范围、危害程度等属性进行评估，准备生成应急预案。使用分级应急监

28、控的好处如下：l 充分利用政府各职能部门已有的应急预警资源，避免重复建设，节约成本。l 充分利用现有各职能部门的专业队伍和专业知识，避免集中管理带来的不便。l 各职能部门的预警系统自己建设，自己使用，建设难度小。l 减小中心压力。职能部门平时专注各自领域的检测，只有发现可能的应急事件时，才立即向中心报告，由中心统一协调处理。l 可扩展性好。可根据城市的发展情况，接入有接入条件的职能部门的预警系统。当其它部门的相应监控系统成熟时，可直接接入，无须对现有系统做修改。l 预警信息实时地由各分管职能部门传送到联动中心，保证了应急联动的快速行动。指挥与控制系统：综合事件现场的全方位信息（包括：水电煤管道

29、的铺设位置、距离事件发生地点最近的警务人员等），在第一时间内做出相应行动决策，并通过命令人员使用的设备、沟通方式和设施指导和协调人力和运作情况。该系统必须具有以下三个特性：o 保证互连（Assured Connectivity）：状况评估与协调o 归因（Attribution）：评估与跟踪多个信息领域中的威胁o 危机协调（Crisis Coordination）：控制与压制威胁，灾难恢复图 2.4：应急指挥与控制系统的组成单元图2.4是应急指挥与控制系统的组成单元示意图。描述了可能的各项功能： 应急专业人员资源数据库 环境检测设备和报告 急救设备资源数据库 紧急通信系统 地理信息系统 应急资源

30、调度 应急物资/药物物流系统 沟通手段 数据分析与报告要实现这样一个城市应急机制，必须解决许多方面的问题： 计划与协调：我们应如何对应急事件做好准备，并确保所有应对措施能够良好地互相协调？o 加强现有的系统o 对各职能部门进行应急事件处理准备状况评估o 在监测与响应准备中采用风险管理概念o 城市各职能部门间的IT协调和数据共享 培训与公众意识：由于应急联动系统要求各职能部门联合作战，我们怎样为应急人员提供充分的协作作战培训？我们怎样向公众传达统一的信息？o 应急联动宣传/广告/公共服务通知o 模拟演习：职能、圆桌会议、互联网o 专业应急人员培训 沟通：数据、信息和告警的共享以及与最初响应人和提

31、供帮助的其它机构沟通的方法和工具？o 提供全方位的沟通工具，包括无线设备，方便指挥人员于现场技术人员的沟通。o 保证网络的可靠性，使决策需要的数据能够实时有效的被传送到中心。o 保证沟通渠道的安全性。 应急设备管理：灾难发生时，我们如何分配安排现有的应急设备和应急人员？o 地理信息系统的支持。提供事件现场全方位的具体情况。o 应急设备数据库。提供所有应急设备的当前位置和地点，并能在电子地图上显示。o 决策支持系统，提供最优的资源配置。从接警到响应：对已发生事件的处理火灾、车祸、抢劫等事件通常无法预测，一般都是相关职能部门得到市民报警后，再采取行动。由于目前城市日益庞大和复杂，这些以前由相关职能

32、部门负责的事件，已经很难由单方面行动来解决。举个简单的例子，如果某楼宇发生了火灾，而火灾是由电器着火引起的，但靠消防部门就不行了，这就需要电力部门进行区域断点。如果该楼宇是居民楼，则考虑到有天然气管道，容易引起爆炸，需要燃气公司及时关闭该楼的煤气管道。如果楼内已经有受伤的居民，还要协调急救中心和公安局进行救护和疏散。整个过程需要各部门通力合作，如果任何一环出了问题，都可能贻误战机，给人民群众的生命财产造成不可估量的损失。基于这种情况，应急联动中心一定要实现统一接警，统一处警，协调调度各职能部门进行统一行动，做到真正的应急联动。图2.5是应急中心统一接警、处警的执行流程。一旦流程到达应急联动指挥

33、控制系统端，则执行步骤与上节所述类似。图 2.5统一接警处警示意图统一接警对接警员和处警员的要求比较高。接警员应具有较高的业务素质，能够对不同的情况做出正确的处理（如：在接到市民火警时，能够准确的询问出事地点，可能的起火原因等相关情况）。这就需要制定一套严格的接警和处警规范和流程，并对相关人员进行严格的培训。图2.6是一个可能的接警流程，2.7是一个可能的处警流程。图 2.6 接警流程图 2.6 处警流程需要特别指出的是，我们建议的应急联动，既能执行平时的监控、预警工作，又能完成真正的应急联动响应。并且最大化地利用了现有的信息资源，避免了重复建设。监控/预警工作技术使用程序应急响应运作3 应急

34、联动系统设计概述3.1 应用系统设计原则我们建议应急联动系统的设计应把握如下原则：实用性区分应用需求的迫切程度，以实际应用需求为核心，保证设计功能有实际应用价值。同时系统应实现用户可接受的查询效率与响应时间，有良好的人机接口与灵活多样的展现方式。平台化鉴于城市应急联动中心未来业务的复杂性，及应急业务的不确定性，系统应建立一个开放的数据交换平台，建立多种接入方式，使其具备足够的灵活性与扩展能力。能够根据应用需求，方便扩展设备容量和提升设备性能，具备支持多种组件模块，具备技术升级、设备更新的灵活性，具备支持业务功能的扩展与重构的灵活性。安全可靠在应急场合的应用系统，其安全与可靠是至关重要的，系统设

35、计将充分考虑到系统的安全防护与冗余措施。系统提供较强的管理机制和控制手段，提供系统备份、数据恢复、事故监控和网络安全保密等技术措施。平战结合应用系统如平时的应用功能不足，使用率低将直接导致战时的应用效率低下，本设计将充分挖掘平时的功能，使其与战时功能结合，以实现平战轻松转换。全盘考虑鉴于国家应急联动中心在应用上的特殊地位，系统设计时将从横纵两个方向考虑应用系统的架构与功能。开放性将基于业界开放式标准，对系统中的网络协议、数据接口、指标体系等进行全国统一规划，为未来的系统扩展奠定基础；3.1.1 系统构架建设的基本要求根据我们对用户需求的了解和分析，我们认为本系统要解决的问题主要体现在以下几点：

36、1、实时性在应急联动中心系统中，对实时性的要求体现在两个方面：一是要求能实时地将联动中心的命令指令传达到各职能部门；二要及时整合数据、分析情况、提供全面的信息给各级领导做决定和实时管理、发布和调配资源。因为这是突发事件处理，所以系统具备在线或快速对事件的变化作出更新和修改的能力。实现实时共享数据资源。2、支持大量并发用户访问和在线处理能力应急联动中心是一个跨部门的服务中心，数据信息源于各单位也提供给相关单位。所以，系统必须具备海量数据处理能力，支持单一信息存储（OLTP）和海量并发的访问（OLAP）要求。实现提供全文信息检索服务，实现专题数据库的生成与库内检索服务。实现各种异构关系数据库资源、

37、各种文档资源、图纸文件、多媒体信息的整合和统一管理。所以系统必须具备先进的I/O功能、支持大量并发数据访问、并提供相应的并发存储保护，使系统具有支持大量各种类型并行亚秒级访问的能力，同时还能支持优先级较低的查询，运营数据存储提供很强的在线高速缓存功能、大大降低了应用与核心中枢联接的开销，适合于支持大量在线讯息交换。3、跨部门跨平台各部门原有的运行系统可以归纳为一个特点，即“分而治之，相对独立”。同一个机构可能运行多种系统多个网络，目前的运行系统多是针对特定的功能和服务进行的。以公共卫生系统为例，各级医疗行政部门、医院都有自己的系统、数据和网络管理，等等。有些部门缺乏对自己的所有的网络和业务的统

38、一管理。不同的运行系统归不同的部门管理，如病历资料在医院，医疗用品和资源数据在行政部。联动中心的系统功能须跨越网络、系统、资源等众多方面，因此不可避免地涉及到众多部门众多系统平台之间的协调。我们建议指挥中心采用以EAI技术基础产生的、又高于传统的EAI，可以实现实时数据采集、存储和分析、实时共享信息、实时掌握全国全面状态、实时作出正确反应、实时跨越部门边界的系统集成。4、决策支持和智能应用指挥中心必须为各部门单位提供数据分析和决策支持手段。中心系统从包括资源、事故、病理、病历、地理、天气等各种信息中作出形势和趋势分析，为各参与单位的运作适时提供参考。在突发事件中为各级领导提供全面的资讯分析。随

39、着中心的建立数据的质量更为重要，对实时的智能化决策和支持的要求越来越高。数据存储管理是系统的核心基础，负责存储和转送应用所使用的实时数据以及应用集成所使用的消息，提供实时数据仓库功能和管理企业当前的状态消息，从而为实时的决策支持和智能应用提供了强有力的手段，满足应急联动中心系统提出的功能要求。5、高可靠性应急联动中心系统作为城市突发事件指挥处理的运行系统，系统的无故障运行对于关键时刻和日常事务的正常运转至关重要。任何一个模块和环节的故障，都不仅会给指挥工作带来不便，而且会造成更严重的后果，使政府在公众中的形象下降和妨碍紧急事件的处理运作。中心系统不仅能够提供724高可用性，而且能够支持程序连续

40、运行（连续可用性）、提供容错、容灾和在线维护能力，满足支持各种关键任务的需要。6、可扩展性应急联动中心系统的可扩展性是与系统信息的发展趋势相对应的。随着系统的运作，积累的数据和分析标准将不断扩大，和技术和管理水平的发展，无论是信息的种类和规模，还是对运行系统的需求都体现出多样化的趋势。建议解决方案的一个主要目的就是为了解决目前各运行系统分立所造成的一系列问题，因此对系统的一个基本要求就是要避免使其成为另一个功能单一、与其他运行系统相隔绝的系统。从发展的角度看，只有具备了高度的可扩展性，才是一个有生命力的系统。对指挥中心系统来说，可扩展性包含多个方面的含义：l 能不断适应更多的信息种类；l 能适

41、应更大的功能和数据规模；l 能提供更多的运行系统功能；l 具有业界通用的标准接口，以便与其它系统进行无缝互连；l 采用模块化结构，适应不同部门的不同的功能需求。与传统的EAI相比，新系统的一个突出的特点是能够方便地增加应用数量、扩大系统资源规模、在增加工作负载的同时不降低性能。而且随着系统规模和应用数量的增加，系统的优势体现的愈加明显。其强大的可扩展性可以确保在指挥中心系统升级和功能完善的过程中，提供足够的处理能力满足系统的需求。3.1.2 应用系统设计思路突发事件应急管理(指挥)理念图3.1 突发事件应急管理(指挥)理念突发事件应急指挥与决策的整体框架城市突发事件应急方案的生成是建立在各职能

42、部门对突发事件发生地情况的实时报告的基础上，预先根据历史和现实业已存在的可能发生的类似事件为对象，制定突发事件应急预案，构成突发事件应急处理的方案集，同时制定建立知识库的规则，系统根据突发事件的级别，针对事件的类型，按图3.2所示的指挥决策整体框架结构通过会商确定执行的应急方案。由此可以看到，突发事件应急决策是通过计算机对突发事件的监控体系以及群众对突发事件的报告，采集与突发事件相关的信息，根据所管理的信息按照不同的突发事件，设计一组可供选择的应急方案，决策者通过人机对话的方式在一组可行方案中选择较佳方案作为应对突发事件的对策。图3.2突发事件应急指挥与决策的整体框架指挥中心技术实现的思路及决

43、策流程图3.3 指挥中心技术实现的思路及决策流程城市应急联动中心技术实现思路及决策过程如上图所示,从数据、信息、知识到智慧，其数据处理的目标就是要对获取的不同来源数据进行标准化与整合，形成信息，进而提供对信息的深入加工与分析形成知识，通过对知识的积累与选择形成智慧，从而协助指挥决策人员进行决策。整个决策过程通过会商来实现。突发公共卫生事件会商管理的工作流程如图3.4所示。图3.4：会商管理的工作流程应急指挥与决策的分析内容图3.5应急指挥与决策的分析内容3.1.3 总体应用架构图3.6 应用系统总体架构应用系统由“一个中心、一个门户、三个系统支撑平台、三个核心应用平台”构成。如上图所示，一个中

44、心指数据中心；一个门户指综合信息门户；三个支撑系统平台指安全管理平台、数据交换平台、系统监控与管理平台；三个核心应用平台指基础信息平台、专业服务平台和综合决策平台。3.1.4 应用系统的总体运行流程在数据中心的支持下，针对城市突发事件的管理，系统将沿预防监测、预警准备、快速反应、收尾恢复、总结提高的流程进行运行，循环反复不断提升系统的应急处理支持能力。1、预防监测联动中心在此阶段主要负责接收、分派、核实与处理事件的报告，同时负责协调与组织开展突发事件的预防与监测工作，获取动态监测、事件调查与疫情评估信息，跟踪事件发展状态。联动中心还将积极开展演习、培训与研究工作，开展应急业务模拟，提高应急处理

45、能力，积极研究完善相关政策法规、预案与方案，同时规划储备应急医疗资源等，建立突发事件的防控体系。2、预警准备根据国家法定的流程与预案，联动中心将组织专家进行事件评估，并针对评估结果发布预警信息，针对相关突发事件快速开展准备具体方案与工作细节的准备工作，落实相关预案与方案涉及工作的准备情况，同时根据流程进行通报与汇报。在此阶段重点是进行响应前的准备工作，进行动员与预热，准备应急资源，落实启动细节，同时积极控制事件的发展，采取相应的控制措施阻止事件升级。3、快速反应针对突发事件，快速启动预案，并根据预案迅速指挥与执行工作，有条不紊地组织调度人员与物资，开展应急的专业处理与相关配合工作。同时根据反馈

46、情况，动态评估事件的发展情况，根据事件情况调整措施，最大限度地减低损失。此阶段重点在于在事件暴发阶段快速启动响应程序，进入应急处理状态，同时为专家提供及时准确的数据与正确的信息，为指挥首长与指挥人员快速提供现状描述，分析预测事件发展趋势，提出参考措施。在决策形成后，迅速部署实施，跟踪落实情况，从而控制疫情或事件的蔓延，使其尽快稳定与下降。4、收尾恢复在突发事件降级或结束时，联动中心将进行事件收尾工作的处理，以尽量减少不必要的损失，同时将快速开展从应急状态恢复到正常状态的工作。一方面组织进行相关控制措施，防止事件死灰复燃，也控制其他可能的突发事件发生；另一方面将有计划地补充应急处理阶段所消耗的战

47、备资源，同时逐步恢复人们正常的生活与生产。此阶段重点在于积极主动地进行事件扫尾，提醒注意事项，同时辅助规划与补充资源，从而控制事件尽快回复正常，降低损失。5、总结提高在事件结束后，应进行科学总结，进一步完善政策法规、预案与方案，同时组织开展应急处理技术的研究与探讨，总结经验，制定针对性的防控措施与演习方案，从而提高相关事件的应急处理能力。此阶段最重要的是总结经验教训，辅助制定针对性的措施，修订与完善相关应急制度与流程，形成更有效的操作规范，从而提升处理能力。3.1.5 总体技术方案总体技术架构3.1.5.1.1 基于浏览器/服务器的三层体系结构系统在技术上要求具有业务变化的适应性、高度的安全性

48、、大容量数据存储处理等特点，引入数据仓库技术。系统利用交易中间件，将应用的业务逻辑、表示逻辑和数据分为三个不同的处理层：表示逻辑（客户层）为第一层:它的主要功能是实现用户交互和数据表示，为以后的处理收集数据，向第二层的业务逻辑请求调用核心服务处理，并显示处理结果。业务逻辑（服务器组件）为中间层:这些组件由中间件管理，实现核心业务逻辑服务并将这些服务按名字广播，管理并接受客户的服务请求，向资源管理器提交数据操作，并将处理结果返回给请求者即客户或其他服务器。数据（资源管理器）构成模型的第三层。比如关系数据库，负责管理应用系统的数据资源，完成数据操作。服务器组件在完成服务的过程中通过资源管理器存取它

49、管理的数据，或者说请求资源管理器的数据服务。在三层客户机/服务器模式上架构的应用系统不但具备了大型机系统稳定、安全和处理能力高等特性，同时拥有开放式系统成本低、可扩展性强、开发周期短等优点。交易中间件作为构造三层结构应用系统的基础平台，提供了以下两个主要功能：负责客户机和服务器间的联接和通讯提供一个三层结构的应用开发和运行平台采用三层结构的应用模型，为用分布式环境处理关键性业务提供了一个结构化的解决方案。中间件应用设计应该是从异构的计算资源中创建一个“虚拟主机”，在分布式应用系统环境下提供可管理的相互关联的资源。交易中间件提供了一个基础的框架来建立、运行和管理一个三层客户机/服务器模式的应用，

50、无需从零做起，大大缩短了应用开发的时间，提高了应用开发的成功率。在三层结构的应用模式中，表示逻辑层和资源管理器作为应用界面和数据的管理者，在传统的二层模式中有关的标准和稳定的实现，而作为三层结构核心的中间层，由于其担负“承上启下”的枢纽作用，在实际的应用系统中扮演着至关重要的角色。中间件在对事务完整性的保证、对大规模并发处理的响应、对异构系统互联的透明支持，以及对数据的安全性保护等方面表现将成为应用系统成败的决定性因素。中间件构成了三层结构的基础，可以选择成熟的商用中间件或自己搭建基础结构并开发相关功能软件。三层结构的技术采用基于J2EE模式，以IBM公司应用服务器和中间件作为系统支撑。3.1

51、.5.1.2 基于J2EE模式的技术实现的体系结构J2EE平台的构成包括： l EJB - J2EE 中间层，完成商业逻辑； l JAAS - J2EE 处理认证和授权的API; l Java Connectors - J2EE 用于连接异种数据源的API，对上层来讲是透明的; l JSP， Java Servlets - J2EE的表示层技术，用于生成用户界面; l Java Virtual Machine - Java 语言运行环境； l JDBC - J2EE数据库访问； l JMS - J2EE的异步消息队列； l JNDI - J2EE的名字查找API，独立于目录服务器； l JTS

52、 - J2EE用于处理交易的API； l RMI/IIOP - J2EE的分布式对象的通讯API，提供了和CORBA交互的能力。J2EE三层结构的系统体系结构如下图：图3.7 J2EE三层结构的系统体系结构图J2EE三层结构的技术框架如下图：图3.8 J2EE三层结构的技术框架图3.1.6 系统分解应急指挥的核心应用平台可以分解为地理信息（GIS）、决策支持（DSS）与运营支持（OSS）三个模块，在这三个模块下，包括系统管理、信息查询、值班管理、事件管理、经费管理、组织管理、物资管理、文档管理部门信息管理、人员管理等若干子系统。图3.9 系统分解图在综合信息门户的支持下，各子系统将协同工作为指

53、挥领导、专家与工作人员提供相应的服务，其中运营支持系统在操作型数据库支持下，主要完成在线操作的各种支持服务，进行流程管理等事务性操作；地理信息系统在地理数据库支持下主要提供地图服务，进行空间分析的支持；决策支持系统可在数据仓库支持下进行数据分析、在线分析与模型分析等分析服务，为决策提供不同维度与不同形式的支持服务。图3.10 子系统的服务分工子系统之间关系三个子系统的相互关系如上图所示，运营支持系统通过数据抽取、加载与转换（ETL）为决策支持提供基础数据，决策支持系统通过分析服务将结果反馈给运营支持系统；运营支持系统为地理信息系统提供动态数据，而地理信息系统则为运营支持系统提供地图服务；地理信

54、息系统通过ETL向决策支持系统提供决策所需的地理数据，同时通过空间分析服务反馈空间分析结果，而决策支持系统则为地理信息系统提供数据分析服务，反馈数据分析结果。图3.11 子系统关系图3.1.6.1.1 系统架构图图3.12 应用架构图在系统监控与管理平台及安全管理平台的支持下，系统将通过数据交换平台获取公安系统、急救中心、消防队、交警系统以及各其他系统的数据与信息，通过处理后进入数据中心。根据应用需要，数据中心将数据与信息分别部署到城市应急数据资料库、地理信息数据库与应急数据仓库。运营支持系统、地理信息系统与决策支持系统在数据中心支持下，提供相应的服务给综合信息门户，为各渠道的应用提供支持。系

55、统通过综合信息门户，综合处理内网、外网、呼叫中心、邮件、短信息等不同渠道的访问与应用，为内部工作人员与外部访问人员提供的信息统一门户，从而确保：l 系统对内对外服务渠道的畅通；l 同一身份访问者通过不同渠道访问时，系统提供一致的信息。l 通过安全、数据、服务、应用四位一体化的管理，进而实现基础信息平台、专业服务平台与综合决策平台的应用需求。3.1.7 系统软硬件部署软件系统部署图3.13 软件系统部署图硬件服务器部署图3.14 服务器硬件部署图编号：时间：2021年x月x日书山有路勤为径，学海无涯苦作舟页码：第89页 共92页4 应急联动子系统设计4.1 综合信息门户设计4.1.1 概述综合信

56、息门户（Portal）应用系统的一个重要组成部分，通过综合信息门户，将城市突发事件应急指挥与决策系统的各种应用系统、数据资源、网络资源等信息集成到一个信息管理平台之上，为指挥首长、业务专家与工作人员提供相应的服务，并以统一的用户界面提供给用户，快速的建立对公众、对内部管理人员的信息通道，使用户以统一的、个性化的、多渠道的方式访问各种信息和服务；另外，作为城市应急联动系统的统一用户界面，接收来自外界各种渠道的服务请求，通过对后台服务的调用，最终把结果依据不同的渠道以不同的表现形式响应给请求端，从而提高效率、响应性和适应能力。4.1.2 设计需求从用户角度看，系统将涉及内部用户如工作人员、专家等，

57、还涉及到外部用户如公众、其他单位与机构等；从渠道角度看，应用系统涉及外网、专网、局域网、呼叫中心、邮件、短消息等多种渠道，系统需要解决以下两个关键问题：l 如何使内部用户与外部用户采用统一的界面去访问渠道获得相同与一致的信息？l 如何使同一身份的用户通过不同渠道获得相同与一致的信息？4.1.3 综合信息门户架构设计综合信息门户是位于用户接入层，支持用户通过多种不同渠道进行信息及服务的访问，比如：内部网站、客户端、通信网关、呼叫中心等形式，并有效地整合突发所涉及的相关应用和信息，使内、外的用户可以通过单一的入口，使用多种渠道个性化地访问相关的各种类型信息。从而保障同一身份的用户从不同渠道进入系统

58、时，可获得一致的信息。图4.1.1 综合信息门户实现模型如图4.1.1所示，综合信息门户的应用系统将形成用户端、接入管理、业务逻辑层与数据存储层，在安全平台提供的身份认证服务的支持下，系统可通过不同的渠道如内部网站、客户端、通信网关、呼叫中心等形式为各种用户终端提供服务，从而保障同一身份的用户从不同渠道进入系统时，可获得统一的信息。综合信息门户的架构是面向今后发展的、具有很好的整合能力的架构，可以防止今后出现在数据、应用、用户界面层面的孤岛，实现资源的再利用。除了快速满足现有的业务系统的功能性要求的同时，还可以快速将新的应用部署到架构中来，共享架构所提供的共用服务，在架构上满足了系统的扩展性、

59、高性能、高可用性等要求。建立综合门户系统可以：l 增强各部门人员的协作能力，缩短事务处理周期，提高工作效率；l 使信息流和管理得到改善，而且拥有一致的基础设施，因此可降低运营成本；l 统一的数据和处理逻辑，支持多种渠道接入方式，统一进行展示；l 提供统一的管理平台，提高管理水平；l 由于可以访问相关性更强的信息并且可通过单一接入点访问应用和协作工具，因此可提高员工的工作效率；l 在展示层面不同应用系统间的集成及互操作性，进一步提高工作效率；l 安全性更好，并且可实现单点登录，因此可减少管理员的密码数量并改善用户体验；l 统一的显示外观和一致的用户界面可降低培训成本；l 灵活度更高，快速响应环境

60、的变化，通过门户平台技术所提供的应用与数据间的松耦合特性，为日后动态增加功能模块提供基础；l 对现有网站资源的利用和重用，保护现有投资，并实现系统的平滑扩展。4.1.4 功能设计在安全管理平台的支持下，综合信息门户将建立内部信息门户、外部信息门户以及统一接入渠道的支持。综合信息门户提供了一个统一的client端操作接口。支持多种渠道的访问模式，包括内部网站、客户端、通信网关、呼叫中心等。支持多种设备的访问，如基于HTML及WAP协议的浏览器，而不需要另一套支持WAP的逻辑。即除了可以通过台式机浏览器以外，还可以通过其它的方式访问应用门户。通过在多种标记语言中生成页面来支持移动式设备。而且支持今

61、后的访问模式的扩展。综合信息门户的内外信息与统一接入渠道支持共设计了11个模块，包括：内容与应用服务管理、智能通讯录管理、工作台管理、信息发布管理、呼叫中心管理、短信接入管理、智能邮件管理与输入输出管理、智能搜索功能、网站分析功能、定制服务功能。图4.1.2 综合信息门户的功能规划1、内容与应用服务管理综合信息门户提供了 Web 内容管理的功能，包括内容创建程序、批准和发布等等。过程中包含定义内容类型、角色、参数、规范和工作流进程。可以实现对内容与应用服务进行编辑处理，提供与维护各类便捷模板，供不同渠道与用户类型应用。l Web 站点中的内容和页面设计。 l Web 站点的框架和导航。 l W

62、eb 站点内容的创建、编辑、核准和发布过程。 l Web内容的管理使用浏览器方式，使用该工具无论是内容发布者还是内容查看者都可以通过浏览器客户端实现网站内容管理，无需在客户机上安装其他的客户端软件。2、智能通讯录管理在门户上提供了与安全中心统一用户管理系统的集成，可以对于不同的用户针对应用需求，对其通讯方式进行捆绑。3、工作台管理对内部信息门户的工作界面进行个人参数设置，在权限范围内定制自己的应用界面。4、信息发布管理通过与应急指挥网站接口，对外部访问用户进行统一管理，同时根据安全权限开放信息，提供信息查询与浏览功能，此外，还可进行内容上传与修改、界面编辑等管理。5、呼叫中心管理通过呼叫中心接

63、口，实现统一接警的综合管理，包括：电话自动录音、来电自动识别、语音播放、自动追呼、传真自动接收、报告记录等，将通讯功能与应用软件功能机结合在一起。6、短信接入管理通过短信网关，实现对短信的编辑、发送与统计分析功能，同时提供短信通知模板辅助开展应急通知、告警等工作。7、智能邮件管理通过邮件接口，实现邮件的自动识别与应答，同时提供各种工作邮件模板，完成调查、报告、通知等基础工作。8、输入输出管理通过对输入输出设备的接口，实现对其的控制与管理，实现如LED信息编辑与播放等应用。9、智能搜索功能提供集成的web内容搜索工具，包括：搜索引擎、文件索引程序和内容归类选项。搜索设备能够搜索本地文件以及互联网内容。门户搜索功能能够使用内置文件过滤器为纯文本以及其他200多种文件格式编写索引。门户服务器的内置搜索引擎优化用于全文搜索中小型文件集