應急調度方案
前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了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
