应急调度方案
前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇应急调度方案范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。
应急调度方案范文第1篇
中图分类号：U492.3+36.3 文献标识码：A 文章编号：1001-828X（2013）05-0-01
一、危险品物流事故应急资源调度概述
随着我国工业的发展，危险品的生产量和运输量每年均在快速增长，由此带来的危险品安全事故频发。事故发生后的紧急救援工作，对于抢救人员、挽回经济损失的重要性不言而喻。目前由于相关信息和软件支持不够，评估主要依靠救援人员经验进行。救援评估的目的主要是确定救援装备的类型、数量等，救援装备经常需要跨区域调度，如何有效调度各类应急资源以达到及时有效救援的目的，是目前的难点。
二、危险品物流事故应急资源调度存在问题
根据项目组对广东省消防总队的调研，现存问题可以概括为：
1.有设备、有资源、无科学的应急资源调度方法。
2.缺乏有效的应急调度联动机制。
3.政府的相关法律、政策不完善。
4.应急救援信息化程度不够高。
5.应急救援智囊的缺乏。
三、基于弱经济性的单事故点问题应急资源调度研究
1.单一事故点应急救援问题的系统性分析
区域内只有一个事故点，由于事故规模较大，单一救援点无法满足其应急需求，需要调集周围消防设施点的应急资源予以救援。为了简化研究，本一定假设：假定运输道路是通畅的，不会因为堵车等路况影响应急资源调度时间；所有应急事故所需要的应急资源量是可估计的，即应急资源需求量是确定的，不会出现临时变动情况。危险品应急资源调度的首要目的是尽快救援，保证应急资源调度时间是第一要求；同时危险品运输事故的应急救援工作不同于大规模自然灾害的资源调度，全区域内通行的危险品运输车辆数量庞大，发生事故的可能性比较高，所以需要同时考虑其它可能发生的应急救援工作，为再次发生事故预留应急救援空间，需要从系统稳定性的角度去考虑该问题。综上所述，危险品应急救援工作，需要满足以下目标[2]：
（1）救援时效性：应急资源调度时间最短。
（2） 系统稳定性：出救点最少。
其中为某一调度方案。
学者刘春林[2]针对自然灾害的应急资源调度问题展开了研究，采用近似穷举法的方法，按照各个出救点的资源量进行排列，得到一个调度方案，之后删除原序列中最后一个出救点，重新排列求解，循环直至无解，在所有方案中选择最优方案。
2.基于弱经济性的调度方法
关于对于一些有资源冲突或者类似方案，一些学者采用不同方法对救援方案进行调整。应急物流的弱经济性即在进行应急资源调度时不考虑成本因素，只研究应急资源调度时间最短的问题，“不惜一切代价救援”。学者陈达强[3]提出救援成本由运输成本和人员伤亡成本两部分组成，人员伤亡率与应急资源调度时间成一定比例，而运输成本与出救点数量直接相关，所以救援成本与应急时间最早、出救点数目最少两个目标密切结合，利用救援成本调整救援方案，不仅可以使得成本降低，更重要的是可以解决多重方案下寻优问题，该思路具有启发性。
利用文献[2]中提到的循环求解方法得到一系列调度方案，之后采用弱经济性因素对方案进行调整，得到最优方案。
四、基于经济损失程度的多事故点问题应急资源调度研究
第三部分已经讨论了单个事故点的调度方法，在此基础上进一步讨论，当同一区域内同一时间段出现两场以上事故的应急资源调度问题。对多事故点问题进行资源调度，必然面临着不同事故点对同一资源（即关键资源）的争夺问题，如何有效分配调度关键资源，是多事故点多资源问题应急资源调度的关键。学者王苏生[4]等提出以公平性原则进行资源分配而当两场事故由于发生地点所处经济水平差异而导致事故后果严重程度不同，事故产生的影响与损失相差巨大时，本文拟采用基于事故经济损失程度的调度规则。
五、总结
本文在研究危险品物流事故应急现状的基础上，重点考虑弱经济性与事故经济损失程度等经济因素在危险品物流事故应急资源调度中的应用，提出了针对单个事故点和多事故点问题的简便易行的调度方法。
参考文献：
[1]赵来军，吴萍，许科.我国危险化学品事故统计分析及对策研究[J].中国安全科学学报，2009，19（07）：165-170.
[2]刘春林，何建敏，盛昭瀚.应急系统多出救点选择问题的模糊规划方法.管理工程学报，1999，13（04）： 21-24.
应急调度方案范文第2篇
【关键词】民用航空 应急物资调度 保障能力受限 时效性 物资匹配度
1 引言
民航因其运输时效快、对沿途设施需求较低等特点，常被用来执行重大灾害下的应急物资调度任务。针对单一运输方式的应急物资调度问题，国内外学者外开展了广泛而深入的研究[1-6]，但这些研究并不适合多灾点、多出救点、多救援物资的民航应急物资调度问题，且对成本等其他非时效性因素关注较多，民航的参与往往意味着灾情的严重和紧急，需要在短时间内从多个救灾机场调运多种物资到多个受灾机场，对时效性的关注度远超对成本等其他因素的关注。
针对民航应急物资调度问题，夏正洪等[7]和阮俊虎等[8]探讨了直升机应用于灾后应急救援的资源分配和调度问题，邵荃等[9]以飞机性能和物资数量作为约束条件，以运输时间和救灾效果为优化目标，建立多机场协同的民航应急物资优化调度模型，提出一种针对多目标优化的改进元胞遗传算法用以求解模型。李桂香等[10]利用多个民航应急救灾物资的供应点与需求点和多种应急救灾物资调度来组建多目标规划模型，应用遗传算法对最优物资调度方案进行求解。此类模型与民航运行实际结合较紧，可有效应对多受灾机场、多救灾机场和多救援物资的民航应急物资调度问题，但却忽略了重大灾害给民航运行带来的影响：虽然民航对沿途设施需求较低，但其正常运行极大依赖着机场的保障，重大灾害极有可能削弱受灾机场保障能力，救援飞机不得不牺牲相当的物资载运能力以应对受灾机场保障能力的降低，进而降低民航应急物资调度的整体效率。
因此，本文将针对多受灾机场、多救灾机场和多救援物资的民航应急物资调度问题，考虑受灾机场的保障能力对飞机的物资载运能力的限制，建立保障能力受限下的民航应急物资调度模型，并以物资的匹配情况和运输的时效性为指派依据，求解调度模型。
2 保障能力受限下民航应急物资调度模型
2.1 民航应急物资调度描述
存在若干救灾机场（运出物资）和若干受灾机场（接受物资），当接到运送救援物资的任务后，飞机在救灾机场装载救援物资若干，接受所需地面保障（如加油等）后前往受灾机场，在受灾机场卸载救援物资并接受必要的地面保障，返回有物资储备且具有保障能力的救灾机场，如此往返直至救援任务结束。建立模型之前，先做以下假设：
（1）每个救灾机场的物资供应量和受灾机场的物资需求量都是已知常量；
（2）执行救援任务的飞机数量为已知常量，均可正常使用，有充足的空勤人员；
（3）飞机仅在救灾机场和受灾机场之间飞行；
（4）救援物资在机场的装卸载时间和地面保障时间考虑为零；
（5）飞行条件均为标准条件；
（6）飞机装载救援物资时不存在体积限制；
（7）所有救灾的飞机为同一类型。
2.2 地面保障与飞机的载运能力
在应急物资运输中，当飞机没有故障时，只要具备足够的燃油和人员以及必要的航行资料，就可执行救援任务。人员和航行资料的需求较易得到满足，而受灾机场由于地处灾区，可用燃油往往得不到有效补充，大多只能依靠存量燃油来保障救援飞机；当存量燃油消耗殆尽后，后续救援飞机前往受灾机场时必须携带回程燃油；机载燃油的增加可能降低飞机的最大业载（乘客、货物、行李和邮件的重量之和，Payload，PL）。
飞机的最大业载受修正后的基本总量（Dry Operating Weight，DOW）、最大无油重量（Maximum Zero Fuel Weight，MZFW）、最大起飞重量（Maximum Takeoff Weight， MTOW）、最大着陆重量（Maximum Landing Weight，MLW）、起飞油（Takeoff Fuel Weight， TFW）和航段油（Air Cost Fuel Weight， ACFW）等限制。
标准条件下，国内飞行的每段航程所携带的额外燃油仅与机型有关，与航程和航时无关；当不考虑滑行油和备份油时，起飞油就可简单地看作是去程燃油（Outbound Fuel Weight，OFW）和回程燃油（如携带，Inbound Fuel Weight，）之和，公式（1）就可简化为公式（2）：
（2）
2.3 保障能力受限下民航应急物资调度模型的建立
应急物资调度中，民航的参与往往意味着物资被送达的紧迫性，调度方案对运输成本等其他因素的关注度远小于运输时效性，因此，本文针对多救灾机场、多受灾机场、多种救援物资的民航应急物资调度问题，考虑受灾机场保障能力受限的情况，以调度方案的执行时间最短为决策目标，建立保障能力受限下民航应急物资调度模型。
符号说明：
i：救灾机场序号，i=1，2，3，…，m；
j：受灾机场序号，j=1，2，3，…，n；
k：物资种类序号，k=1，2，3，…，q；
a：飞机序号，a=1，2，3，…，p；
Sjk：机场i中第k种物资的库存量；
Dik：机场j对第k种物资的需求量；
Cai，j：飞机a从机场i飞往机场j的所需时间，Cai，j=Caj，i，不考虑飞机的延误等；
FSj：机场j的可用燃油；
FBai，j：飞机a从机场i飞往机场j时的燃油消耗，FBai，j=FBaj，i，不考虑航程额外耗油的情况；
：飞机a的第b次运输任务，=（AT，），其中，i1（救灾机场）表示去程的始发机场，j（受灾机场）表示去程的目的机场，i2（救灾机场）表示回程的目的机场，AT表示飞机a的可用时间；
：飞机a的第b次运输任务中，去程时携带的回程油重量；
：飞机a的第b次运输任务中，从救灾机场i1向受灾机场j运输的第k种物资的数量，
式（3）表示调度方案的执行时间等于所有飞机的调度方案的执行时间的最大值，式（4）要求受灾机场的燃油消耗量不超过该机场的燃油储备总量，式（5）、式（6）和式（7）要求每架飞机每次飞行所携带的物资不超过式（2）中的业载限制，式（8）要求运往各受灾机场的各物资总量至少要满足该机场对该物资的需求，式（9）要求从各救灾机场运出的各物资总量不得超过该机场该物资的储备总量。
3 保障能力受限下民航应急物资调度模型求解算法
民航应急物资调度中，指派飞机执行运输任务时，不仅要考虑救灾机场和受灾机场间的物资匹配度（MEi，j），还要考虑救援的时效性（TLJIi，j，a和TLIJi，j，a），基于此，描述受灾机场对飞机所在救灾机场的吸引作用（GJIi，j，a）和救灾机场对受灾机场的吸引所用（GIJi，j，a），作为调度飞机执行运输任务时的依据：吸引作用越大的飞机、受灾机场和救灾机场组合，被指派的优先级越大。
3.1 飞机指派依据
救灾机场和受灾机场间的物资匹配度（MEi，j）表示从救灾机场向受灾机场的单次物资运送方案能否充分发挥飞机的最大载运能力，计算时需虑受灾机场的物资需求数量和救灾机场的物资库存量以及飞机的载运能力，如果能具体计算步骤如下：
用飞机到达救灾机场或受灾机场时间与所有飞机执行某次救灾运输任务的飞行时间的最大值间的关系表示飞机执行该次救灾任务的时效性，时效性越大表明调用该架飞机来执行此次救灾任务的时间效应越好。飞机从救灾机场运输物资到受灾机场的时效性（TLJIi，j，a）不仅要考虑受灾机场和救灾机场间的飞行时长，还需考虑飞机到达救灾机场的时刻，用TLJI表示相邻两个时效性间的时间间隔，具体计算步骤如下：
飞机从受灾机场飞往救灾机场的时效性（TLJIi，j，a）仅考虑受灾机场和救灾机场间的飞行时长，用TLIJ表示相邻两个时效等级间的时间间隔，具体计算步骤如下：
用物资匹配度和时效性的乘积表示救灾机场和受灾机场间的吸引作用，吸引作用越大，表明该架飞机被调用执行该次救援任务的优先级越高。受灾机场对飞机所在救灾机场的吸引作用（GJIi，j，a）和救灾机场对受灾机场的吸引所用（GIJi，j，a）分别由式（10）和式（11）计算：
3.2 模型求解算法
考虑受灾机场地面保障能力对飞机载运能力的限制，以受灾机场对飞机所在救灾机场的吸引作用（GJIi，j，a）和救灾机场对受灾机场的吸引所用（GIJi，j，a）为依据，求解应急物资调度模型，制定飞机指派方案，具体步骤如表1所示。
4 数值实验
现假设某省S发生重大突发事件，需动员民航从该省周边的4个省会机场（H、X、Z和W）运输救援物资（M1、M2、M3和M4若干）到该省的机场C和M，以开展救灾活动，用于执行救灾任务的飞机机型均为B737-800，图1显示的是4个救灾机场和2个受灾机场间的位置关系、飞行时长（分钟）和单程飞行所需燃油（吨），例如，机场M和机场X之间的“81/9.7”表示机场M和机场X之间的单程飞行时长为81分钟、所需燃油为9.7吨。
参与此次救灾任务的飞机均为B737-800，该机型修正后的基本总量（DOW）为42733 KG，最大起飞重量（MTOW）为75926 KG，最大着陆重量（MLW）为66360 KG，最大无油重量（MZFW）为62731 KG。机场H、X、Z和W中可用来执行救灾任务的飞机数量分别是2、2、2和2；机场C和M的存量燃油均为100吨；各机场对M1、M2、M3和M4的需求量（吨）或供应量（吨）则见表 2。
利用2.1的飞机指派依据，结合2.2中的算法，求解此类问题。其燃油消耗量随时间变化的曲线如图2所示，实验结果显示，机场C和机场M的存量燃油被消耗殆尽的时间分别为570分钟和985分钟，因此，图2中机场C和机场M的曲线在第570分钟和985时达到最大值，趋于平稳。
机场C和机场M的物资需求被满足的时刻分别为3561（分钟）和3784（分钟），受灾机场中各物资的调入量随时间变化的曲线如图3所示。
从图3中可以看出，受灾机场C和受灾机场M的物资调入量的增长率分别在570分钟和985分钟以后有明显的降低，主要因为在570分钟和985分钟时，受灾机场C和M的燃油消耗殆尽，后续救灾飞机不得不在前往救灾机场时携带回程燃油，被迫削减飞机的最大业载，进而降低了物资运输的效率。
5 结论
针对多受灾机场、多救灾机场和多救援物资下的应急物资调度问题，从民航应急调度的实际出发，考虑受灾机场保障能力受限的情况，建立民航应急物资调度模型；以运输的时效性和物资满意度为指派依据，提出相应的求解算法；实验结果显示，受灾机场C和M的保障能力限制性影响在第570分钟和第985分钟后开始显现，其物资需求在第3561分钟和第3784分钟时被全部满足，模型较为客观地考虑了受灾机场的保障能力对应急物资调度的影响，可以制定出符合实际的民航应急物资调度方案。
参考文献
[1]柴秀荣，王儒敬.多出救点、多物资应急调度算法研究[J].计算机工程与应用，2006，46（06）：224-226.
[2]Mete H O，Zabinsky Z B.Stochastic optimization of medical supply location and distribution in disaster management[J].International Journal of Production Economics， 2010，126（01）：76-84.
[3]甘勇，吕书林，李金旭，等.考虑成本的多出救点多物资应急调度研究[J].中国安全科学学报，2011，21（09）：172-176.
[4]Berkoune D，Renaud J，Rekik M，et al. Transportation in disaster response operations.Socio-Economic Planning Sciences，2012，46（01）：23-32.
[5]Yang Z，Zhou H，Gao X，et al. Multiobjective Model for Emergency Resources Allocation[J]. Mathematical Problems in Engineering，2013， 2013（05）.
[6]Altay N.Capability-based resource allocation for effective disaster response.Ima Journal of Management Mathematics，2013，24（02）：253-266.
[7]夏正洪，潘卫军.多救援直升机多目标分配与航迹规划研究[J].科学技术与工程， 2013，13（34）：10226-10231.
[8]阮俊虎.应急医疗物资直升机与车辆联合运送优化[D].大连理工大学，2015.
应急调度方案范文第3篇
关键词:应急预案;服务流程;智能平台;SOA
中图分类号:TP311文献标识码:A文章编号:1009-3044(2010)21-5837-03
The Study of Emergency Plan Intelligent Platform and It's Application
LIAO Ling-song
(Communication Information Center of State Administation of Work Safety, Beijing 100013, China)
Abstract:Emergency rescue has complex business processes, which makes high demands on the preparation and management of emergency plan. According to the trend of information technology development and SOA framework thinking, the infrastructure and application mode of emergency plan management platform is studied. based on the infrastructure of service and service process, a "hot swap" capability service management platform is designed,which enables service personnel to customize the emergency procedures at any time, dynamic access to business applications, and meets the requirements of the emergency response timely.
Key words: emergency plan; service process, intelligent platform; SOA
1 应急预案智能平台概念
应急预案是指政府或生产单位为了能够快速有效地应对突发事件,根据事件的特点、以往应对类似事件的经验、对事件结果的预测分析而预先制定的行动方案。在应急预案中,规定了突发事件应急处置方法与步骤,明确了各部门的职责,使各部门在事件发生后有条不紊地开展应急工作,提高了应急处置的效率。
传统的文本方式的应急预案在使用中难以充分利用信息化建设成果,发挥信息系统的辅助决策功能,指挥人员面对现场复杂局面,很难作出正确的应急方案;当前正在试验的数字预案,基本上属于信息大集中的模式,所有的应用和数据集中在一个平台节点上统一维护管理,信息很难与实际现场同步,同时系统应用是事先设置好的,不能随着突发事件的变化而更改系统功能流程,系统应用也不能根据需要随时迁移到现场处理。
因此,开发一种具有“热插拔”能力、具有移动性特点的应急预案平台就显得非常有必要,这也是应急预案智能平台被提出的根源。
应急预案智能平台是在职责规定、步骤安排、资源调集、信息流程等重要环节严格遵循应急预案规定的前提下,以应急预案为依据,当突发事件发生后,可以根据事件信息和其他与之相关的数据信息,借助于应急平台提供的信息化手段,快速生成直观、有效的行动方案,并可以对方案进行实时调整的软件系统。应急预案智能平台把调度指挥和应用功能剥离开来,平台本身关注于应急流程的管理,而与流程相关的系统应用功能独立部署于平台之外,根据需要随时接入平台,这样平台就具有动态调整业务流程的功能,也具有高度的移动性,并可多点部署,随处运行。
2 应急预案智能平台技术架构
应急预案智能平台基于SOA架构,其核心是服务流程引擎。
SOA核心思想是服务,业务被划分为一系列粗粒度的业务服务和业务流程。业务服务相对独立、自包含、可重用,由一个或者多个分布的系统所实现,而业务流程由服务组装而来。一个"服务"定义了一个与业务功能或业务数据相关的接口,以及约束这个接口的契约,如服务质量要求、业务规则、安全性要求、法律法规的遵循、关键业绩指标(Key Performance Indicator,KPI)等。接口和契约采用中立、基于标准的方式进行定义,它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互、相互理解,服务的请求者和提供者之间高度解耦。
平台架构如图1所示分为三层:应急服务管理平台、流程服务容器和门户系统。应急服务管理平台提供应急预案管理所需的后台技术支撑;流程服务容器构建业务流程,设置服务访问路由;门户系统负责业务应用的展现。
2.1 应急服务管理平台
应急服务管理平台实现服务注册、流程建模和组织机构管理。采用通用资源标识符来表示每个应急管理要素。
应急服务独立部署在应急智能平台之外,由相关应急组织机构进行维护管理,智能平台对服务进行注册管理,以便在需要的时候能够将该服务纳入应急流程中。
1)服务入口注册:注册服务的授权访问入口,取得合法访问服务的权限;
2)用户接口注册:一个应用服务具有不同的用户界面,供指挥用户、调度用户、操作用户等使用。
3)数据接口注册:一个应用服务具有多个数据接口,供其他应用服务使用,进行数据交换和服务交互调用。
应急管理平台提供了流程建模和组织机构管理模块,以便创建完整的服务流程定义文件,形成应急预案。
2.2 流程服务容器
为了实现业务流程的实时部署和运行监管,采用服务容器设计模式,构建了流程服务容器。流程服务容器容纳应急预案业务流程的本地实例,提供了业务组件集成的开发和运行环境,可对各类标准服务按照业务流程进行编排和管理,是应急预案智能平台的核心引擎。
服务容器采用服务控件(Controls)技术对应用服务进行封装,支持控件接口与实现的动态绑定,支持运行期控件元数据重写,这些特性构成了服务动态接入和服务编排的技术基础。服务容器读取应用服务的WSDL文件,根据元数据信息自动实现对应的应用服务管理接口,由服务容器生成控件实例,在不进行编码开发和重新部署的情况下对应用服务资源进行“热插拔”操作。
服务控件的实现技术主要包括两部分:应急服务语义匹配和控件(过滤器)实例化。
应急服务语义匹配模块包括语义分析器和应急救援本体库。应急救援本体库存储应急救援领域知识,包括各级应急救援组织网络、各级救援服务接口描述、救援预案流程定义、专业术语定义等。语义分析器通过读取流程定义文件和外部服务的WSDL信息并与本体库进行智能匹配,生成服务流程模型;控件工厂和过滤器工厂分别解析服务流程模型中的节点和链接信息,匹配出合适的控件模板和过滤器模板,生成控件实例和过滤器实例。
过滤器负责节点之间参数传递中的模型转换,解决流程中前后服务节点参数语法语义的差异性问题。-语义分析器在分析节点间存在语法语义差异后会在节点之间插入过滤器,进行语法语义转换,使得流程中后服务节点能够理解前服务节点传输的参数内容。
2.3 门户系统
门户提供了用户登录系统和管理应用的接口,用户通过可视化建模工具,根据预案要求编排应急服务流程,构建应急救援应用。
门户系统负责应急救援服务流程的展现,门户系统通过访问应急服务管理平台的服务注册信息,获取相关用户的授权界面,并可根据组织机构的权限,将相关服务界面整合在一起,构建用户终端页面,形成实际运行的应用系统。
3 应急预案智能平台应用
智能平台是一个面向应急流程的调度管理平台,一旦发生突发公共事件,由应急指挥人员,加载相应的应急电子预案,应用事件分析与模拟预测结果,结合空间环境信息、应急资源信息、现场情况信息等,形成应对突发公共事件的应急流程与行动方案,包括应急组织体系、应急工作流程、应急资源调配、应急处置方法等。
应急预案智能平台主要包括应急预案管理、应急方案管理和外部系统智能接入等功能。
3.1 应急预案管理
3.1.1 预案要素管理
包括组织机构管理、应急服务管理和要素关系管理等内容。
应急组织机构管理:应急组织机构包括各级政府机构及主管部门、专业应急机构和应急队伍等。应急组织机构是应急救援中真正承担救援活动的主体。平台存储各级组织机构的职能定位及联系方式,在突发事件发生时能够自动、快速联系相关机构,激活相关服务,启动应急救援流程。
应急服务管理:应急服务包括资源服务、通信服务和应用服务等内容。各级应急组织机构都维护着对应其自身职责的信息系统,这些信息系统通过封装成服务供应急预案智能平台调用。资源服务包括救援物资、设施、设备、队伍等的现状和调度;通信服务包括电子邮件、短信平台、自动传真、视频电话等多种通信手段的调度;应用服务包括环境监测、地理分析、预测模拟等专业应用服务。
预案要素关系管理工具:给组织机构分配应急服务的访问权限。应急服务和应急组织机构是多对多的关系,在实际应急流程中,一个应急服务对应着操作用户、指挥用户等多个用户,这些用户来自不同的组织机构,共同协同完成整个应急流程。在应急预案编制中,需要事先确定各个组织机构之间的协作关系,搭建每个应急预案的组织架构,从而确定预案要素之间的对应关系。
3.1.2 预案制作和维护
预案制作维护包括服务流程和用户界面要素的建模设计。
在应急救援标准流程中,包括预测预警、分级响应、现场处置和应急总结等几个大的阶段性活动,每个活动里面还可能包含了若干子活动,根据突发事件的不同,这些子活动也会有所不同。一个危化品应急预案流程如图2所示,其中预测服务调用了环境监测服务和事故态势分析服务两个子服务,而现场处置则调用了应急资源服务、通信调度服务等多个应用服务。这些服务构成了应急救援服务链,把整个应急救援过程中组织机构、救援人员、应急资源和救援行动有效整合,极大提高了救援效率。
在应急智能平台中,应急服务的入口、用户界面和数据接口都是注册作为平台资源进行管理,可以借助可视化建模设计工具,编排整个应急服务流程链,并对每个应急服务的用户界面进行定制,从而构建一个完整的应急预案。
3.2 应急方案管理
应急预案主要针对单项事件,在发生大面积、跨区域的应急事件时,不仅仅需要协调多部门,多行业的应急救援,而且还需要面对次生、衍生事件,需要整合多个数字预案,生成应急方案。应急方案包括应急组织体系、应急工作流程、应急资源调配、应急处置方法等等,所有这些都是以相关应急预案中规定的内容为基础的。
智能平台中的应急预案是以服务链的结构化形式管理的,通过对服务节点的调整,可以快速整合服务流程,形成实际的应急方案,并根据应急方案生成应急服务流程和用户界面,自动通知方案中规定的相关人员与部门,启动应急流程。
3.3 外部系统的智能接入
在应急救援流程中,智能平台起着“中枢”的作用:现场指挥部、应急指挥中心、应急队伍等之间需要通过平台实时交换业务信息,传达指令,发送报告;需要通过平台接入气象监测仪器、各类GPS信号、视频监控信号、现场检测信号等各类实时信息,通过地理信息位置同步系统,接入应急平台的各类业务应用模块;需要临时接入本地或异地专业信息系统,开通数据传输通道,为本地应急平台提供专业信息。
4 总结
智能平台是以应急救援调度为核心业务,通过对数字预案和智能方案的管理,生成应急业务调度流程,并在流程的各个节点上连接相关服务,接入现场信息、辅助决策信息、指挥调度信息等内容,形成应急指挥核心中枢系统。智能平台剥离了与核心调度业务无关的业务功能,采用信息交换和共享的新技术,实时接入外部信息,真正起到了指挥平台的作用。
参考文献:
[1] 张瑞新,门红,廖凌松.安全生产应急救援地理信息平台建设探讨[J].地理信息世界,2007(1):13-18.
[2] 李曼,王大治,杜小勇,等. 基于领域本体的Web服务动态组合[J].计算机学报,2005(4):644-650.
[3] Alur D, Crupi J, Malks D. Core J2EE Patterns:Best Practices and Design Strategies[M].Prentice Hall/Sun Microsystems Press,2003.
[4] OASIS.Web Services Business Process Execution Language Version 2.0[EB/OL]. /wsbpel/2.0/wsbpel-v2.0.doc,2007.
[5] The Apache Software Fundation.Beehive 1.0.2 Documentation[EB/OL]./docs/1.0.2,2006.
[6] 樊运晓.应急救援预案编制实务[M].北京:化学工业出版社,2006.
应急调度方案范文第4篇
为保障全县工业商贸经济持续快速发展和社会全面进步，建立和维护工业经济商贸发展所必需的煤、电、油、运生产和供给秩序，有效减少和缓解各类突发事件和持续紧张状态（以下简称紧急状态）对煤电油运的影响和危害，按照国务院关于加快建立经济领域“反应灵敏、运转有序、精干高效、保障有力”的应急机制要求，维护社会稳定，确保我县经济又好又快发展，特制定本预案。
二、组织机构
成立县煤电油运综合协调应急领导小组，专门负责我县电力、成品油、煤炭市场供应应急协调工作。
领导小组由县政府分管经贸工作的副县长任组长，县府办主任和经贸局局长任副组长，成员由县政府办公室、县委宣传部、县发改局、经贸局、公安局、财政局、交通局、物价局、安监局、工商局、质监局、武装部、公安消防大队、供电局、中石化肇庆分公司等单位的有关领导担任。应急领导小组办公室设在县经贸局，负责日常具体工作，县经贸局分管副局长兼任办公室主任。
三、有关单位的主要职责
1、县经贸局：
⑴负责综合分析判断紧急状态对全县宏观经济、区域经济或重要产业的影响程度和持续时间，提交紧急状态初步报告或启动预案紧急报告。
⑵制定煤电油运专项调度应急运转模式和措施建议。组织应急措施的实施，协调解决实施中出现的重大问题，保证紧急状态下各项应急调度协调工作有序进行。
2、供电局：
⑴制定电力行业专项调度协调应急预案和所属电厂调度协调应急预案。
⑵监测分析电网的运行情况，及时发现和评估电网紧急状态对工业经济和社会生活可能造成的破坏性影响，在紧急状态下负责供电应急运转方案的实施和电网的安全运行，并及时向县经贸局报告电网运行情况。
⑶监测分析所属发电企业生产运行情况，在紧急状态下负责所属电厂的正常发电和燃料保障，并及时向县经贸局报告情况；组织发电企业加大自购煤工作力度，确保机组不因缺煤而发电不足或停机。
⑷负责电力调度，做好错峰用电管理工作，保证电力供应。
3、中石化肇庆分公司：
⑴分别负责制定本系统成品油专项调度协调应急预案。
⑵监测分析成品油销售运行情况，及时发现和评估成品油行业紧急状态对工业经济和社会生活的破坏性影响，在紧急状态下负责组织所属石油、石化企业进行燃油的市场保障，并及时向县经贸局报告情况。
⑶落实成品油资源，组织成品油调运、销售，平抑成品油价格，保证成品油供应。
4、交通局：
⑴分别负责制定铁路、公路、航道运输行业专项调度协调应急预案。
⑵监测分析运输情况，及时发现和评估运输行业紧急状态对我县工业商贸经济的破坏性影响，在紧急状态下负责本系统的运输和保障，并及时向县经贸局反馈或报告情况。
⑶组织客货运输，保证应急、重点物资、鲜活农产品运输畅通。
5、其他相关部门和系统：
⑴负责制定本部门和系统配合保障煤电油运应急调度方案。
⑵在紧急状态下，按照县政府的统一指挥，负责实施本部门和系统应急配合保障方案。
四、监测预警和信息报告
县经贸局根据专项应急措施（或预案），制定日常情况和紧急情况下的分类监测预警及其工作规范，综合分析、科学判断监测数据和动态信息，及时发现具有全局性影响的煤电油运等异常现象。
㈠各有关部门要加强沟通，开拓信息渠道，及时发现和评估紧急状态对工业商贸经济的破坏性影响。县经贸局要加强工业商贸经济运行监测分析，研究和建立煤电油运应急预测和指挥调度网络。
㈡监测预警工作应当根据紧急状态类型，制定日常和紧急情况下的分类监测计划和工作规范，科学分析、综合评议监测数据和信息，及时发现潜在的具有全局性影响的煤电油运问题。
㈢建立应急联络渠道。县经贸局应保持与各成员单位和各镇政府的应急领导机构及其有关单位的联络畅通，确定担负24小时值班任务部门的责任人及应急电话，并通过快速信息通道，实现网上应急调度的调控。
㈣建立应急报告制度。县经贸局负责建立煤电油运重大、紧急情况的信息报告系统。煤电油运有关部门或企业、各镇的信息要及时上报县经贸局，县经贸局整理汇总并向县政府报告。正常情况下为月报，特别紧急时为日报、专报。同时以简报形式反映工作进展情况，并不定期地提交阶段性综合分析报告。
㈤通过日常监测预警有关部门、地方政府报告或者通过其他方式判断等，获取可能发生煤电油运紧急状态的信息时，县经贸局应立即组织有关部门或各镇政府会商核实，并迅速向县政府提交紧急状态初步报告。报告内容应当包括：事件或情况发生的时间、地点，估计产生的影响和损失，已采取的主要措施和事态控制程度，需要解决的突出问题，发展态势的预测，应对措施建议等。
㈥发生或发现煤电油运紧急事件后，县经贸局除按本预案规定向县政府报告外，还应会同有关部门立即组织力量进行全面调查核实，并指导有关部门采取必要控制和缓解措施，避免态势扩大。
㈦凡出现下列紧急状态的，经调查核实后，县经贸局立即向县政府提交启动预案紧急报告：
1、重点水泥企业用煤运输渠道严重不畅。
2、重点工业企业用煤供给中断，煤炭库存低于正常生产需要，且预计补充困难的。
3、县电网发生特、重大事故，全面或局部崩溃；县电网电力供应损失急剧增大，县城电网减供负荷在40%以上，且电力系统自身难以恢复的。
4、重要发电企业或110KV以上枢纽变电站发生全停事故，已导致县网非正常解列成三片及以上，并造成县电网减供负荷超过20%。
5、县城供电持续性异常，短时间无法恢复，如生活用电连续中断造成居民生活出现严重困难的，重要公共设施供电连续中断造成供水、通讯等公共服务严重紊乱的。
6、县内成品油库存低于县内正常消费量7天。
7、全社会加油站因资源原因出现较大范围停业且预期持续较长时间的。
8、社会经营单位持续抢购成品油，销售价格明显高于规定价格，并预期维持较长时间的。
9、辖区内高速公路、国省道干线公路出现长时间关闭、中断或堵塞等交通异常，造成大量车辆长时间中途滞留的。
10、应急物资运输受阻、防疫、救灾、抢险和其他应急医药用品、防护用品和消杀用品，以及救灾物资（食品、日用品、装备）急需组织铁路、公路直达运输综合协调的。
11、重点货物运输异常，如煤炭、成品油、粮食、棉花、化肥、农药、鲜活农产品等涉及国计民生的重要、大宗物资运输量持续不足，造成上下游产业行业生产组织困难的。
㈧县经贸局向县政府提出紧急状态初步报告或启动预案紧急报告后，应根据调查核实尽快提出建议性报告，综合分析判断紧急状态对全县宏观经济、区域经济或重要产业影响的严重程度以及持续时间，并提出可供决策选择的煤电油运专项调度应急方案。情况特别紧急时，县经贸局向县政府提出书面紧急报告之前，可以直接口头报告或请示。
㈨根据上级指示或紧急事件情形，县经贸局召开紧急会议，综合判断紧急状态的程度和影响范围等，制定煤电油运专项调度应急运转模式和措施建议，经县政府批准后实施。
五、应急措施
㈠县政府接到紧急状态初步报告或启动预案紧急报告后，根据紧急状态对煤电油运的影响和危害程度，研究决定启动预案有关事宜。
㈡按照县政府指示，结合煤电油运紧急状态或异常事件的性质特点、扩散趋势、持续时间，以及对全县工业商贸经济的现实和潜在影响等，县经贸局分别启动相应的紧急措施。
1、开展专项应急调度协调。组织实施煤电油运专项调度协调应急预案，临时调整部分资源配置，解决或缓解局部突出矛盾。
2、情况特别紧急时，按照县政府授权，根据实际情况，统一配置资源、统一提交计划、统一组织运输，并按上级批准的方案和授予的权限下达“调度命令”或“调度通知”，督促有关单位具体实施，所涉及相关部门和相关企业必须严格执行，不得无故拖延或推诿扯皮。
3、指导各镇政府和有关企业，加强煤电油运需求侧管理与协调，在煤电油运供给已经满负荷生产的情况下服从大局，合理控制对煤电油运需求的增长速度并调整其结构。
4、启动值班制度。保持主要工作人员联络畅通（如手机24小时开机），节假日编制值班表，公布紧急情况下值班电话，特别紧急时实行24小时在岗轮流值班。
5、实行会商制度。组织有关单位定期会商，及时沟通情况、研究对策、制定措施。紧急情况下实行日会商制度。
6、指导、协调、配合有镇和企业实施区域和专项调度协调应急预案。
㈢煤电油运应急运转期间，为保证调度协调应急措施效果，缓解紧急状态，县经贸局可以协商有关部门，依据有关法律法规向县政府和市有关部门提出以下煤电油运相关政策措施建议：
1、对煤电油运相关企业或区域实施临时应急政策，稳定或增加生产供给能力。
2、减免煤电油运相关行政性规费，简化行政审批、核准、备案等管理程序。
3、向煤电油运企业运行急需进口原料、材料、设备等提供相关方面的优惠和支持。
4、动用政府储备物资和商品，征调商业流通企业相关库存物资和商品，缓解部分企业需求。
5、煤炭、电力、成品油特别紧缺情况下，临时管制部分地区或企业的生产和销售，加强对价格的监管，按应急措施计划方案下达分配、销售和运输计划，保证煤电油运的基本供应和运输畅通。
6、制定、审批煤电油运产品或服务的应急技术标准、规范、措施等。
7、依法采取有关物价干预措施和紧急措施，进行物价监督，组织物价执法检查。
㈣煤电油运调度应急措施实施期间，县经贸局对煤电油运调度应急措施的实施效果组织评审或评价，及时向县政府提出调整、终止的建议。提出终止建议时，应同时提出有关善后事宜处理方案。
六、相关管理事项
㈠应急措施实施期间县级发生的储备物资动用、紧急采购（进口）、应急生产、征用、补偿和赔偿等经费，应编制应急项目概算，请示县政府从财政应急预算或专项准备金中支出。
㈡本预案一旦启动，执行应急任务的单位和个人必须无条件执行。对拒绝、延误执行应急调控措施或、推诿扯皮的有关单位领导和责任人要严肃处理，对有关单位予以通报批评。造成严重后果和损失的，给予行政处分；构成犯罪的，依法追究刑事责任。
㈢县经贸局按规定向上级提出申请，对参加应急工作的人员，给予适当的通讯、交通等补贴，对做出突出贡献人员给予表彰和奖励。
七、其他事项
应急调度方案范文第5篇
经过SARS等一系列公共卫生突发事件后，应急信息系统的建设受到了空前的重视。我国各级政府、各部门都把应急信息系统或应急指挥中心的建设提上了议事日程。例如，北京市公共卫生信息应用系统的建设，就是在以往的经验教训基础上，把应对公共卫生突发事件作为一个主要建设目标；卫生部应急指挥中心向社会公开招标，征集建设方案，等等。在政府推动下，应急信息系统建设已经进入一个高峰期。
应急信息系统的建设受到全社会范围的重视，这是一件好事。但同时也带来了问题：系统建设的目标到底是什么？多个相关项目如何统筹？怎样处理应急信息系统建设与业务处理系统的关系？应急信息系统的功能边界应该如何划分？等等。对这些问题如果没有一个正确的思路，应急信息系统建设的大规模投入就难以收到应有的社会效益，甚至象以前办公自动化和门户网站一样，变为一场“运动”。
本文试图对应急信息系统给出一个目标，描述“理想”情况下的系统模型和需求；在此基础上给出对整个应急信息系统规划的看法。
二、应急信息系统的目标和功能需求分析
应急信息系统的目标，就是配合危机管理的全过程，应用信息技术，实现大面积的、跨专业和部门的信息资源、处理资源和通讯资源的实时调度，使应急指挥过程更加科学化和可视化。
这里用到了一个超越“应急”的概念——危机管理，我们把支持危机管理作为应急信息系统的目标。这是因为，要最大限度减少各种突发或紧急事件带来的损失，不仅仅要求我们在事件发生后做出迅速、准确的应对和处理，还要求我们在事件前期进行预警和辨识、在后期进行常态恢复。“危机管理”的三阶段理论更能指导我们运用信息技术对突发或紧急事件全面、全程的支持。
显然，这一目标，不是一个单纯的信息系统可以达到的。它要依赖基础性的网络和多个专业化的应用系统，要依赖多种技术的支持。但是，越是复杂，我们就越应该分析清楚，那些是核心、哪些是基础、哪些是锦上添花；哪些应该先建，哪些可以后建。否则眉毛胡子一把抓，不利于复杂系统的建设和统一的规划。
我们用如下的三层逻辑模型表示应急信息系统及其支持系统的关系。
……
应急信息系统
信息处
理系统
通讯调
度系统
信息
采集
信息
调度
资源
调度
信息
表现
基本网络和通讯系统
辅助
决策
应用支持层
集成应用层
基础设施层
GIS
应急信息系统的三层逻辑模型
各层的关系如下：最高层即是应急信息系统的核心功能，它是一种集成式应用；专业化的信息处理系统和各种相对成熟的技术系统（如GIS和Call Center系统）是构建应急信息系统的支撑性应用，我们称之为应用支撑层；而基本网络和通信系统是以上所有应用的基础。相邻层次之间有着双向的信息供求关系。
我们从对信息的处理角度来分解应急信息系统的功能目标。
任何类型和目的的应急指挥系统，都具有以下功能特性：
1、信息汇聚：从应急事件现场或监测网络采集到的各种信息，将被传输到信息汇聚点（应急指挥中心）。这些信息可能是直接事件现场的视音频信息，也可能是来自传感设备、监控设备的信息或信号，还可能是来自相关的专业化信息处理系统的数字化信息。
2、信息表现：应急信息系统应该有直观而准确的信息表现形式，为指挥员进行指挥调度和辅助决策提供最大的帮助。GIS是一项广泛使用的技术，可以将危机管理所涉及的信息（如危机态势、应急指挥相关资源分布、应急方案等）在基础的空间地理图形上形象地表现出来，便于指挥和决策人员直观地进行形式判断、形成决策或进行资源调度；各种信息还可能要借助一定的显示设备和显示控制系统表现出来。
3、信息调度：所有信息在汇聚点被组合和集中呈现，供指挥中心的指挥决策人员作为决策和调度依据；有时还要将信息分发下级指挥中心（或分中心）的不同的专业化处理系统进行处理，或从这些系统收集处理结果。
4、通讯和物资资源调度：应急指挥最终都表现为通过一定的通讯手段，完成一定的人力、物力资源调度。例如警力的调度、救灾物资和设施调度、对事件现场的疏导和部署，等等。
5、辅助分析决策：在应急指挥过程中，提供一些逻辑分析模型、统计模型或预案，以及案例库中的参考案例，帮助指挥员进行理性决策；同时，应急信息系统还应记录下整个指挥调度的过程，形成完整案例，丰富案例库，为实现知识化、智能化的危机管理作积累。
以上是一个较为抽象的逻辑功能模型，它有助于我们把握应急信息系统的核心建设目标，合理运用各种技术和各种“物理的”系统。
三、应急信息系统与其它信息系统的周边关系
1、技术型应用系统与应急信息系统的关系
在应急信息系统建设领域的最大误区，在于信息系统功能需求分析的缺失——从需求的陈述（实质上是一种需求定义）直接跳到技术方案，甚至成为技术方案或产品的简单堆砌。以技术方案代替功能需求，这似乎已经成为了一种应急信息系统建设中的普遍现象。
例如，我们经常能在招标书或所谓规划中看到这样的做法：即直接把“数字录音系统”、“大屏幕显示系统”、“地理信息系统”等作为“需求”本身的内容，对具体的技术实施方案和产品型号进行招标，甚至还有的招标书把“数据库系统”也作为应急信息系统需求的一部份提出来。这里面缺少了对应急信息系统的实质内容和目标的把握，缺少了一个理性的论证和分析过程。这样的“需求”拿出来招标，多半会造成建设的混乱和失控。
并不是说以上的技术系统不能作为应急信息系统的一部分，相反，逻辑的功能最终都会落实为一系列“物理”的技术子系统。但是我们在进行技术子系统的划分和分包之前，有必要对有机信息系统的“原始”功能需求作一定义和陈述，为技术方案的展开提供理性的约束，而不会被技术牵着鼻子走。
例如，GIS是一种广泛使用的、成熟的技术，也已经形成相对独立运行的系统。独立运行的GIS甚至可能成为整个应急信息系统中最主要的操作平台。这也是一些项目直接把GIS作为一种“默认”的“需求”的原因。但是，应急信息系统是否要采纳GIS，还要看具体的应用领域是否具备了应用GIS的数据条件和环境。而且，即使有必要和有条件使用GIS，也要从整个应急信息系统的总体目标出发进行分析，提出技术应用需求：
第一， 要实现应急信息系统与GIS的双向联动。GIS虽然可以独立运行，但在应急信息系统环境下，应该可以实现应急信息系统与GIS的多种联动方式——包括双向的相互驱动和基于数据共享的独立操作，等等；
第二， 要实现应急信息系统与GIS的底层整合。GIS系统与应急信息系统应共同遵循一定的数据标准，产生和传递一致的数据；底层应实现数据库共享或公用。
第三， GIS与其他系统的数据整合。GIS的基础数据来自测绘部门，而应急指挥所需的“活”的应用数据往往来自其他业务部门，如建设、交通、气象、卫生，等等。为让信息系统能够运行起来而“一劳永逸”地导入数据的做法是不可取的。应该充分利用这些“活”的地理数据，建立与数据源进行同步更新的完整机制，贯彻专用属性数据“谁使用、谁负责”和合理共享的原则，避免产生新的信息孤岛。
以上是应急信息系统中对GIS的需求分析应该考虑的内容。只有对这些问题都分析清楚了，才可能对应急信息系统中GIS的必要性、可行性和技术方案和造价作一正确判断。而这种全局的、客观的、中立的分析，恐怕要在请GIS厂商提供技术方案之前完成。
在应急信息系统领域，类似的成熟技术系统还有Call Center、知识管理系统、视频会议和视频监控系统等。对这些相对成熟、“自成一体”的技术应用系统，都要作类似的分析，才能保证最后的应急信息系统是一个有机的、完整的、体现建设初衷的系统，而不是一组不分主次、繁复、独立的技术系统。
忽视需求分析或缺乏正确的需求分析方法，是存在于信息化建设的通病。对于应急信息系统建设而言，这种只有方案，没有需求分析的现象尤其有害。因为应急信息系统的建设几乎成了一种潮流，而且它同时承载着政府危机管理和电子政务信息资源整合的双重重任。缺乏对需求的分析和规划，会使应急信息系统建设失去理性，导致盲目建设和重复建设，与信息资源整合的精神背道而驰。
2、专业化信息处理系统与应急信息系统的关系
我们对应急信息系统的需求认识往往是始于“混沌”的。尤其是当因为信息系统缺位造成重大损失的时候，更是希望通过一个项目、甚至一个系统的建设毕其功于一役。但是，应急信息系统的主要目标是实现危机管理中的决策支持，离开了专业领域的知识和专业化的信息处理系统的支持，应急信息系统对科学决策的支持就会落空。另一方面，应急信息系统往往是跨管理部门、跨专业领域的系统，涉及多个专业系统。处理这种兼具“宽度”和“深度”的复杂需求的合理做法，是把项目进行分解，把应急信息系统建设与专业化信息处理系统进行合理划分。
一般来说，专业化信息系统负责专业化的信息监测和预警、信息处理；应急信息系统则负责信息的汇聚、分析，以及对会商、决策和资源调度的支持；二种系统之间通过共同认可的标准来实现信息传递和工作协同。应急信息系统从专业化信息处理系统中收集预警监测的结果；应急信息系统则向专业化信息处理系统提交信息加工请求并收集信息处理结果。
检验是否较好划分了专业化信息处理系统和应急信息系统界限的直接办法，是看二者之间是否有足够的独立性。一个好的规划和设计应该是这样的情形：应急信息系统本身不一定很“专业”，但它能与很专业化的信息处理系统高效地协同工作。应急信息系统的核心价值，在于它对跨专业的、公用资源的调度能力；专业的判断和业务流程应该留给专业化的信息处理系统。从这点上来说，应急信息系统其实需要有一定的“通用性”。通用性越好，它动态“接入”不同专业信息系统的能力就越强，整个大系统的“应急”能力也就越好。
举个例子，假设我们针对SARS的预防和控制建设了一个公共卫生应急信息系统，如果它不能百分之八十、九十，甚至更高比例地应用到其它公共卫生突发事件的处理上，那么它的规划和需求定义就是失败的。相反，如果我们在进行需求分析的时候，能把专业化事件处理的差异性需求尽可能地体现在“应用支持层”的专业化信息处理系统中，那么无论是作为通用应急指挥平台的公共卫生应急信息系统，还是专业化的传染病管理信息系统、医院管理信息系统、以及各种科研信息系统，等等，都能沿着相对稳固的需求轨迹发展。
四、应急信息系统的规划与标准化
现在我们跳出单个应急信息系统的需求分析，来看看多个系统——或者说整个城市级别的应急信息系统——的需求，或者说一种规划。
根据上面的分析可知，我们如果采用一个相对通用的“应急信息系统”和一系列专业化信息处理系统，可以构成一个完整的、面向各种突发事件的应急信息系统“两层”构架。也即从理论上说，可以构建城市级别的唯一的、集中的、公用的应急信息系统平台。但在实际操作中，有两个因素制约这种“两层架构”模式。一是系统的规模和负载问题；二是现有的行政管理体制的制约。
根据系统论的原理和系统工程实践经验，每个系统下辖的子系统个数是有限的，超出这一限度，不仅系统的业务负载和复杂度会难以承受，为保障系统运行可靠性所付出的代价也会十分巨大。我们通常采用系统分级的办法来解决这一问题。在应急信息系统建设中，就是通过建立一些区域的或“领域”分中心来分担“总中心”的负载和复杂性。
但是，采用分中心的“三层”构架，应该满足两个先决条件。否则，就有可能使整个城市的应急信息系统更加混乱和难于管理，操作起来无所适从，甚至变成一盘散沙，为信息资源综合增加新的负担。
第一个条件，还是比较、分析和论证。在具体的城市危机管理环境中采用三层构架，一定要有与两层构架的对比分析。三层系统的优势在于其上的业务操作流程通常可以更好吻合现有管理体制；劣势是分级处理带来了额外的信息分配和汇总的效率开销，甚至为一些导致低效的“门槛”创造了条件。我们对架构进行分析的结果，应该不仅仅是一个构架的模式，而且有具体的构架实施方案，包括对弱点的分析，以及弥补的方法，作为系统后续建设的前提条件。这是应该在决定建分中心之前完成的。
在实际建设过程中，对于城市应急信息系统的构架模式选择，盲目模仿或是“拍脑袋”的情况还是很多的。构架的选择往往不是对流程科学性、系统运行效率、系统建设周期和投入、系统的可操作性等因素进行分析比较的结果，而是避开业务整合的深层困难、对现有管理体制过分迁就和妥协的结果。这对于整个城市的危机管理和信息化建设都是非常不利的。
第二个条件，无论是二层还是三层构架，都离不开标准化基础。统一的数据标准制定应该在应急信息系统的总体规划层面，而不是某个具体的应急信息系统建设的层面来进行。在某个具体应用系统中谈统一标准的意义是十分有限的。即使每个系统都实现了“内部”的统一标准，也可能导致多个系统之间无法沟通。
对于标准化的认识，也是信息化建设中误区多多的一个领域。如把统一数据规划甚至统一数据库设计等同为数据标准化，把标准化局限于管理标准化而无视应用标准化，把应急信息系统的标准化局限于应急事件的分级，等等。应用标准化是我国信息化建设的一个弱点和紧迫点，也是应急信息系统建设的一项基础性工作。如果能在国家层面整合专业化研究资源，组织面向应急指挥和危机管理的统一的标准化研究，则能有效促进整个国家的应急信息系统的建设；反之，如果我们不抓住应急信息系统这一建设背景，则不仅应急信息系统的建设不能进入有序状态，标准化建设本身也将摆脱不了滞后于信息系统建设的状况。（参考《把标准做“实”》）。
参考文献：
1.
《把标准做“实”》 黄以宽，《信息化建设》2005-1，2
2.
《浅论应急指挥系统的基础性研究》，黄以宽，第一届中国政府电子政务论坛交流论文，2004-10
