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

昆明城市应急响应联动防御系统项目提议书翼博通讯10月Version0.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.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.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 安全汇报 84概述伴随中国城市建设不停发展，政府对城市综合管理也面临着极大挑战。这尤其表现在处理地震、恶性流行性疾病扩散、恐怖攻击、有害物质泄漏等重大灾难时。灾难发生前，怎样依据搜集到信息进行立即有效预警；灾难发生后，怎样调动、指挥和协调各方面资源，统一领导，快速行动，已经成为政府部门面临关键课题。“911”事件、SARS、印度洋海啸等突发事件已经暴露出城市危机管理机制微弱和应对突发事件能力缺乏是一个世界性问题。而世界各国也全部在主动建设自己应急联动系统。中国应急联动系统建设还处于起步阶段，没有固定模式可寻。因为各个城市规模、自然、人文和信息化建设程度不一样，分别出现了以南宁为代表集权模式，以北京为代表代理模式，以广州为代表授权模式和以扬州为代表网络模式。这些模式各有优缺点，而应用这些模式应急联动系统在运行过程中，暴露出部分问题。这些问题含有相当普遍性，是在中国建设应急联动系统所必需处理问题：怎样在现有行政体制和应急联动中心之间取得平衡，取得最大反应速度和协作效果，是目前应急联动系统面临首要问题。应急联动需要整合政府现有各部门资源，所以，怎样定义应急联动中心在政府现有体系中地位，并确立和其它部门职、权、利关系，是确保应急联动中心有效运作关键。怎样整合现有资源，建立以应急联动中心为关键应急联动神经网络，是应急联动建设关键问题。城市应急联动首先要实现信息联动，所以，多部门异构数据集成是应急指挥系统设计关键焦点。因为部门众多，相关信息系统也很多，这就需要统一基础信息交换平台，将不一样部门信息系统和应用系统有效地整合在一起。怎样确保应急联动系统开放性、通用性和可扩展性。现在应急联动业务范围关键涵盖公安、交通、消防、医疗抢救、水电气、自然灾难、生产事故等，和以前状态相比，已经有了巨大进步。不过从系统设计角度看，处理问题思绪还局限于就事论事层面，缺乏通用关键处理模型和开放架构，所以系统灵活性和可扩展性也就比较差。从发展角度来看，当城市出现新问题或事件时，系统应该许可经过接入新系统或模块和调整步骤来适应新业务。怎样提供智能化决议支持和知识管理，为应急指挥提供有效支持。城市应急联动中心真正挑战不是来自大量日常事件，而是来自少许特殊事件，包含专业性强事件、疑难事件、重大事故、敏感事件等。全部这些事件，要么不出现，一旦出现就很棘手。在高度紧急情况下，指挥人员要能够对报警等突发事件、关键案件快速地做出正确决议，需要掌握大量事件专业知识和背景知识，如专业、地理、交通、法律法规、警力布署等。所以，应急联动系统应含有知识管理和决议支持功效，以确保在紧急情况下，系统能够向指挥人员提供充足相关知识支持和预案提议，避免出现重大差错。怎样确保系统高可靠性。应急联动系统任务是应急事务处理，所以系统本身可靠性很关键。从实践中得出，设备可靠性并不等系统可靠性。中国在类似系统建设时，往往比较重视硬件设备可靠性，但实践证实，这种做法带来可靠性是不能完全处理问题。所以，在系统可靠性设计中，还要强调软件系统可靠性设计，即立足于事件处理步骤，建立一个安全事务保护机制，避免形成对特定设备或环境依靠，在系统部分设备或环境发生故障时，犯错事务依据不一样场景进行立即转移、备份或临时降能处理，以确保相关事务连续、并行处理，从而在应用等级上最大程度地保障可靠性。怎样建立安全有效监控和考评系统。指挥中心是一个关键任务处理中心，除了技术系统引发风险之外，更多风险还来自于人为责任事故，所以，管理水平是指挥中心良好运作关键原因。因为应急联动中心人员往往来自不一样部门，有着各自责任和利益，一旦出现责任事故，轻易相互推诿。所以，系统设计要充足考虑到这些需求，提供充足管理参数获取和管理手段。怎样实施应急联动系统标准化工作。应急联动系统建设和使用必将是一个长久过程。国外大型应用系统取得成功关键原因是连续不停技术标准化和业务标准化建设，多种标准在系统计划、系统设计、业务模型、技术选型过程中起到了强有力引导作用，从而确保了一代一代系统含有良好继承性和一致性。应急联动标准化需求表现在信息交换格式标准化、通信协议标准化、电子地图标准等各个方面。标准化将方便各子系统接入应急联动平台，而系统升级替换工作也会所以变简单易行。总而言之，应急联动系统需要达成高可用性、可扩展性、高可靠性、安全性、智能化、标准化这多个目标。本文将下下面章节中具体讨论怎样设计和实现这些目标。应急联动系统体系和信息化建设 和应急联动系统关联部门城市应急联动系统需要协调政府各职能部门资源，统一指挥、统一行动。在中国，这些职能部门包含公安部门、消防部门、交通管理部门、医疗抢救、煤气企业、自来水企业、电力部门、工商、城管等。而这些职能部门大部分已经建立有自己应急服务系统，如公安部门110报警电话、消防部门119火警电话、医疗抢救120电话等。怎样整合各部门已经有应急资源（包含人力资源），达成充足高效利用，是应急联动系统设计时要考虑首要问题。应急联动系统需要建立以联动中心为关键，连接各职能部门数据通道，集成各部门数据和资源。确保在危机处理时：首先，联动系统能够立即地得到全方位实时数据，作为形成应急预案基础；其次，确保联动中心发出指令能够快速下达成各单位，使整个行动能有条不紊地进行。图2.1是应急联动中心和现有各政府职能部门关系示意图。图2.1应急联动中心关联部门示意图应急联动中心“战时”侧重于重大事件协调、决议和监督，建立预案；“平时”则侧重于突发事件（如地震、流行性疾病传输等）监测、预警和预案演练。作为决议和指挥者联动中心，集成了各职能部门有效资源，应能在灾难发生前作出立即预警，灾难发生后第一时间作出正确决议，在危机解除后给出合理救援安排和任务移交计划，全方位地保护人民群众生命和财产安全，将突发事件损失降到最小。中国应急联动系统建设现实状况分析应急联动系统建设在中国还处于起步阶段。所以，现在还没有统一建设模式。分析中国已建设应急联动中心能够发觉，中国应急联动中心大致能够分为四种类型：集权模式、授权模式、代理模式、协同模式。集权模式集权模式是指整合政府和社会全部应急资源，成立专门应急联动中心，由该部门代表政府全权行使应急联动指挥大权。中国第一个建设“城市应急联动”南宁市就采取了集权模式。该模式所含有特征包含：由政府牵头、政府投资、集中管理，应急联动中心是政府管理一个部门，有专门编制和预算；联动中心是城市应急事件处理唯一中枢；政府将全部指挥权归于联动中心，应急联动中心在处理紧急事时，有权调动政府任何部门；采取一级接警，一级处警，即指挥中心统一接警，统一处警；简单事件由专业组处理，出现重大事件时，由指挥长协调各专业联动处警；市政府不再设应急联动中心，出现重大事件时应急联动中心同时也是政府指挥中心，政府领导能够在指挥中心市长指挥区参与指挥；应急联动中心同时也是应急指挥资源管理中心，统一管理相关应急指挥资源。优势：集权模式是国外应急指挥普遍采取形式，表现了城市应急联动本质要求，是城市联动发展方向。统一指挥、信息共享、资源共享，有利于实现快速反应、正确指挥。一级接警，统一了全部报警信息入口，另外，一级接警降低了指挥层次，使指挥效率大大提升，有利于快速反应。风险：该模式几乎重构了城市应急体制，所以建设难度大，投资也大。在接警量大情况下，一级处警没有多层次协作指挥，轻易造成指挥中心负荷过重。授权模式授权模式是政府利用现有应急指挥基础，依据城市应急联动要求，经过局部体制调整，授权应急基础比很好某一部门，在该部门牵头下，政府相关应急部门联动办公，联合行动，从而快速构建城市应急联动系统。授权模式所含有特征包含：政府将应急联动指挥权授权给公安，以公安处警为关键，协同其它联动部门共同处警。在紧急情况下，公安代表政府调动各部门联合行动，并代表政府协调和监督紧急事务处理。优势：授权模式充足利用现有基础，经过合适投资和改造构建而成，见效快。充足利用公安、消防、交通、卫生等部门经验，能够快速构建相对成熟应急指挥系统，指挥中心运行磨合期短、风险小。风险：授权难度大。授权要充足而又具体：授权不充足，关键时候指挥中心指挥不灵，就达不到应急联动目标；一样授权不具体，指挥中心权力边界不明确，联动时轻易出现不一样了解，贻误战机。因为系统建设依靠公安等部门基础设施，所以无法和政府内网或外网互连，也就极难实现真正意义上信息联动。同时，该模式也存在一些部门主动性不高，指挥困难问题。代理模式代理模式是政府成立统一接警中心或呼叫中心，负责接听城市应急呼叫，依据呼叫性质，将接警统计分配给一个或多个部门去处理，并依据各部门处理情况反馈报警人。本质上讲，这种模式并不是真正意义上应急联动，只是向城市提供了统一紧急呼叫入口。该模式所含有特征包含：由政府牵头，统一了紧急呼叫入口；各部门分头处警，各自指挥；负责向报警人反馈处理信息，监督各部门处理事件过程。优势：处理了统一接听问题，为统一指挥打下了基础。风险：首先是接警风险，不正确接警肯定造成不正确处警，所以，接警务求正确，而对应接警系统也需要很多专业知识沉淀。在跨部门事件处理时，形成统一指挥关键还需要时间。另外，该模式还没有真正表现应急联动理念，整体作战有赖于其它方法协调。协同模式协同模式是多个不一样类型、不一样层次指挥中心和实施机构经过网络组合在一起，根据约定步骤，分工协作、联合指挥、联合行动一个应急联动模式。协同模式所含有特征包含：应急联动机制是由多个不一样类型、多层次有指挥系统组成。通常由一个政府指挥中心、多个部门指挥中心和更多基层远程协同终端组成。不一样系统含有不一样职责。政府指挥中心战时侧重于重大事件协调、决议和监督。部门指挥中心，如公安指挥中心、交通指挥中心、消防指挥中心、抢救调度中心等，则侧重于对紧急呼叫快速反应，先期处理。基层远程协同终端系统则是部门指挥中心远程终端，关键是网上快速接收指令、网上反馈，平时上传应急指挥基础数据，在条件许能够情况下，能够由公安统一接警，也能够成立专门接警部门。条件不成熟时，能够维持现在分部门接警现实状况。优势：在协同模式下，政府指挥系统和部门指挥系统职能分明，各相关键，互不冲突。构建多层次指挥网络，物理分离、逻辑集中、业务统一。政府应急指挥系统是关键，经过该系统将过去多个分立部门指挥系统整合成一体化应急联动系统，大事政府牵头，小事部门负责。风险：区分重大事件和通常事件比较困难。一旦某事件被确定为通常事件，则极难立即联动，轻易贻误战机。现有应急联动模式不足现有应急联动系统存在关键问题是对政府各职能部门整合不够，不能实现真正应急联动。尤其是代理模式和授权模式，基础上是只能应急，不能联动，对突发事件处理能力比较差。难以扩充。现有应急联动模式全部没有突出可扩展性，没有一个开放数据交换平台和多个系统接入方法，以方便已经存在和未来可能出现应急资源接入现有系统，升级潜力小。没有强调预警功效。大部分应急联动模式只强调了危机出现时怎样接警和处警，而没有强调在危机发生前怎样进行监控和预报，而这正是应急联动系统最关键组成部分。假如不能对地震、洪涝、恶性传染病流行进行早期监控和预警，城市将遭受损失将是难以估量。通常事件占用应急通道。出现在集权模式、授权模式和代理模式中一个关键问题是，接警处每日处理非紧急事件在70%左右，也就是说，在真正突发灾难事件发生时，很可能因为这些非紧急事件占用应急通道资源而造成战机贻误。针对中国现在城市信息化建设现实状况，和中国已经有应急联动系统存在不足，我们提议采取以下方案。城市应急联动系统处理方案结构和组织怎样在中国现有行政体制下，协调各职能部门间关系，建立一套适合应急联动协同作战需要组织关系，是摆在城市应急联动系统设计前面首要问题。而建立这么一个组织结构，则一定要考虑以下问题：怎样协调应急联动中心和各职能部门关系，有效利用现有职能系统应急响应系统，最大程度地整合现有资源，节省实施成本而又不减弱应急联动效果。假如采取授权模式、代理模式和协同模式，势必造成一定程度上只能应急，不能联动或不能立即联动。所以，联动中心存在和统一接警和处警是应急联动系统正常运行不可或缺一部分。而采取集权模式实施成本又太高，而且也极难充足利用现有职能部门应急响应系统。所以我们提议采取图2.2所表示以应急联动中心为关键，其它职能部门现有应急系统为辅分级管理模式。图2.2应急联动系统组织结构示意图应急事件发生时，应急联动中心负责统一接警，统一处警，并搜集处理灾难必需案件现场全部实时信息（如：地理位置、下水管道位置等等），给出合理应急预案，并依据案件情况，指挥调配对应三级联动单位调度中心，要求立即派出处理力量编组。平时监测时，各职能部门负责本部门职责内监控和预警，一旦监控到可能发生突发事件（如：地震、疫情爆发等），则在第一时间由系统自动通知应急联动中心，并由联动中心集合各职能部门资源（如：天气、水文、出入境管理部门等），对可能发生灾难进行评定和处理，给出防御预案，统一布署和协调各职能部门合作，在第一时间采取预防行动。市委市政府作为最高指挥机构，通常情况下可不进入应急联动中心。一旦发生重大应急事件，市委市政府则可直接进驻联动指挥中心，利用联动中心设备进行现场指挥和调度。该组织结构方案充足利用了现有各职能部门应急资源，并真正意义上实现了应急联动，能够对可能出现灾难做出快速行动，灾难发生时，又能合理配置和利用社会各部分资源，对突发事件做出立即有效地处理。在面对重大事件时，市委市政府能够在一线坐镇，负责指挥和协调，充足发挥现有行政体制作用。应急联动中心我们提议城市应该设置一个独立应急联动中心。该中心作为应急事件处理大脑中枢，应该和政府各职能部门信息系统相连，集成城市中全部必需信息资源，在应急事件发生时，统一指挥各职能部门行动。我们提议该中心应含有统一接警和同一处警功效。前期，应派驻在各职能部门应急系统中有丰富工作经验接警人员入驻（如：110，120，119接警员）。对接警员进行接警培训，设置操作规范，对不一样灾难情况，正确而全方面地问询报案者相关信息，并进行分类整理，便于处警员统一处理。我们提议该中心应含有开放性和高可扩展性。前期可只接入有接入条件职能部门系统，一旦有新职能部门需要加入，该中心系统能无须修改现有代码情况下，方便地接入。我们提议该中心应能提供智能化决议支持和知识管理功效。能够为决议人员体统全方位信息（如：地理信息、煤气管道信息等），帮助决议人员完成应急预案和行动方案指定。我们提议该中心应含有高可靠性。不仅提供硬件可靠性，更要提供软件可靠性。因为应急响应特殊要求，该中心需要实时可靠数据传输。全部数据必需一次传输，绝不丢失。公安指挥中心、交通指挥中心、消防指挥中心、抢救调度中心等公安指挥中心、交通指挥中心、消防指挥中心、抢救调度中心等三级应急联动中心应负责本中心应急事件预警工作，并经过可靠网络接入到应急联动中心，实时地向应急联动中心汇报。三级联动单位调动中心同时负责向联动中心传送本单位实时数据，为中心统筹安排提供信息支持。三级联动单位负责接收联动中心调度指令，并委派本单位处理力量编组实施。应急联动中心运行机制从监测到响应：对可估计灾难处理应急联动系统一个关键任务就是在突发事件发生时，能够很快速地应对。这种突发事件不管是疾病爆发，自然灾难，还是人为酿成祸患。所以，必需含有完善预警及应急机制。这么一个完整机制在图2.3中充足显示出来。从步骤角度来看，她必需包含从监测（Detection）到响应（Response）各个步骤。而在范围上，具体包含各个功效单元：监控和监测、计划和协调、应急资源管理、沟通、超负荷能力、培训和公众意识。图2.3：可估计灾难处理：从监测到响应和城市应急机制步骤相吻合，全部这些功效属于两大类系统：应急事件监控系统（SurveillanceSystem）和指挥和控制系统（CommandandControlSystem）。应急时间监控系统：为减轻中心压力，降低中心建设和运行成本，可考虑将现有各职能部门相关监控预警系统和中心应急事件监控系统相连，形成图2.4所表示分级应急监控系统。图2.3：分级应急监控示意图联动中心应急事件监控系统和现有职能部门监控系统（如：地质部门地震估计系统，卫生局公共卫生预警系统等）经过可靠网络相连。一旦这些系统发觉可能出现灾难，则经过各自系统和应急事件监控系统接口向中心自动报警，并传输和该事件相关全部消息。联动中心一旦收到报警，将立即通知指挥和控制系统（CommandandControlSystem），并采集调用和该事件相关一切其它实时信息，对事件范围、危害程度等属性进行评定，准备生成应急预案。使用分级应急监控好处以下：充足利用政府各职能部门已经有应急预警资源，避免反复建设，节省成本。充足利用现有各职能部门专业队伍和专业知识，避免集中管理带来不便。各职能部门预警系统自己建设，自己使用，建设难度小。减小中心压力。职能部门平时专注各自领域检测，只有发觉可能应急事件时，才立即向中心汇报，由中心统一协调处理。可扩展性好。可依据城市发展情况，接入有接入条件职能部门预警系统。当其它部门对应监控系统成熟时，可直接接入，无须对现有系统做修改。预警信息实时地由各分管职能部门传送到联动中心，确保了应急联动快速行动。指挥和控制系统：综合事件现场全方位信息（包含：水电煤管道铺设位置、距离事件发生地点最近警务人员等），在第一时间内做出对应行动决议，并经过命令人员使用设备、沟通方法和设施指导和协调人力和运作情况。该系统必需含有以下三个特征：确保互连（AssuredConnectivity）：情况评定和协调归因（Attribution）：评定和跟踪多个信息领域中威胁危机协调（CrisisCoordination）：控制和压制威胁，灾难恢复图2.4：应急指挥和控制系统组成单元图2.4是应急指挥和控制系统组成单元示意图。描述了可能各项功效：应急专业人员资源数据库环境检测设备和汇报抢救设备资源数据库紧急通信系统地理信息系统应急资源调度应急物资/药品物流系统沟通手段数据分析和汇报要实现这么一个城市应急机制，必需处理很多方面问题：计划和协调：我们应怎样对应急事件做好准备，并确保全部应对方法能够良好地相互协调？加强现有系统对各职能部门进行应急事件处理准备情况评定在监测和响应准备中采取风险管理概念城市各职能部门间IT协调和数据共享培训和公众意识：因为应急联动系统要求各职能部门联合作战，我们怎样为应急人员提供充足协作作战培训？我们怎样向公众传达统一信息？应急联动宣传/广告/公共服务通知模拟演练：职能、圆桌会议、互联网专业应急人员培训沟通：数据、信息和告警共享和和最初响应人和提供帮助其它机构沟通方法和工具？提供全方位沟通工具，包含无线设备，方便指挥人员于现场技术人员沟通。确保网络可靠性，使决议需要数据能够实时有效被传送到中心。确保沟通渠道安全性。应急设备管理：灾难发生时，我们怎样分配安排现有应急设备和应急人员？地理信息系统支持。提供事件现场全方位具体情况。应急设备数据库。提供全部应急设备目前位置和地点，并能在电子地图上显示。决议支持系统，提供最优资源配置。从接警到响应：对已发生事件处理 火灾、车祸、抢劫等事件通常无法估计，通常全部是相关职能部门得到市民报警后，再采取行动。因为现在城市日益庞大和复杂，这些以前由相关职能部门负责事件，已经极难由单方面行动来处理。举个简单例子，假如某楼宇发生了火灾，而火灾是由电器着火引发，但靠消防部门就不行了，这就需要电力部门进行区域断点。假如该楼宇是居民楼，则考虑到有天然气管道，轻易引发爆炸，需要燃气企业立即关闭该楼煤气管道。假如楼内已经有受伤居民，还要协调抢救中心和公安局进行救护和疏散。整个过程需要各部门通力合作，假如任何一环出了问题，全部可能贻误战机，给人民群众生命财产造成不可估量损失。基于这种情况，应急联动中心一定要实现统一接警，统一处警，协调调度各职能部门进行统一行动，做到真正应急联动。图2.5是应急中心统一接警、处警实施步骤。一旦步骤抵达应急联动指挥控制系统端，则实施步骤和上节所述类似。图2.5统一接警处警示意图统一接警对接警员和处警员要求比较高。接警员应含有较高业务素质，能够对不一样情况做出正确处理（如：在接到市民火警时，能够正确问询出事地点，可能起火原因等相关情况）。这就需要制订一套严格接警和处警规范和步骤，并对相关人员进行严格培训。图2.6是一个可能接警步骤，2.7是一个可能处警步骤。图2.6接警步骤图2.6处警步骤需要尤其指出是，我们提议应急联动，既能实施平时监控、预警工作，又能完成真正应急联动响应。而且最大化地利用了现有信息资源，避免了反复建设。监控/预警工作技术使用程序监控/预警工作技术使用程序应急响应运作应急联动系统设计概述应用系统设计标准我们提议应急联动系统设计应把握以下标准：实用性区分应用需求迫切程度，以实际应用需求为关键，确保设计功效有实际应用价值。同时系统应实现用户可接收查询效率和响应时间，有良好人机接口和灵活多样展现方法。平台化鉴于城市应急联动中心未来业务复杂性，及应急业务不确定性，系统应建立一个开放数据交换平台，建立多个接入方法，使其含有足够灵活性和扩展能力。能够依据应用需求，方便扩展设备容量和提升设备性能，含有支持多个组件模块，含有技术升级、设备更新灵活性，含有支持业务功效扩展和重构灵活性。安全可靠在应急场所应用系统，其安全和可靠是至关关键，系统设计将充足考虑到系统安全防护和冗余方法。系统提供较强管理机制和控制手段，提供系统备份、数据恢复、事故监控和网络安全保密等技术方法。平战结合应用系统如平时应用功效不足，使用率低将直接造成战时应用效率低下，本设计将充足挖掘平时功效，使其和战时功效结合，以实现平战轻松转换。全盘考虑鉴于国家应急联动中心在应用上特殊地位，系统设计时将从横纵两个方向考虑应用系统架构和功效。开放性将基于业界开放式标准，对系统中网络协议、数据接口、指标体系等进行全国统一计划，为未来系统扩展奠定基础；系统构架建设基础要求依据我们对用户需求了解和分析，我们认为本系统要处理问题关键表现在以下几点：1、实时性在应急联动中心系统中，对实时性要求表现在两个方面：一是要求能实时地将联动中心命令指令传达成各职能部门；二要立即整合数据、分析情况、提供全方面信息给各级领导做决定和实时管理、公布和调配资源。因为这是突发事件处理，所以系统含有在线或快速对事件改变作出更新和修改能力。实现实时共享数据资源。2、支持大量并发用户访问和在线处理能力应急联动中心是一个跨部门服务中心，数据信息源于各单位也提供给相关单位。所以，系统必需含有海量数据处理能力，支持单一信息存放（OLTP）和海量并发访问（OLAP）要求。实现提供全文信息检索服务，实现专题数据库生成和库内检索服务。实现多种异构关系数据库资源、多种文档资源、图纸文件、多媒体信息整合和统一管理。所以系统必需含有优异I/O功效、支持大量并发数据访问、并提供对应并发存放保护，使系统含有支持大量多种类型并行亚秒级访问能力，同时还能支持优先级较低查询，运行数据存放提供很强在线高速缓存功效、大大降低了应用和关键中枢联接开销，适合于支持大量在线讯息交换。3、跨部门跨平台各部门原有运行系统能够归纳为一个特点，即“分而治之，相对独立”。同一个机构可能运行多个系统多个网络，现在运行系统多是针对特定功效和服务进行。以公共卫生系统为例，各级医疗行政部门、医院全部有自己系统、数据和网络管理，等等。有些部门缺乏对自己全部网络和业务统一管理。不一样运行系统归不一样部门管理，如病历资料在医院，医疗用具和资源数据在行政部。联动中心系统功效须跨越网络、系统、资源等众多方面，所以不可避免地包含到众多部门众多系统平台之间协调。我们提议指挥中心采取以EAI技术基础产生、又高于传统EAI，能够实现实时数据采集、存放和分析、实时共享信息、实时掌握全国全方面状态、实时作出正确反应、实时跨越部门边界系统集成。4、决议支持和智能应用指挥中心必需为各部门单位提供数据分析和决议支持手段。中心系统从包含资源、事故、病理、病历、地理、天气等多种信息中作出形势和趋势分析，为各参与单位运作适时提供参考。在突发事件中为各级领导提供全方面资讯分析。伴随中心建立数据质量更为关键，对实时智能化决议和支持要求越来越高。数据存放管理是系统关键基础，负责存放和转送应用所使用实时数据和应用集成所使用消息，提供实时数据仓库功效和管理企业目前状态消息，从而为实时决议支持和智能应用提供了强有力手段，满足应急联动中心系统提出功效要求。5、高可靠性应急联动中心系统作为城市突发事件指挥处理运行系统，系统无故障运行对于关键时刻和日常事务正常运转至关关键。任何一个模块和步骤故障，全部不仅会给指挥工作带来不便，而且会造成更严重后果，使政府在公众中形象下降和妨碍紧急事件处理运作。中心系统不仅能够提供7×24高可用性，而且能够支持程序连续运行（连续可用性）、提供容错、容灾和在线维护能力，满足支持多种关键任务需要。6、可扩展性应急联动中心系统可扩展性是和系统信息发展趋势相对应。伴随系统运作，积累数据和分析标准将不停扩大，和技术和管理水平发展，不管是信息种类和规模，还是对运行系统需求全部表现出多样化趋势。提议处理方案一个关键目标就是为了处理现在各运行系统分立所造成一系列问题，所以对系统一个基础要求就是要避免使其成为另一个功效单一、和其它运行系统相隔绝系统。从发展角度看，只有含有了高度可扩展性，才是一个有生命力系统。对指挥中心系统来说，可扩展性包含多个方面含义：能不停适应更多信息种类；能适应更大功效和数据规模；能提供更多运行系统功效；含有业界通用标准接口，方便和其它系统进行无缝互连；采取模块化结构，适应不一样部门不一样功效需求。和传统EAI相比，新系统一个突出特点是能够方便地增加应用数量、扩大系统资源规模、在增加工作负载同时不降低性能。而且伴随系统规模和应用数量增加，系统优势表现愈加显著。其强大可扩展性能够确保在指挥中心系统升级和功效完善过程中，提供足够处理能力满足系统需求。应用系统设计思绪突发事件应急管理(指挥)理念图3.1突发事件应急管理(指挥)理念突发事件应急指挥和决议整体框架城市突发事件应急方案生成是建立在各职能部门对突发事件发生地情况实时汇报基础上，预先依据历史和现实业已存在可能发生类似事件为对象，制订突发事件应急预案，组成突发事件应急处理方案集，同时制订建立知识库规则，系统依据突发事件等级，针对事件类型，按图3.2所表示指挥决议整体框架结构经过会商确定实施应急方案。由此能够看到，突发事件应急决议是经过计算机对突发事件监控体系和群众对突发事件汇报，采集和突发事件相关信息，依据所管理信息根据不一样突发事件，设计一组可供选择应急方案，决议者经过人机对话方法在一组可行方案中选择较佳方案作为应对突发事件对策。图3.2突发事件应急指挥和决议整体框架指挥中心技术实现思绪及决议步骤图3.3指挥中心技术实现思绪及决议步骤城市应急联动中心技术实现思绪及决议过程如上图所表示,从数据、信息、知识到智慧，其数据处理目标就是要对获取不一样起源数据进行标准化和整合，形成信息，进而提供对信息深入加工和分析形成知识，经过对知识积累和选择形成智慧，从而帮助指挥决议人员进行决议。整个决议过程经过会商来实现。突发公共卫生事件会商管理工作步骤图3.4所表示。图3.4：会商管理工作步骤应急指挥和决议分析内容图3.5应急指挥和决议分析内容总体应用架构图3.6应用系统总体架构应用系统由“一个中心、一个门户、三个系统支撑平台、三个关键应用平台”组成。如上图所表示，一个中心指数据中心；一个门户指综合信息门户；三个支撑系统平台指安全管理平台、数据交换平台、系统监控和管理平台；三个关键应用平台指基础信息平台、专业服务平台和综合决议平台。应用系统总体运行步骤在数据中心支持下，针对城市突发事件管理，系统将沿预防监测、预警准备、快速反应、收尾恢复、总结提升步骤进行运行，循环反复不停提升系统应急处理支持能力。1、预防监测联动中心在此阶段关键负责接收、分配、核实和处理事件汇报，同时负责协调和组织开展突发事件预防和监测工作，获取动态监测、事件调查和疫情评定信息，跟踪事件发展状态。联动中心还将主动开展演练、培训和研究工作，开展应急业务模拟，提升应急处理能力，主动研究完善相关政策法规、预案和方案，同时计划贮备应急医疗资源等，建立突发事件防控体系。2、预警准备依据国家法定步骤和预案，联动中心将组织教授进行事件评定，并针对评定结果公布预警信息，针对相关突发事件快速开展准备具体方案和工作细节准备工作，落实相关预案和方案包含工作准备情况，同时依据步骤进行通报和汇报。在此阶段关键是进行响应前准备工作，进行动员和预热，准备应急资源，落实开启细节，同时主动控制事件发展，采取对应控制方法阻止事件升级。3、快速反应针对突发事件，快速开启预案，并依据预案快速指挥和实施工作，有条不紊地组织调度人员和物资，开展应急专业处理和相关配合工作。同时依据反馈情况，动态评定事件发展情况，依据事件情况调整方法，最大程度地减低损失。此阶段关键在于在事件暴发阶段快速开启响应程序，进入应急处理状态，同时为教授提供立即正确数据和正确信息，为指挥首长和指挥人员快速提供现实状况描述，分析估计事件发展趋势，提出参考方法。在决议形成后，快速布署实施，跟踪落实情况，从而控制疫情或事件蔓延，使其立即稳定和下降。4、收尾恢复在突发事件降级或结束时，联动中心将进行事件收尾工作处理，以尽可能降低无须要损失，同时将快速开展从应急状态恢复到正常状态工作。首先组织进行相关控制方法，预防事件死灰复燃，也控制其它可能突发事件发生；其次将有计划地补充应急处理阶段所消耗战备资源，同时逐步恢复大家正常生活和生产。此阶段关键在于主动主动地进行事件扫尾，提醒注意事项，同时辅助计划和补充资源，从而控制事件立即回复正常，降低损失。5、总结提升在事件结束后，应进行科学总结，深入完善政策法规、预案和方案，同时组织开展应急处理技术研究和探讨，总结经验，制订针对性防控方法和演练方案，从而提升相关事件应急处理能力。此阶段最关键是总结经验教训，辅助制订针对性方法，修订和完善相关应急制度和步骤，形成更有效操作规范，从而提升处理能力。总体技术方案总体技术架构基于浏览器/服务器三层体系结构系统在技术上要求含有业务改变适应性、高度安全性、大容量数据存放处理等特点，引入数据仓库技术。系统利用交易中间件，将应用业务逻辑、表示逻辑和数据分为三个不一样处理层：表示逻辑（用户层）为第一层:它关键功效是实现用户交互和数据表示，为以后处理搜集数据，向第二层业务逻辑请求调用关键服务处理，并显示处理结果。业务逻辑（服务器组件）为中间层:这些组件由中间件管理，实现关键业务逻辑服务并将这些服务按名字广播，管理并接收用户服务请求，向资源管理器提交数据操作，并将处理结果返回给请求者——即用户或其它服务器。数据（资源管理器）组成模型第三层。比如关系数据库，负责管理应用系统数据资源，完成数据操作。服务器组件在完成服务过程中经过资源管理器存取它管理数据，或说请求资源管理器数据服务。在三层用户机/服务器模式上架构应用系统不仅含有了大型机系统稳定、安全和处理能力高等特征，同时拥有开放式系统成本低、可扩展性强、开发周期短等优点。交易中间件作为结构三层结构应用系统基础平台，提供了以下两个关键功效：负责用户机和服务器间联接和通讯提供一个三层结构应用开发和运行平台采取三层结构应用模型，为用分布式环境处理关键性业务提供了一个结构化处理方案。中间件应用设计应该是从异构计算资源中创建一个“虚拟主机”，在分布式应用系统环境下提供可管理相互关联资源。交易中间件提供了一个基础框架来建立、运行和管理一个三层用户机/服务器模式应用，无需从零做起，大大缩短了应用开发时间，提升了应用开发成功率。在三层结构应用模式中，表示逻辑层和资源管理器作为应用界面和数据管理者，在传统二层模式中相关标准和稳定实现，而作为三层结构关键中间层，因为其担负“承上启下”枢纽作用，在实际应用系统中饰演着至关关键角色。中间件在对事务完整性确保、对大规模并发处理响应、对异构系统互联透明支持，和对数据安全性保护等方面表现将成为应用系统成败决定性原因。中间件组成了三层结构基础，能够选择成熟商用中间件或自己搭建基础结构并开发相关功效软件。三层结构技术采取基于J2EE模式，以IBM企业应用服务器和中间件作为系统支撑。基于J2EE模式技术实现体系结构J2EE平台组成包含：EJB-J2EE中间层，完成商业逻辑；JAAS-J2EE处理认证和授权API;JavaConnectors-J2EE用于连接异种数据源API，对上层来讲是透明;JSP，JavaServlets-J2EE表示层技术，用于生成用户界面;JavaVirtualMachine-Java语言运行环境；JDBC-J2EE数据库访问；JMS-J2EE异步消息队列；JNDI-J2EE名字查找API，独立于目录服务器；JTS-J2EE用于处理交易API；RMI/IIOP-J2EE分布式对象通讯API，提供了和CORBA交互能力。J2EE三层结构系统体系结构以下图：图3.7J2EE三层结构系统体系结构图J2EE三层结构技术框架以下图：图3.8J2EE三层结构技术框架图系统分解应急指挥关键应用平台能够分解为地理信息（GIS）、决议支持（DSS）和运行支持（OSS）三个模块，在这三个模块下，包含系统管理、信息查询、值班管理、事件管理、经费管理、组织管理、物资管理、文档管理部门信息管理、人员管理等若干子系统。图3.9系统分解图在综合信息门户支持下，各子系统将协同工作为指挥领导、教授和工作人员提供对应服务，其中运行支持系统在操作型数据库支持下，关键完成在线操作多种支持服务，进行步骤管理等事务性操作；地理信息系统在地理数据库支持下关键提供地图服务，进行空间分析支持；决议支持系统可在数据仓库支持下进行数据分析、在线分析和模型分析等分析服务，为决议提供不一样维度和不一样形式支持服务。图3.10子系统服务分工子系统之间关系三个子系统相互关系如上图所表示，运行支持系统经过数据抽取、加载和转换（ETL）为决议支持提供基础数据，决议支持系统经过分析服务将结果反馈给运行支持系统；运行支持系统为地理信息系统提供动态数据，而地理信息系统则为运行支持系统提供地图服务；地理信息系统经过ETL向决议支持系统提供决议所需地理数据，同时经过空间分析服务反馈空间分析结果，而决议支持系统则为地理信息系统提供数据分析服务，反馈数据分析结果。图3.11子系统关系图系统架构图图3.12应用架构图在系统监控和管理平台及安全管理平台支持下，系统将经过数据交换平台获取公安系统、抢救中心、消防队、交警系统和各其它系统数据和信息，经过处理后进入数据中心。依据应用需要，数据中心将数据和信息分别布署到城市应急数据资料库、地理信息数据库和应急数据仓库。运行支持系统、地理信息系统和决议支持系统在数据中心支持下，提供对应服务给综合信息门户，为各渠道应用提供支持。系统经过综合信息门户，综合处理内网、外网、呼叫中心、邮件、短信息等不一样渠道访问和应用，为内部工作人员和外部访问人员提供信息统一门户，从而确保：系统对内对外服务渠道通畅；同一身份访问者经过不一样渠道访问时，系统提供一致信息。经过安全、数据、服务、应用四位一体化管理，进而实现基础信息平台、专业服务平台和综合决议平台应用需求。系统软硬件布署软件系统布署图3.13软件系统布署图硬件服务器布署图3.14服务器硬件布署图应急联动子系统设计综合信息门户设计概述综合信息门户（Portal）应用系统一个关键组成部分，经过综合信息门户，将城市突发事件应急指挥和决议系统多种应用系统、数据资源、网络资源等信息集成到一个信息管理平台之上，为指挥首长、业务教授和工作人员提供对应服务，并以统一用户界面提供给用户，快速建立对公众、对内部管理人员信息通道，使用户以统一、个性化、多渠道方法访问多种信息和服务；另外，作为城市应急联动系统统一用户界面，接收来自外界多种渠道服务请求，经过对后台服务调用，最终把结果依据不一样渠道以不一样表现形式响应给请求端，从而提升效率、响应性和适应能力。设计需求从用户角度看，系统将包含内部用户如工作人员、教授等，还包含到外部用户如公众、其它单位和机构等；从渠道角度看，应用系统包含外网、专网、局域网、呼叫中心、邮件、短消息等多个渠道，系统需要处理以下两个关键问题：怎样使内部用户和外部用户采取统一界面去访问渠道取得相同和一致信息？怎样使同一身份用户经过不一样渠道取得相同和一致信息？综合信息门户架构设计综合信息门户是在用户接入层，支持用户经过多个不一样渠道进行信息及服务访问，比如：内部网站、用户端、通信网关、呼叫中心等形式，并有效地整合突发所包含相关应用和信息，使内、外用户能够经过单一入口，使用多个渠道个性化地访问相关多种类型信息。从而保障同一身份用户从不一样渠道进入系统时，可取得一致信息。图4.1.1综合信息门户实现模型图4.1.1所表示，综合信息门户应用系统将形成用户端、接入管理、业务逻辑层和数据存放层，在安全平台提供身份认证服务支持下，系统可经过不一样渠道如内部网站、用户端、通信网关、呼叫中心等形式为多种用户终端提供服务，从而保障同一身份用户从不一样渠道进入系统时，可取得统一信息。综合信息门户架构是面向以后发展、含有很好整合能力架构，能够预防以后出现在数据、应用、用户界面层面孤岛，实现资源再利用。除了快速满足现有业务系统功效性要求同时，还能够快速将新应用布署到架构中来，共享架构所提供共用服务，在架构上满足了系统扩展性、高性能、高可用性等要求。建立综合门户系统能够：增强各部门人员协作能力，缩短事务处理周期，提升工作效率；使信息流和管理得到改善，而且拥有一致基础设施，所以可降低运行成本；统一数据和处理逻辑，支持多个渠道接入方法，统一进行展示；提供统一管理平台，提升管理水平；因为能够访问相关性更强信息而且可经过单一接入点访问应用和协作工具，所以可提升职员工作效率；在展示层面不一样应用系统间集成及互操作性，深入提升工作效率；安全性愈加好，而且可实现单点登录，所以可降低管理员密码数量并改善用户体验；统一显示外观和一致用户界面可降低培训成本；灵活度更高，快速响应环境改变，经过门户平台技术所提供给用和数据间松耦合特征，为以后动态增加功效模块提供基础；对现有网站资源利用和重用，保护现有投资，并实现系统平滑扩展。功效设计在安全管理平台支持下，综合信息门户将建立内部信息门户、外部信息门户和统一接入渠道支持。综合信息门户提供了一个统一client端操作接口。支持多个渠道访问模式，包含内部网站、用户端、通信网关、呼叫中心等。支持多个设备访问，如基于HTML及WAP协议浏览器，而不需要另一套支持WAP逻辑。即除了能够经过台式机浏览器以外，还能够经过其它方法访问应用门户。经过在多个标识语言中生成页面来支持移动式设备。而且支持以后访问模式扩展。综合信息门户内外信息和统一接入渠道支持共设计了11个模块，包含：内容和应用服务管理、智能通讯录管理、工作台管理、信息公布管理、呼叫中心管理、短信接入管理、智能邮件管理和输入输出管理、智能搜索功效、网站分析功效、定制服务功效。图4.1.2综合信息门户功效计划1、内容和应用服务管理综合信息门户提供了Web内容管理功效，包含内容创建程序、同意和公布等等。过程中包含定义内容类型、角色、参数、规范和工作流进程。能够实现对内容和应用服务进行编辑处理，提供和维护各类便捷模板，供不一样渠道和用户类型应用。Web站点中内容和页面设计。Web站点框架和导航。Web站点内容创建、编辑、核准和公布过程。Web内容管理使用浏览器方法，使用该工具不管是内容公布者还是内容查看者全部能够经过浏览器用户端实现网站内容管理，无需在用户机上安装其它用户端软件。2、智能通讯录管理在门户上提供了和安全中心统一用户管理系统集成，能够对于不一样用户针对应用需求，对其通讯方法进行捆绑。3、工作台管理对内部信息门户工作界面进行个人参数设置，在权限范围内定制自己应用界面。4、信息公布管理经过和应急指挥网站接口，对外部访问用户进行统一管理，同时依据安全权限开放信息，提供信息查询和浏览功效，另外，还可进行内容上传和修改、界面编辑等管理。5、呼叫中心管理经过呼叫中心接口，实现统一接警综合管理，包含：电话自动录音、来电自动识别、语音播放、自动追呼、传真自动接收、汇报统计等，将通讯功效和应用软件功效机结合在一起。6、短信接入管理经过短信网关，实现对短信编辑、发送和统计分析功效，同时提供短信通知模板辅助开展应急通知、告警等工作。7、智能邮件管理经过邮件接口，实现邮件自动识别和应答，同时提供多种工作邮件模板，完成调查、汇报、通知等基础工作。8、输入输出管理经过对输入输出设备接口，实现对其控制和管理，实现如LED信息编辑和播放等应用。9、智能搜索功效提供集成web内容搜索工具，包含：搜索引擎、文件索引程序和内容归类选项。搜索设备能够搜索当地文件和互联网内容。门户搜索功效能够使用内置文件过滤器为纯文本和其它200多个文件格式编写索引。门户服务器内置搜索引擎优化用于全文搜索中小型文件集，这种搜索要求很高精度。能够高效地应用最优异搜索算法，生成高质量搜索结果。搜索引擎支持自由文本查询，包含辅助查询和整词查询，它还支持通配符和按字段搜索选项。搜索查询还能够使用高级查询运算符（+或-）指示文件中必需存在关键字或文件中不能存在关键字。搜索引擎能够搜索任何语言文件，而且支持同义词和无用词列表。搜索结果包含文件汇总、归类和搜索结果归并。10、网站分析功效该功效可捕捉和分析门户站点数据,从而提供相关访问者流量、访问者行为、站点使用、站点内容和站点结构有用汇报。您可从预定义汇报元素中构建汇报,您也可搜集特定信息来量身定制属于您汇报。该功效可针对Web站点访问者流量、各应用使用情况和个性化规则调用情况进行统计分析进而生成汇报。比如，对查看门户网站页面用户进行排名，对经过某个特定Portlet访问特定服务情况生成统计图形。这些汇报是经过和门户网站生成日志进行集成来生成，管理员将日志导入到网站分析服务数据库中，然后经过图形界面创建汇报。11、定制服务功效能够提供定制内容和外观和页面布局等功效。另外，还提供工具许可页面专题教授按每个站点访问者需要和爱好将内容个性化。每个页面内容能够经过用户自己选择或管理员设置。管理员能够指定所要求一定特定服务内容，方便最终用户能够随意组织或除去它们。每个页面组能够有其自己颜色方案和列布局。经过门户页面个性化；布局、格式、颜色标准；随时添加应用组件。关键功效描述呼叫中心管理1人工座席服务和报警接收提供统一服务号码接收汇报信息，同时为指挥领导和教授提供相关应急咨询服务。汇报人、指挥领导和教授资料和位置信息、汇报事宜、事件情况信息等自动屏幕弹出，并和呼叫转移绑定；提供用户基础信息、历史信息、交易信息、语音步骤轨迹信息等信息随呼叫转移能力；进行应急业务咨询（查询）服务，配合坐席界面对应提供常见问题集、事件状态等相关信息可随时调用。自动接收电话、传真、EMAIL汇报和其它通告信息，由坐席人员统一依据步骤进行派发，各对应部门接收处理；信息反馈服务，对于对应部门待处理事项（完成及未完成）进度及处理方案可反馈坐席前端，指挥领导二次电话了解进度时，坐席人员应能够进行回复。2呼叫控制包含座席间呼叫转移、自动语音转座席、座席转移至自动语音、外线呼叫转移、呼叫保持和恢复、呼叫应答和挂机、三方通话、多方会议、座席监听和会议监听、语音信箱、自动总机等功效。3电话自动呼出和追呼可依据应急业务需要完全自由定制多个呼出计划，比如：给相关人员发电话通知，通知相关人员快速到现场，对紧急情况相关责任人和教授电话进行列表，并对呼出时间进行计划，呼出后可选择提供自动语音服务或人工服务，可统计呼叫历史和结果。4交互式语音应答可提供图形化语音步骤编辑器，语音步骤定制简捷、快速，支持定时（实施计划）切换语音菜单，并提供丰富语音及其控制功效，能完全满足用户服务需要，支持TTS文语转换语音技术和ASR自动语音识别技术，可对语音编辑和管理。5呼叫统计和报表可进行详尽呼入、呼出、语音、座席服务统计，提供自助语音服务业务统计报表，和座席服务业务统计报表。6录音可进行不间断全程录音，并对指定呼叫录音，同时可进行录音资源管理。7系统监控和管理由班长席负责监控坐席状态，能够监听坐席和汇报人通话、对汇报人通话进行录音、播放录音、监督坐席员状态、强制插入坐席和用户通话、对坐席电话强制拆线、强制签出、强制示忙和强制示闲等功效，系统可对座席线路工作状态、语音资源线路工作状态、语音服务和座席服务进行实时监控。同时，可实时统计显示系统运行信息、呼叫量曲线实时图，并对系统参数统一配置。智能EMAIL智能EMAIL是联动中心和其它部门或公众交流一个渠道，同时也是内部工作沟通、文件实时交互传输一个路径。可提供EMAIL接入和收发，提供获取内外发送电子邮件接口，并为值班人员提供邮件收发、查询支持EMAIL分拣和回复。可提供各类EMAIL工作模板，如固定格式EMAIL信息调查、咨询等功效，经过EMAIL开启对应步骤，实现智能分拣和自动回复EMAIL管理和统计分析，向管理者提供和业务相关EMAIL统计结果。信息公布管理城市应急联动中心需要依据信息披露要求分别提供给政府职能部门内部和社会公众。突发事件信息公布分内网公布和外网公布，内外网组建是严格根据政府相关安全部门要求组建，实施严格内外网物理隔离，内网数据传送到外网进行公布，不能够直接经过网络进行传输。为了做到突发事件向外网公布，系统需要提供数据导出和电子开关方法，将符合要求数据生成指定格式和指定结构文件，然后在外网WEB服务器定制网页，并公布供一套接收数据和公布数据方法，来实现数据外部查询。专网公布建立一个面向社会、面向政府各部门内外正确、立即突发事件信息公布体系，针对各部门和各类用户提供不相同级和层次应急信息。外网公布建立一个面向社会、面向联动中心内外正确、立即突发事件信息公布体系(应急指挥网站)，针对民众、企业、厂商、市场等社会各界提供丰富应急处理、安全防护、事件状态和范围真实。公布信息预处理为信息处理人员提供工具，来排版、编辑、预览、审批和上载公布信息。地理信息系统（GIS）系统开发目标GIS技术在城市应急联动中心应急指挥和决议系统中应用表现在五个方面：空间数据库（图形库）管理；相关子系统需要电子地图技术应用；相关子系统需要空间分析和网络分析技术应用；数字高程模型（DEM）技术用于灾情评定；基于IntranetGIS技术应用。具体来说，系统开发目标是建立地理信息系统，结构网络化地理信息系统和全球定位地理指挥系统平台环境，并实现以下功效：创建GIS数据库和数据仓库，并实现对数据和数据库管理维护；绘制专题地图，实现数据可视化；实现多种空间查询服务，如模糊查询、查找最近、周围查询、地理位置描述等；提供通用空间分析服务，如缓冲区分析、网络分析、DEM分析、图层叠置分析；提供突发事件专业模型研究，支持资源计划和调度、报警处理和反馈、现场情况分析展现等；提供多种信息公布功效。系统体系结构依据地理信息系统采取三层体系结构，将整个应用划分为三个逻辑上分离层，每一层全部有一套定义好接口。第一层是数据层，包含数据库层和数据维护层；中间层由应用逻辑组成，封装业务逻辑和对数据库访问，经过地图服务方法向应急指挥系统中其它功效模块提供GIS支持。该层能够分为公用数据接口层和专业服务接口层；第三层是表现层，能够为决议支持系统提供GIS空间查询、空间分析支持等。和两层结构相比，三层结构增加了中间层，即应用逻辑层。中间层基础上是用户为了获取数据需要（经过表示层）调用代码。表示层接收到数据后将其格式化并显示出来。这种应用逻辑和用户界面分离极大提升了应用设计灵活性，我们能够在不改变应用逻辑情况下采取不一样用户界面，只需要应用逻辑提供给表示层一个明确接口。地理信息系统体系结构图3.2.1所表示：图4.2系统数据分析系统数据特征、类型和表示在地理信息系统中，地理数据通常含有三个基础特征：属性特征（非定位数据），表示实际现象或特征，比如变量、等级、数量特征和名称等等。空间特征（定位数据）：表示现象空间位置或现在所处地理位置。时间特征（时间尺度）：指现象或物体随时间改变，其改变周期有超短期、短期、中期、长久等等，图3.7-2所表示：图4.2.在地理信息系统中，根据其特征，数据可分为三种类型：空间特征数据（定位数据）、时间属性数据（尺度数据）和专题属性数据（非定位数据）。其中，时间和专题属性数据结合在一起共同作为属性特征数据，而空间特征数据和属性特征数据统称为空间数据（或地理数据）。空间特征数据：统计是空间实体位置、拓扑关系和几何特征，这是地理信息系统区分于其它数据库管理系统标志。空间特征指空间物体位置、形状和大小等几何特征，和和相邻物体拓扑关系。位置和拓扑特征是地理或空间信息系统所独有，空间位置能够由不一样坐标系统来描述，如经纬度坐标、部分标准地图投影坐标或是任意直角坐标等。人类对空间目标定位通常不是经过记忆其空间坐标，而是确定某一目标和其它更熟悉目标间空间位置关系，而这种关系往往也是拓扑关系。如一所学校在哪个路口或哪条街道。专题特征数据：指是地理实体所含有多种性质，如地形坡度、坡向、某地年降雨量、土地酸碱类型、人口密度、交通流量、空气污染程度等。这类特征在其它类型信息系统中均可存放和处理。专题属性特征通常以数字、符号、文本和图像等形式来表示。时间特征数据：时间属性是指地理实体时间改变或数据采集时间等。严格地讲，空间数据总是在某一特定时间或时段内采集得到或计算产生。因为有些空间数据随时间改变相对较慢，所以有时被忽略；有些时候，时间能够被看成一个专题特征。在地理信息系统中，空间数据表示能够细分为：类型数据：比如考古地点、道路线和土壤类型分布等；面域数据：比如随机多边形中心点、行政区域界线和行政单元等；网络数据：比如道路交点、街道和街区等；样本数据：比如气象站、航线和野外样方分布区等；曲面数据：比如高程点、等高线和等值区域；文本数据：比如地名、河流名称和区域名称；符号数据：比如点状符号、线状符号和面状符号（晕线）等。空间数据表示图4.2.3所表示：图4.2.3地理信息系统中多种数据和其表现系统数据步骤分析1．系统顶层数据步骤系统顶层数据步骤图4.2.4所表示：图4.2.4GIS系统顶层数据步骤2．系统内部数据步骤系统内部数据步骤图4.2.5所表示：图4.2.5运行支持系统(OSS)需求分析运行支持系统（OSS）是以工作流技术为支撑，支持预案和方案步骤管理、值班运行、演练模拟、设备管理等操作类和事务性工作。OSS支持基础信息平台、专业服务平台和综合决议平台中在线操作功效。体系结构运行支持系统体系结构包含：数据层、逻辑层和表现层。图4.3.1所表示：图4.3.1OSS系统体系结构功效设计数据层数据层是系统对业务数据进行统一组织、集中管理平台，它为逻辑层提供规范、高效数据服务，实现业务数据充足共享，是整个系统基础。逻辑层业务逻辑层是系统业务处理逻辑平台，它经过对业务层数据原子服务调用访问业务数据，实现不一样功效模块，满足不一样业务需求。在交易中间件支持下，该层完成知识库管理、值班管理、预案管理等业务逻辑功效。表现层在表现层，OSS将依据平台计划要求，展现基础信息管理平台、专业服务平台和综合决议平台相关界面。表现层由交互界面、界面控制逻辑和业务过程调用组成。交互界面负责系统用户数据输入和系统输出数据表示；界面控制逻辑负责交互界面间逻辑控制；业务过程调用负责调用业务平台中业务过程，完成对应业务功效，多个界面逻辑能够重新组合成新界面逻辑。关键功效描述步骤管理1、工作流技术针对城市联动中心计算机应用已不仅仅停留在诸如文档处理、公文流转和信息公布等这些简单业务层面上。越来越多要求将信息技术应用扩展到关键业务中。关键业务普遍特征是：（1）是企业或部门赖以生存；（2）业务过程往往由很多业务活动组成，业务逻辑和业务规则复杂；（3）业务完成依靠于其中众多业务活动之间交互和众多业务人员协作参与；（4）包含到数据量常常是海量数据；（5）假如能将信息技术合适地应用到这些关键业务中，不仅仅能够提升工作效率，还能够降低犯错可能性。工作流技术所含有协调本质决定了其在关键业务信息化过程中将饰演关键角色。城市指挥和决议系统中工作流技术应用图4.3.2所表示：4.3.2工作流技术2、工作流引擎针对关键业务应用开发离不开工作流技术支持。经过对关键业务实际开发需求分析，在传统关系数据库基础上，提出了一个适适用于关键业务开发基于关系结构工作流引擎框架结构。此工作流模型由机构模型、信息模型和控制模型三部分组成。所谓基于关系工作流引擎指是工作流引擎中数据模型（即机构模型和信息模型）全部经过关系结构来表示；控制工作流引擎运作多种程序逻辑（即控制模型）也是经过常规关系数据库管理系统中所提供存放过程、包和触发器等机制来实现；同时，事务并发控制也经过数据库系统所提供机制来实现。以下是采取关系结构级理念来设计工作流引擎原因，并具体地给出了相关机构模型、信息模型和控制模型设计原理和具体表示和实现方法。1）工作流引擎数据模型基于关系结构轻量级工作流引擎数据模型包含机构模型和信息模型两部分。机构模型描述是企业或部门组织机构关系，信息模型则定义工作流引擎中所用到多种控制数据。经过数据模型，能够方便地描述关键业务业务规则、活动依靠关系和任务指派等特征。它们全部经过统一关系结构来定义。2）工作流引擎控制模型基于关系结构工作流引擎数据模型包含机构模型和信息模型两部分。机构模型描述是企业或部门组织机构关系，信息模型则定义工作流引擎中所用到多种控制数据。经过数据模型，能够方便地描述关键业务业务规则、活动依靠关系和任务指派等特征。它们全部经过统一关系结构来定义。工作流引擎控制模型将机构模型和信息模型有机地结合在一起，它依据其中定义业务规则对业务过程中各项业务活动流转和任务指派等工作进行控制和协调。控制模型是工作流引擎控制中心。工作流引擎应用系统框架结构如4.3.3所表示：图4.3.3工作流引擎应用框架如上图所表示，“可视化建模工具”即采取一套合适图示化工具来对业务过程进行描述，然后将其转换成如机构模型和信息模型中所述及关系结构，从而建立起工作流引擎数据模型。所以，“可视化建模工具”是工作流引擎在结构时定义中心，而“引擎控制器”则是工作流引擎在运行时控制中心，它负责工作流引擎在运行时协调、调度和控制功效。依据具体应用开发环境不一样，工作流引擎在应用框架中为不一样类型应用提供了不一样接口，比如C/C++接口、Java接口和直接基于数据库通信协议接口，从而为不一样类型应用和工作流引擎交互提供了方便。应用框架中“应用数据”则由具体应用逻辑自行管理，工作流引擎并不关心这部分数据格式。3）引擎控制器引擎控制器是工作流引擎在运行时控制中心，图.5调度中心调度中心接收从外部接口发送过来相关步骤控制请求（如业务初始化、获取任务和结束任务等），然后依据不一样请求类型调用对应处理模块完成和此次请求相关操作并将结果返回。任务管理任务管理关键依据调度中心指示完成诸如任务创建、任务状态转换和相关数据维护等工作。转发控制当应用发出“结束任务”外部请求时，该请求将触发调度中心开启“转发控制”。转发控制关键依据在工作流数据模型中定义后转发规则，后转发规则定义了目前活动和其后继活动之间关系。开启控制开启控制负责常规自动活动所对应自动实施体开启并对其活动进行监控。4）工作流管理功效结构图图3.4.5知识库管理知识库管理模块能够提供工具进行教授知识共享和知识交流，同时可将各方面最好实践经验集中起来，对其进行管理维护，形成应急知识库，然后开放给教授和参谋。可使得教授参谋能够经过知识库处理应急处理中上碰到多种问题，以深入提升支持效率，提升应急处理能力。1、知识库管理功效结构图图3.4.6知识库管理功效接警管理接警管理模块统计事件汇报信息，核实事件汇报信息，并依据步骤将事件汇报转发给教授委员会组员，进行调查评定，获取评定结果，进行信息公布或请示汇报。1、接警管理功效结构图图3.4.8决议支持系统（DSS）决议支持系统概述本系统所设计决议支持系统（DSS）是以数据仓库技术为关键，基于数据挖掘和建模技术，经过分析来支持指挥中心应急业务处理，DSS系统建设关键工作在数据仓库建立、分析专题确实定和分析模型建立。DSS、OSS及GIS系统经过综合信息门户为指挥中心提供基础信息平台、专业服务平台和综合决议平台相关服务，从支持层次上看，决议支持系统可在应急业务闭环管理步骤不一样阶段，支持以下多个层次分析应用：数据描述和直观展现静态报表查询和动态统计多维分析模型分析主动分析和估计体系结构图4.4.1DSS系统技术架构系统自下而上分为四个层面：即数据采集层、数据存放层、数据分析层和数据展现层。其中数据分析层由分析中间件、科学分析工具及分析服务组成，实现即席查询、自定义报表、OLAP、数据挖掘和专题分析功效。系统功效设计模型库管理对模型和指标进行分类描述，可对其参数进行维护，同时可从外部导入或更新相关模型和指标，也可导出内部建立模型和指标。多维模型组织:图3.4.2多维模型建立及数据展示从技术角度看较传统方法关键包含以下两种新具体实现方法：MOLAP方案以多维方法来组织数据，以多维方法来存放数据；ROLAP方案以二维关系表为关键表示多维概念，经过将多维结构划分为两类表：维表和事实表，使关系型结构能很好地适应多维数据库表示和存放。在多维数据模型表示方面，多维矩阵比关系表更清楚且占用存放更少，面经过关系表间连接来查询数据库ROLAP系统，系统性能成为最问题。MOLAP方案比RPLAP方案要简明，索引及数据聚合能够自动进行并自动管理，但同时丧失了一定灵活性。ROLAP方案实现较为复杂，但灵活性很好，用户能够动态定义统计和计算方法。另外能保护在已经相关系数据库上投资。因为两种方案各有优劣，所以在项目中，往往将MOLAP和ROLAP结合使用，即所谓混合模型（HOLAP）。利用关系数据库存放历史数据、细节数据或非数值数据，发挥关系数据库技术成熟优势降低花费，而在多维数据库中存放目前数据和常见统计数据，以提升操作性能。在设计仓库信息模型时，应采取面向对象设计思绪，先依据需求调查情况，确定分析专题和层次，同时明确各角色在统计和分析信息时关心关键维对象和维层次。在设计分析专题中，本着尽可能使各维交叉取值全部有意义标准和尽可能使维各层全部能够向上汇总标准设计，因为只有各维交叉取值有意义，它们度量才有意义，维各层能够向上汇总而且向上汇总值有意义，才能支持在线分析型报表上钻、下钻。在确定分析专题和维后，再确定事实表。一个分析专题对应一个或多个事实表，一个子专题在本系统中和事实表一一对应。事实表中关键包含两部分字段信息，即维字段和度量字段。在每个事实表中描述了和每个子分析专题关联维对象和度量，维对象关键是定性描述子专题观察角度，度量关键是定量表示该子专题在各维约束条件下部门关心量值。在设计上，星型模型效率高、可扩展性好，将采取星型模型设计分析专题，如上图示。设计时对维和维层次进行合理划分，确保模型可扩充性，同时提供数据合适聚集，满足用户通常查询，并支持分析型需求。专业模型建立专业模型关键包含临床研究、流行病学研究和试验室研究所采取分析模型和方法，包含多种流行病学指标和统计模型，同时还包含资源计划、路径计划、决议树等决议模型。方法库管理对中国外各类突发事件具体控制方法和方法进行编辑、分类和整理，可进行快速查询。报表管理（自定义报表）系统一个关键功效在于满足日常生产报表需求。报表制作是一项费时工作，而且业务部门往往会随时对报表提出新需求。系统提供稳健、高效率企业报表工具，用于快速构建高质量基于动态或静态数据报表。经过向导驱动方法，提供一个图形布局编辑器，依据申明、以文档为中心开发模型构建复杂报表。能够快速生成所需报表，降低报表开发复杂度，该工具提供高级性能，以帮助用户处理大多数富有挑战性包含复杂查询和编程逻辑报表。系统提供强大开发和布署平台，在无和伦比可伸缩、安全环境下构建和公布动态生成网络报表，使您访问任何数据，以任意格式公布，而且随地可用。辅助分析工具提供辅助分析工具，对疾病模型进行采样、探索、修正、建模、评定等过程仿真分析研究，从而确定模型，在应急状态下使用。统计查询（即席查询）可进行基础统计和查询，并可设定统计指标和查询参数。系统实现直接基于数据仓库关系型数据库进行分析查询分析工具，提供多种向导式界面、图形查询生成器、联机帮助、提醒窗口等，用户无需经过专业培训，经过简单鼠标拖拉操作即可实现即席查询、汇报生成、图表生成、深入分析和公布等功效。系统能够帮助最终用户在不需要了解SQL或数据库结构情况下，建立查询、汇报，和实施功效强大搜索。只需拖拉式操作，就能直接访问所需数据，和改变工作面布局。经过使用直观循序渐进Wizard界面，能够建立条件过滤器和计算项目。无须担心数据类型、括号、函数名或数据值。能够充足利用数据库提供性能优化技术，能够动态地生成性能优化SQL查询，为数据即席查询、深入和旋转提供最好性能。数据挖掘数据挖掘能够帮助教授发觉在数据中隐含有用信息。DB2数据库中集成了数据挖掘功效，它避免了把大量数据卸载到外部专用分析服务器复杂过程。全部数据挖掘功效全部嵌入到了DB2数据库中，这么，数据准备、模型建立和模型评定活动全部在数据库内进行。因为DB2在关系数据库中实现了数据挖掘各个阶段，所以，数据挖掘各个阶段在生产效率、自动化、集成化方面得到了重大改善。生产效率方面重大改善是因为避免了把海量数据卸载到外部专用数据挖掘服务器上、和将数据挖掘结果重新装载到数据库中而取得。数据交换平台概述城市应急联动系统总体设计目标是实现对突发甚至是潜在城市应急事件动态监测和预警；面对突发事件，要提供高效、统一、可靠信息交换平台，从而帮助联动中心调度和协同各职能部门，统一处理、统一行动。所以就必需建立以城市应急联动中心为关键，覆盖政府各职能部门信息系统三级或多级数据交换网络平台，图4.1.1所表示。图4.4.1数据交换网络平台数据交换平台逻辑结构从交换逻辑上我们将各应用系统之间交换划分成三个层次，即应用层（包含多种应用系统）、交换层（交换系统）和通讯层（网络）。图4.4.