市应急响应联动防御系统项目建议书模板.doc

昆明城市应急响应联动防御系统项目提议书

翼博通讯
10月23日
Version 0.0

目 录
目 录 i
1 概述 1
2 应急联动系统体系和信息化建设 3
2.1 和应急联动系统关联部门 3
2.2 中国应急联动系统建设现实状况分析 3
2.2.1 集权模式 4
2.2.2 授权模式 4
2.2.3 代理模式 5
2.2.4 协同模式 5
2.2.5 现有应急联动模式不足 6
2.3 城市应急联动系统处理方案 7
2.3.1 结构和组织 7
2.3.2 应急联动中心运行机制 9
3 应急联动系统设计概述 16
3.1 应用系统设计标准 16
3.1.1 系统构架建设基础要求 17
3.1.2 应用系统设计思绪 19
3.1.3 总体应用架构 22
3.1.4 应用系统总体运行步骤 22
3.1.5 总体技术方案 24
3.1.6 系统分解 27
3.1.7 系统软硬件布署 30
4 应急联动子系统设计 32
4.1 综合信息门户设计 32
4.1.1 概述 32
4.1.2 设计需求 32
4.1.3 综合信息门户架构设计 32
4.1.4 功效设计 34
4.1.5 关键功效描述 37
4.2 地理信息系统（GIS） 39
4.2.1 系统开发目标 39
4.2.2 系统体系结构 40
4.2.3 系统数据分析 41
4.3 运行支持系统(OSS) 45
4.3.1 需求分析 45
4.3.2 体系结构 45
4.3.3 功效设计 45
4.3.4 关键功效描述 46
4.4 决议支持系统（DSS） 52
4.4.1 决议支持系统概述 52
4.4.2 体系结构 53
4.4.3 系统功效设计 54
4.5 数据交换平台 57
4.5.1 概述 57
4.5.2 数据交换平台逻辑结构 58
4.5.3 数据交换标准 59
4.5.4 数据交换方法 59
4.6 系统监控和管理平台 61
4.6.1 概述 61
4.6.2 系统配置 65
4.6.3 监控管理 68
4.6.4 系统控制 69
4.7 安全管理平台 72
4.7.1 概述 72
4.7.2 安全管理模型 72
4.7.3 权限管理 73
4.7.4 安全检测 76
4.7.5 认证管理 78
4.7.6 密码管理 80
4.7.7 授权管理 81
4.7.8 安全汇报 84

1 概述
伴随中国城市建设不停发展，政府对城市综合管理也面临着极大挑战。这尤其表现在处理地震、恶性流行性疾病扩散、恐怖攻击、有害物质泄漏等重大灾难时。灾难发生前，怎样依据搜集到信息进行立即有效预警；灾难发生后，怎样调动、指挥和协调各方面资源，统一领导，快速行动，已经成为政府部门面临关键课题。“911”事件、SARS、印度洋海啸等突发事件已经暴露出城市危机管理机制微弱和应对突发事件能力缺乏是一个世界性问题。而世界各国也全部在主动建设自己应急联动系统。
中国应急联动系统建设还处于起步阶段，没有固定模式可寻。因为各个城市规模、自然、人文和信息化建设程度不一样，分别出现了以南宁为代表集权模式，以北京为代表代理模式，以广州为代表授权模式和以扬州为代表网络模式。这些模式各有优缺点，而应用这些模式应急联动系统在运行过程中，暴露出部分问题。这些问题含有相当普遍性，是在中国建设应急联动系统所必需处理问题：
1. 怎样在现有行政体制和应急联动中心之间取得平衡，取得最大反应速度和协作效果，是目前应急联动系统面临首要问题。应急联动需要整合政府现有各部门资源，所以，怎样定义应急联动中心在政府现有体系中地位，并确立和其它部门职、权、利关系，是确保应急联动中心有效运作关键。
2. 怎样整合现有资源，建立以应急联动中心为关键应急联动神经网络，是应急联动建设关键问题。城市应急联动首先要实现信息联动，所以，多部门异构数据集成是应急指挥系统设计关键焦点。因为部门众多，相关信息系统也很多，这就需要统一基础信息交换平台，将不一样部门信息系统和应用系统有效地整合在一起。
3. 怎样确保应急联动系统开放性、通用性和可扩展性。现在应急联动业务范围关键涵盖公安、交通、消防、医疗抢救、水电气、自然灾难、生产事故等，和以前状态相比，已经有了巨大进步。不过从系统设计角度看，处理问题思绪还局限于就事论事层面，缺乏通用关键处理模型和开放架构，所以系统灵活性和可扩展性也就比较差。从发展角度来看，当城市出现新问题或事件时，系统应该许可经过接入新系统或模块和调整步骤来适应新业务。
4. 怎样提供智能化决议支持和知识管理，为应急指挥提供有效支持。城市应急联动中心真正挑战不是来自大量日常事件，而是来自少许特殊事件，包含专业性强事件、疑难事件、重大事故、敏感事件等。全部这些事件，要么不出现，一旦出现就很棘手。在高度紧急情况下，指挥人员要能够对报警等突发事件、关键案件快速地做出正确决议，需要掌握大量事件专业知识和背景知识，如专业、地理、交通、法律法规、警力布署等。 所以，应急联动系统应含有知识管理和决议支持功效，以确保在紧急情况下，系统能够向指挥人员提供充足相关知识支持和预案提议，避免出现重大差错。
5. 怎样确保系统高可靠性。应急联动系统任务是应急事务处理，所以系统本身可靠性很关键。从实践中得出，设备可靠性并不等系统可靠性。中国在类似系统建设时，往往比较重视硬件设备可靠性，但实践证实，这种做法带来可靠性是不能完全处理问题。所以，在系统可靠性设计中，还要强调软件系统可靠性设计，即立足于事件处理步骤，建立一个安全事务保护机制，避免形成对特定设备或环境依靠，在系统部分设备或环境发生故障时，犯错事务依据不一样场景进行立即转移、备份或临时降能处理，以确保相关事务连续、并行处理，从而在应用等级上最大程度地保障可靠性。
6. 怎样建立安全有效监控和考评系统。指挥中心是一个关键任务处理中心，除了技术系统引发风险之外，更多风险还来自于人为责任事故，所以，管理水平是指挥中心良好运作关键原因。因为应急联动中心人员往往来自不一样部门，有着各自责任和利益，一旦出现责任事故，轻易相互推诿。所以，系统设计要充足考虑到这些需求，提供充足管理参数获取和管理手段。
7. 怎样实施应急联动系统标准化工作。应急联动系统建设和使用必将是一个长久过程。国外大型应用系统取得成功关键原因是连续不停技术标准化和业务标准化建设，多种标准在系统计划、系统设计、业务模型、技术选型过程中起到了强有力引导作用，从而确保了一代一代系统含有良好继承性和一致性。应急联动标准化需求表现在信息交换格式标准化、通信协议标准化、电子地图标准等各个方面。标准化将方便各子系统接入应急联动平台，而系统升级替换工作也会所以变简单易行。
总而言之，应急联动系统需要达成高可用性、可扩展性、高可靠性、安全性、智能化、标准化这多个目标。本文将下下面章节中具体讨论怎样设计和实现这些目标。
2 应急联动系统体系和信息化建设
2.1 和应急联动系统关联部门
城市应急联动系统需要协调政府各职能部门资源，统一指挥、统一行动。在中国，这些职能部门包含公安部门、消防部门、交通管理部门、医疗抢救、煤气企业、自来水企业、电力部门、工商、城管等。而这些职能部门大部分已经建立有自己应急服务系统，如公安部门110报警电话、消防部门119火警电话、医疗抢救120电话等。怎样整合各部门已经有应急资源（包含人力资源），达成充足高效利用，是应急联动系统设计时要考虑首要问题。
应急联动系统需要建立以联动中心为关键，连接各职能部门数据通道，集成各部门数据和资源。确保在危机处理时：首先，联动系统能够立即地得到全方位实时数据，作为形成应急预案基础；其次，确保联动中心发出指令能够快速下达成各单位，使整个行动能有条不紊地进行。图2.1 是应急联动中心和现有各政府职能部门关系示意图。

图2.1 应急联动中心关联部门示意图
应急联动中心“战时”侧重于重大事件协调、决议和监督，建立预案；“平时”则侧重于突发事件（如地震、流行性疾病传输等）监测、预警和预案演练。作为决议和指挥者联动中心，集成了各职能部门有效资源，应能在灾难发生前作出立即预警，灾难发生后第一时间作出正确决议，在危机解除后给出合理救援安排和任务移交计划，全方位地保护人民群众生命和财产安全，将突发事件损失降到最小。
2.2 中国应急联动系统建设现实状况分析
应急联动系统建设在中国还处于起步阶段。所以，现在还没有统一建设模式。分析中国已建设应急联动中心能够发觉，中国应急联动中心大致能够分为四种类型：集权模式 、授权模式、代理模式、协同模式。
2.2.1 集权模式
集权模式是指整合政府和社会全部应急资源，成立专门应急联动中心，由该部门代表政府全权行使应急联动指挥大权。中国第一个建设“城市应急联动”南宁市就采取了集权模式。该模式所含有特征包含：由政府牵头、政府投资、集中管理，应急联动中心是政府管理一个部门，有专门编制和预算；联动中心是城市应急事件处理唯一中枢；政府将全部指挥权归于联动中心，应急联动中心在处理紧急事时，有权调动政府任何部门；采取一级接警，一级处警，即指挥中心统一接警，统一处警；简单事件由专业组处理，出现重大事件时，由指挥长协调各专业联动处警；市政府不再设应急联动中心，出现重大事件时应急联动中心同时也是政府指挥中心，政府领导能够在指挥中心市长指挥区参与指挥；应急联动中心同时也是应急指挥资源管理中心，统一管理相关应急指挥资源。
优势：
l 集权模式是国外应急指挥普遍采取形式，表现了城市应急联动本质要求，是城市联动发展方向。
l 统一指挥、信息共享、资源共享，有利于实现快速反应、正确指挥。
l 一级接警，统一了全部报警信息入口，另外，一级接警降低了指挥层次，使指挥效率大大提升，有利于快速反应。
风险：
l 该模式几乎重构了城市应急体制，所以建设难度大，投资也大。
l 在接警量大情况下，一级处警没有多层次协作指挥，轻易造成指挥中心负荷过重。
2.2.2 授权模式
授权模式是政府利用现有应急指挥基础，依据城市应急联动要求，经过局部体制调整，授权应急基础比很好某一部门，在该部门牵头下，政府相关应急部门联动办公，联合行动，从而快速构建城市应急联动系统。
授权模式所含有特征包含：政府将应急联动指挥权授权给公安，以公安处警为关键，协同其它联动部门共同处警。在紧急情况下，公安代表政府调动各部门联合行动，并代表政府协调和监督紧急事务处理。
优势：
l 授权模式充足利用现有基础，经过合适投资和改造构建而成，见效快。
l 充足利用公安、消防、交通、卫生等部门经验，能够快速构建相对成熟应急指挥系统，指挥中心运行磨合期短、风险小。
风险：
l 授权难度大。授权要充足而又具体：授权不充足，关键时候指挥中心指挥不灵，就达不到应急联动目标；一样授权不具体，指挥中心权力边界不明确，联动时轻易出现不一样了解，贻误战机。
l 因为系统建设依靠公安等部门基础设施，所以无法和政府内网或外网互连，也就极难实现真正意义上信息联动。
l 同时，该模式也存在一些部门主动性不高，指挥困难问题。
2.2.3 代理模式
代理模式是政府成立统一接警中心或呼叫中心，负责接听城市应急呼叫，依据呼叫性质，将接警统计分配给一个或多个部门去处理，并依据各部门处理情况反馈报警人。本质上讲，这种模式并不是真正意义上应急联动，只是向城市提供了统一紧急呼叫入口。该模式所含有特征包含：由政府牵头，统一了紧急呼叫入口；各部门分头处警，各自指挥；负责向报警人反馈处理信息，监督各部门处理事件过程。
优势：
l 处理了统一接听问题，为统一指挥打下了基础。
风险：
l 首先是接警风险，不正确接警肯定造成不正确处警，所以，接警务求正确，而对应接警系统也需要很多专业知识沉淀。
l 在跨部门事件处理时，形成统一指挥关键还需要时间。
l 另外，该模式还没有真正表现应急联动理念，整体作战有赖于其它方法协调。
2.2.4 协同模式
协同模式是多个不一样类型、不一样层次指挥中心和实施机构经过网络组合在一起，根据约定步骤，分工协作、联合指挥、联合行动一个应急联动模式。协同模式所含有特征包含：应急联动机制是由多个不一样类型、多层次有指挥系统组成。通常由一个政府指挥中心、多个部门指挥中心和更多基层远程协同终端组成。不一样系统含有不一样职责。政府指挥中心战时侧重于重大事件协调、决议和监督。部门指挥中心，如公安指挥中心、交通指挥中心、消防指挥中心、抢救调度中心等，则侧重于对紧急呼叫快速反应，先期处理。基层远程协同终端系统则是部门指挥中心远程终端，关键是网上快速接收指令、网上反馈，平时上传应急指挥基础数据，在条件许能够情况下，能够由公安统一接警，也能够成立专门接警部门。条件不成熟时，能够维持现在分部门接警现实状况。
优势：
l 在协同模式下，政府指挥系统和部门指挥系统职能分明，各相关键，互不冲突。
l 构建多层次指挥网络，物理分离、逻辑集中、业务统一。
l 政府应急指挥系统是关键，经过该系统将过去多个分立部门指挥系统整合成一体化应急联动系统，大事政府牵头，小事部门负责。
风险：
l 区分重大事件和通常事件比较困难。一旦某事件被确定为通常事件，则极难立即联动，轻易贻误战机。
2.2.5 现有应急联动模式不足
l 现有应急联动系统存在关键问题是对政府各职能部门整合不够，不能实现真正应急联动。尤其是代理模式和授权模式，基础上是只能应急，不能联动，对突发事件处理能力比较差。
l 难以扩充。现有应急联动模式全部没有突出可扩展性，没有一个开放数据交换平台和多个系统接入方法，以方便已经存在和未来可能出现应急资源接入现有系统，升级潜力小。
l 没有强调预警功效。大部分应急联动模式只强调了危机出现时怎样接警和处警，而没有强调在危机发生前怎样进行监控和预报，而这正是应急联动系统最关键组成部分。假如不能对地震、洪涝、恶性传染病流行进行早期监控和预警，城市将遭受损失将是难以估量。
l 通常事件占用应急通道。出现在集权模式、授权模式和代理模式中一个关键问题是，接警处每日处理非紧急事件在70%左右，也就是说，在真正突发灾难事件发生时，很可能因为这些非紧急事件占用应急通道资源而造成战机贻误。
针对中国现在城市信息化建设现实状况，和中国已经有应急联动系统存在不足，我们提议采取以下方案。
2.3 城市应急联动系统处理方案
2.3.1 结构和组织
怎样在中国现有行政体制下，协调各职能部门间关系，建立一套适合应急联动协同作战需要组织关系，是摆在城市应急联动系统设计前面首要问题。而建立这么一个组织结构，则一定要考虑以下问题：
怎样协调应急联动中心和各职能部门关系，有效利用现有职能系统应急响应系统，最大程度地整合现有资源，节省实施成本而又不减弱应急联动效果。假如采取授权模式、代理模式和协同模式，势必造成一定程度上只能应急，不能联动或不能立即联动。所以，联动中心存在和统一接警和处警是应急联动系统正常运行不可或缺一部分。而采取集权模式实施成本又太高，而且也极难充足利用现有职能部门应急响应系统。
所以我们提议采取图2.2所表示以应急联动中心为关键，其它职能部门现有应急系统为辅分级管理模式。

图2.2 应急联动系统组织结构示意图
应急事件发生时，应急联动中心负责统一接警，统一处警，并搜集处理灾难必需案件现场全部实时信息（如：地理位置、下水管道位置等等），给出合理应急预案，并依据案件情况，指挥调配对应三级联动单位调度中心，要求立即派出处理力量编组。
平时监测时，各职能部门负责本部门职责内监控和预警，一旦监控到可能发生突发事件（如：地震、疫情爆发等），则在第一时间由系统自动通知应急联动中心，并由联动中心集合各职能部门资源（如：天气、水文、出入境管理部门等），对可能发生灾难进行评定和处理，给出防御预案，统一布署和协调各职能部门合作，在第一时间采取预防行动。
市委市政府作为最高指挥机构，通常情况下可不进入应急联动中心。一旦发生重大应急事件，市委市政府则可直接进驻联动指挥中心，利用联动中心设备进行现场指挥和调度。
该组织结构方案充足利用了现有各职能部门应急资源，并真正意义上实现了应急联动，能够对可能出现灾难做出快速行动，灾难发生时，又能合理配置和利用社会各部分资源，对突发事件做出立即有效地处理。在面对重大事件时，市委市政府能够在一线坐镇，负责指挥和协调，充足发挥现有行政体制作用。
应急联动中心
¨ 我们提议城市应该设置一个独立应急联动中心。该中心作为应急事件处理大脑中枢，应该和政府各职能部门信息系统相连，集成城市中全部必需信息资源，在应急事件发生时，统一指挥各职能部门行动。
¨ 我们提议该中心应含有统一接警和同一处警功效。前期，应派驻在各职能部门应急系统中有丰富工作经验接警人员入驻（如：110，120，119接警员）。对接警员进行接警培训，设置操作规范，对不一样灾难情况，正确而全方面地问询报案者相关信息，并进行分类整理，便于处警员统一处理。
¨ 我们提议该中心应含有开放性和高可扩展性。前期可只接入有接入条件职能部门系统，一旦有新职能部门需要加入，该中心系统能无须修改现有代码情况下，方便地接入。
¨ 我们提议该中心应能提供智能化决议支持和知识管理功效。能够为决议人员体统全方位信息（如：地理信息、煤气管道信息等），帮助决议人员完成应急预案和行动方案指定。
¨ 我们提议该中心应含有高可靠性。不仅提供硬件可靠性，更要提供软件可靠性。因为应急响应特殊要求，该中心需要实时可靠数据传输。全部数据必需一次传输，绝不丢失。
公安指挥中心、交通指挥中心、消防指挥中心、抢救调度中心等
公安指挥中心、交通指挥中心、消防指挥中心、抢救调度中心等三级应急联动中心应负责本中心应急事件预警工作，并经过可靠网络接入到应急联动中心，实时地向应急联动中心汇报。三级联动单位调动中心同时负责向联动中心传送本单位实时数据，为中心统筹安排提供信息支持。三级联动单位负责接收联动中心调度指令，并委派本单位处理力量编组实施。
2.3.2 应急联动中心运行机制
从监测到响应：对可估计灾难处理
应急联动系统一个关键任务就是在突发事件发生时，能够很快速地应对。这种突发事件不管是疾病爆发，自然灾难，还是人为酿成祸患。所以，必需含有完善预警及应急机制。这么一个完整机制在图2.3中充足显示出来。从步骤角度来看，她必需包含从监测（Detection）到响应（Response）各个步骤。而在范围上，具体包含各个功效单元：监控和监测、计划和协调、应急资源管理、沟通、超负荷能力、培训和公众意识。

图 2.3：可估计灾难处理：从监测到响应
和城市应急机制步骤相吻合，全部这些功效属于两大类系统：应急事件监控系统（Surveillance System）和指挥和控制系统（Command and Control System）。
应急时间监控系统：
为减轻中心压力，降低中心建设和运行成本，可考虑将现有各职能部门相关监控预警系统和中心应急事件监控系统相连，形成图2.4所表示分级应急监控系统。

图 2.3：分级应急监控示意图
联动中心应急事件监控系统和现有职能部门监控系统（如：地质部门地震估计系统， 卫生局公共卫生预警系统等）经过可靠网络相连。一旦这些系统发觉可能出现灾难，则经过各自系统和应急事件监控系统接口向中心自动报警，并传输和该事件相关全部消息。联动中心一旦收到报警，将立即通知指挥和控制系统（Command and Control System），并采集调用和该事件相关一切其它实时信息，对事件范围、危害程度等属性进行评定，准备生成应急预案。
使用分级应急监控好处以下：
l 充足利用政府各职能部门已经有应急预警资源，避免反复建设，节省成本。
l 充足利用现有各职能部门专业队伍和专业知识，避免集中管理带来不便。
l 各职能部门预警系统自己建设，自己使用，建设难度小。
l 减小中心压力。职能部门平时专注各自领域检测，只有发觉可能应急事件时，才立即向中心汇报，由中心统一协调处理。
l 可扩展性好。可依据城市发展情况，接入有接入条件职能部门预警系统。当其它部门对应监控系统成熟时，可直接接入，无须对现有系统做修改。
l 预警信息实时地由各分管职能部门传送到联动中心，确保了应急联动快速行动。
指挥和控制系统：
综合事件现场全方位信息（包含：水电煤管道铺设位置、距离事件发生地点最近警务人员等），在第一时间内做出对应行动决议，并经过命令人员使用设备、沟通方法和设施指导和协调人力和运作情况。该系统必需含有以下三个特征：
o 确保互连（Assured Connectivity）：情况评定和协调
o 归因（Attribution）：评定和跟踪多个信息领域中威胁
o 危机协调（Crisis Coordination）：控制和压制威胁，灾难恢复

图 2.4：应急指挥和控制系统组成单元
图2.4是应急指挥和控制系统组成单元示意图。描述了可能各项功效：
· 应急专业人员资源数据库
· 环境检测设备和汇报
· 抢救设备资源数据库
· 紧急通信系统
· 地理信息系统
· 应急资源调度
· 应急物资/药品物流系统
· 沟通手段
· 数据分析和汇报
要实现这么一个城市应急机制，必需处理很多方面问题：
· 计划和协调：我们应怎样对应急事件做好准备，并确保全部应对方法能够良好地相互协调？
o 加强现有系统
o 对各职能部门进行应急事件处理准备情况评定
o 在监测和响应准备中采取风险管理概念
o 城市各职能部门间IT协调和数据共享
· 培训和公众意识：因为应急联动系统要求各职能部门联合作战，我们怎样为应急人员提供充足协作作战培训？我们怎样向公众传达统一信息？
o 应急联动宣传/广告/公共服务通知
o 模拟演练：职能、圆桌会议、互联网
o 专业应急人员培训
· 沟通：数据、信息和告警共享和和最初响应人和提供帮助其它机构沟通方法和工具？
o 提供全方位沟通工具，包含无线设备，方便指挥人员于现场技术人员沟通。
o 确保网络可靠性，使决议需要数据能够实时有效被传送到中心。
o 确保沟通渠道安全性。
· 应急设备管理：灾难发生时，我们怎样分配安排现有应急设备和应急人员？
o 地理信息系统支持。提供事件现场全方位具体情况。
o 应急设备数据库。提供全部应急设备目前位置和地点，并能在电子地图上显示。
o 决议支持系统，提供最优资源配置。
从接警到响应：对已发生事件处理
火灾、车祸、抢劫等事件通常无法估计，通常全部是相关职能部门得到市民报警后，再采取行动。因为现在城市日益庞大和复杂，这些以前由相关职能部门负责事件，已经极难由单方面行动来处理。
举个简单例子，假如某楼宇发生了火灾，而火灾是由电器着火引发，但靠消防部门就不行了，这就需要电力部门进行区域断点。假如该楼宇是居民楼，则考虑到有天然气管道，轻易引发爆炸，需要燃气企业立即关闭该楼煤气管道。假如楼内已经有受伤居民，还要协调抢救中心和公安局进行救护和疏散。整个过程需要各部门通力合作，假如任何一环出了问题，全部可能贻误战机，给人民群众生命财产造成不可估量损失。
基于这种情况，应急联动中心一定要实现统一接警，统一处警，协调调度各职能部门进行统一行动，做到真正应急联动。图2.5是应急中心统一接警、处警实施步骤。一旦步骤抵达应急联动指挥控制系统端，则实施步骤和上节所述类似。

图 2.5统一接警处警示意图
统一接警对接警员和处警员要求比较高。接警员应含有较高业务素质，能够对不一样情况做出正确处理（如：在接到市民火警时，能够正确问询出事地点，可能起火原因等相关情况）。这就需要制订一套严格接警和处警规范和步骤，并对相关人员进行严格培训。
图2.6是一个可能接警步骤，2.7是一个可能处警步骤。

图 2.6 接警步骤

图 2.6 处警步骤
需要尤其指出是，我们提议应急联动，既能实施平时监控、预警工作，又能完成真正应急联动响应。而且最大化地利用了现有信息资源，避免了反复建设。

监控/预警工作

技术使用程序

应急响应运作

3 应急联动系统设计概述
3.1 应用系统设计标准
我们提议应急联动系统设计应把握以下标准：
实用性
区分应用需求迫切程度，以实际应用需求为关键，确保设计功效有实际应用价值。同时系统应实现用户可接收查询效率和响应时间，有良好人机接口和灵活多样展现方法。
平台化
鉴于城市应急联动中心未来业务复杂性，及应急业务不确定性，系统应建立一个开放数据交换平台，建立多个接入方法，使其含有足够灵活性和扩展能力。能够依据应用需求，方便扩展设备容量和提升设备性能，含有支持多个组件模块，含有技术升级、设备更新灵活性，含有支持业务功效扩展和重构灵活性。
安全可靠
在应急场所应用系统，其安全和可靠是至关关键，系统设计将充足考虑到系统安全防护和冗余方法。系统提供较强管理机制和控制手段，提供系统备份、数据恢复、事故监控和网络安全保密等技术方法。
平战结合
应用系统如平时应用功效不足，使用率低将直接造成战时应用效率低下，本设计将充足挖掘平时功效，使其和战时功效结合，以实现平战轻松转换。
全盘考虑
鉴于国家应急联动中心在应用上特殊地位，系统设计时将从横纵两个方向考虑应用系统架构和功效。
开放性
将基于业界开放式标准，对系统中网络协议、数据接口、指标体系等进行全国统一计划，为未来系统扩展奠定基础；
3.1.1 系统构架建设基础要求
依据我们对用户需求了解和分析，我们认为本系统要处理问题关键表现在以下几点：
1、实时性
在应急联动中心系统中，对实时性要求表现在两个方面：一是要求能实时地将联动中心命令指令传达成各职能部门；二要立即整合数据、分析情况、提供全方面信息给各级领导做决定和实时管理、公布和调配资源。因为这是突发事件处理，所以系统含有在线或快速对事件改变作出更新和修改能力。实现实时共享数据资源。
2、支持大量并发用户访问和在线处理能力
应急联动中心是一个跨部门服务中心，数据信息源于各单位也提供给相关单位。所以，系统必需含有海量数据处理能力，支持单一信息存放（OLTP）和海量并发访问（OLAP）要求。实现提供全文信息检索服务，实现专题数据库生成和库内检索服务。实现多种异构关系数据库资源、多种文档资源、图纸文件、多媒体信息整合和统一管理。所以系统必需含有优异I/O功效、支持大量并发数据访问、并提供对应并发存放保护，使系统含有支持大量多种类型并行亚秒级访问能力，同时还能支持优先级较低查询，运行数据存放提供很强在线高速缓存功效、大大降低了应用和关键中枢联接开销，适合于支持大量在线讯息交换。
3、跨部门跨平台
各部门原有运行系统能够归纳为一个特点，即“分而治之，相对独立”。同一个机构可能运行多个系统多个网络，现在运行系统多是针对特定功效和服务进行。以公共卫生系统为例，各级医疗行政部门、医院全部有自己系统、数据和网络管理，等等。有些部门缺乏对自己全部网络和业务统一管理。不一样运行系统归不一样部门管理，如病历资料在医院，医疗用具和资源数据在行政部。
联动中心系统功效须跨越网络、系统、资源等众多方面，所以不可避免地包含到众多部门众多系统平台之间协调。我们提议指挥中心采取以EAI技术基础产生、又高于传统EAI，能够实现实时数据采集、存放和分析、实时共享信息、实时掌握全国全方面状态、实时作出正确反应、实时跨越部门边界系统集成。
4、决议支持和智能应用
指挥中心必需为各部门单位提供数据分析和决议支持手段。中心系统从包含资源、事故、病理、病历、地理、天气等多种信息中作出形势和趋势分析，为各参与单位运作适时提供参考。在突发事件中为各级领导提供全方面资讯分析。
伴随中心建立数据质量更为关键，对实时智能化决议和支持要求越来越高。数据存放管理是系统关键基础，负责存放和转送应用所使用实时数据和应用集成所使用消息，提供实时数据仓库功效和管理企业目前状态消息，从而为实时决议支持和智能应用提供了强有力手段，满足应急联动中心系统提出功效要求。
5、高可靠性
应急联动中心系统作为城市突发事件指挥处理运行系统，系统无故障运行对于关键时刻和日常事务正常运转至关关键。任何一个模块和步骤故障，全部不仅会给指挥工作带来不便，而且会造成更严重后果，使政府在公众中形象下降和妨碍紧急事件处理运作。
中心系统不仅能够提供7×24高可用性，而且能够支持程序连续运行（连续可用性）、提供容错、容灾和在线维护能力，满足支持多种关键任务需要。
6、可扩展性
应急联动中心系统可扩展性是和系统信息发展趋势相对应。伴随系统运作，积累数据和分析标准将不停扩大，和技术和管理水平发展，不管是信息种类和规模，还是对运行系统需求全部表现出多样化趋势。提议处理方案一个关键目标就是为了处理现在各运行系统分立所造成一系列问题，所以对系统一个基础要求就是要避免使其成为另一个功效单一、和其它运行系统相隔绝系统。从发展角度看，只有含有了高度可扩展性，才是一个有生命力系统。
对指挥中心系统来说，可扩展性包含多个方面含义：
l 能不停适应更多信息种类；
l 能适应更大功效和数据规模；
l 能提供更多运行系统功效；
l 含有业界通用标准接口，方便和其它系统进行无缝互连；
l 采取模块化结构，适应不一样部门不一样功效需求。
和传统EAI相比，新系统一个突出特点是能够方便地增加应用数量、扩大系统资源规模、在增加工作负载同时不降低性能。而且伴随系统规模和应用数量增加，系统优势表现愈加显著。其强大可扩展性能够确保在指挥中心系统升级和功效完善过程中，提供足够处理能力满足系统需求。
3.1.2 应用系统设计思绪
突发事件应急管理(指挥)理念

图3.1 突发事件应急管理(指挥)理念
突发事件应急指挥和决议整体框架
城市突发事件应急方案生成是建立在各职能部门对突发事件发生地情况实时汇报基础上，预先依据历史和现实业已存在可能发生类似事件为对象，制订突发事件应急预案，组成突发事件应急处理方案集，同时制订建立知识库规则，系统依据突发事件等级，针对事件类型，按图3.2所表示指挥决议整体框架结构经过会商确定实施应急方案。由此能够看到，突发事件应急决议是经过计算机对突发事件监控体系和群众对突发事件汇报，采集和突发事件相关信息，依据所管理信息根据不一样突发事件，设计一组可供选择应急方案，决议者经过人机对话方法在一组可行方案中选择较佳方案作为应对突发事件对策。

图3.2突发事件应急指挥和决议整体框架
指挥中心技术实现思绪及决议步骤

图3.3 指挥中心技术实现思绪及决议步骤
城市应急联动中心技术实现思绪及决议过程如上图所表示,从数据、信息、知识到智慧，其数据处理目标就是要对获取不一样起源数据进行标准化和整合，形成信息，进而提供对信息深入加工和分析形成知识，经过对知识积累和选择形成智慧，从而帮助指挥决议人员进行决议。整个决议过程经过会商来实现。突发公共卫生事件会商管理工作步骤图3.4所表示。

图3.4：会商管理工作步骤
应急指挥和决议分析内容

图3.5应急指挥和决议分析内容
3.1.3 总体应用架构

图3.6 应用系统总体架构
应用系统由“一个中心、一个门户、三个系统支撑平台、三个关键应用平台”组成。如上图所表示，一个中心指数据中心；一个门户指综合信息门户；三个支撑系统平台指安全管理平台、数据交换平台、系统监控和管理平台；三个关键应用平台指基础信息平台、专业服务平台和综合决议平台。
3.1.4 应用系统总体运行步骤
在数据中心支持下，针对城市突发事件管理，系统将沿预防监测、预警准备、快速反应、收尾恢复、总结提升步骤进行运行，循环反复不停提升系统应急处理支持能力。
1、预防监测
联动中心在此阶段关键负责接收、分配、核实和处理事件汇报，同时负责协调和组织开展突发事件预防和监测工作，获取动态监测、事件调查和疫情评定信息，跟踪事件发展状态。
联动中心还将主动开展演练、培训和研究工作，开展应急业务模拟，提升应急处理能力，主动研究完善相关政策法规、预案和方案，同时计划贮备应急医疗资源等，建立突发事件防控体系。
2、预警准备
依据国家法定步骤和预案，联动中心将组织教授进行事件评定，并针对评定结果公布预警信息，针对相关突发事件快速开展准备具体方案和工作细节准备工作，落实相关预案和方案包含工作准备情况，同时依据步骤进行通报和汇报。
在此阶段关键是进行响应前准备工作，进行动员和预热，准备应急资源，落实开启细节，同时主动控制事件发展，采取对应控制方法阻止事件升级。
3、快速反应
针对突发事件，快速开启预案，并依据预案快速指挥和实施工作，有条不紊地组织调度人员和物资，开展应急专业处理和相关配合工作。同时依据反馈情况，动态评定事件发展情况，依据事件情况调整方法，最大程度地减低损失。
此阶段关键在于在事件暴发阶段快速开启响应程序，进入应急处理状态，同时为教授提供立即正确数据和正确信息，为指挥首长和指挥人员快速提供现实状况描述，分析估计事件发展趋势，提出参考方法。在决议形成后，快速布署实施，跟踪落实情况，从而控制疫情或事件蔓延，使其立即稳定和下降。
4、收尾恢复
在突发事件降级或结束时，联动中心将进行事件收尾工作处理，以尽可能降低无须要损失，同时将快速开展从应急状态恢复到正常状态工作。首先组织进行相关控制方法，预防事件死灰复燃，也控制其它可能突发事件发生；其次将有计划地补充应急处理阶段所消耗战备资源，同时逐步恢复大家正常生活和生产。
此阶段关键在于主动主动地进行事件扫尾，提醒注意事项，同时辅助计划和补充资源，从而控制事件立即回复正常，降低损失。
5、总结提升
在事件结束后，应进行科学总结，深入完善政策法规、预案和方案，同时组织开展应急处理技术研究和探讨，总结经验，制订针对性防控方法和演练方案，从而提升相关事件应急处理能力。
此阶段最关键是总结经验教训，辅助制订针对性方法，修订和完善相关应急制度和步骤，形成更有效操作规范，从而提升处理能力。

3.1.5 总体技术方案
总体技术架构
3.1.5.1.1 基于浏览器/服务器三层体系结构
系统在技术上要求含有业务改变适应性、高度安全性、大容量数据存放处理等特点，引入数据仓库技术。系统利用交易中间件，将应用业务逻辑、表示逻辑和数据分为三个不一样处理层：
表示逻辑（用户层）为第一层:它关键功效是实现用户交互和数据表示，为以后处理搜集数据，向第二层业务逻辑请求调用关键服务处理，并显示处理结果。
业务逻辑（服务器组件）为中间层:这些组件由中间件管理，实现关键业务逻辑服务并将这些服务按名字广播，管理并接收用户服务请求，向资源管理器提交数据操作，并将处理结果返回给请求者——即用户或其它服务器。
数据（资源管理器）组成模型第三层。比如关系数据库，负责管理应用系统数据资源，完成数据操作。服务器组件在完成服务过程中经过资源管理器存取它管理数据，或说请求资源管理器数据服务。
在三层用户机/服务器模式上架构应用系统不仅含有了大型机系统稳定、安全和处理能力高等特征，同时拥有开放式系统成本低、可扩展性强、开发周期短等优点。交易中间件作为结构三层结构应用系统基础平台，提供了以下两个关键功效：
负责用户机和服务器间联接和通讯
提供一个三层结构应用开发和运行平台
采取三层结构应用模型，为用分布式环境处理关键性业务提供了一个结构化处理方案。中间件应用设计应该是从异构计算资源中创建一个“虚拟主机”，在分布式应用系统环境下提供可管理相互关联资源。
交易中间件提供了一个基础框架来建立、运行和管理一个三层用户机/服务器模式应用，无需从零做起，大大缩短了应用开发时间，提升了应用开发成功率。
在三层结构应用模式中，表示逻辑层和资源管理器作为应用界面和数据管理