主頁（http://www.by236.com）：應急聯動系統的分析、設計與實施(5) 五、大屏顯示系統 大屏幕顯示系統主要進行應急地理信息顯示、應急車輛狀態顯示、氣象顯示、應急實力信息顯示、災情受理地點顯示、主要交通道口交通狀態顯示和部分重點保衛目標監控顯示。指揮中心實現對指揮系統控制區的各種情況進行動態監管。大屏幕投影系統負責實現直觀、完整、準確、清晰、靈活的顯示各項信息，包括：各種地理信息、車輛狀態顯示、氣象信息顯示、實力顯示、受理信息顯示。這類信號由計算機相關軟件生成，在現場計算機顯示器上顯示，同時調入所需要的信息在大屏幕作任意大型顯示。便于整體統籌，指揮。同時指揮中心計算機與其它會議室（兼指揮室）計算機聯網，使其它會議室可通過局域網調用所需信息在會議用投影機上顯示。 六、支撐軟件 支撐軟件平臺系統包括計算機操作系統、數據庫管理系統、GIS系統和應用軟件開發平臺系統等。以下是我們的一個實例： 數據庫服務器：Oracle . GIS支撐平臺：Mapinfo profession MAPBASIC OA平臺：Lotus Domino 開發平臺：DelpHi VC Jbuilder 操作系統：Windows Advance Server 網絡協議：TCP/IP 軟件平臺結構：軟件平臺采用Ｃ／Ｓ＋Ｂ／Ｓ結構 2.1.4 標準與接口設計 系統接口：本應用系統是一個復雜的各種技術、各種相關系統、數據的集成系統，因此系統接口設計十分重要。系統接口分為外部接口、內部接口。接口有數據接口、軟件接口、硬件接口。 標準的建設是CERS的核心工作。 2.1.5 系統安全的設計 安全設計從系統安全、數據及數據庫安全兩方面進行了設計。 2.2 CERS的框架設計 采用B/S與C/S相結合的體系結構。 一、Client/Server體系結構 Client/Server是一種目前發展已經非常成熟的計算機體系結構。在此之前，信息系統一般采用文件共享的方式，通過直接訪問數據庫來達到數據共享的目的。Client/Server體系結構嚴格地定義了客戶端和服務器端對信息數據的處理范圍。即客戶端要訪問服務器端的數據時，一定是以特定的描述語言，將請求信息首先傳遞給服務器端，由服務器端的相關模塊判別并處理客戶端的這個請求。請求處理完畢后，服務器端再將處理結果回傳給客戶端。這樣才算一個訪問過程的結束。Client/Server體系結構發展到今天已經非常成熟了，它可以把實現友好人機交互界面的任務交給客戶端處理，而服務器端只需完成數據的存儲和處理。這種體系結構的優點是：系統功能強大、交互能力強、系統運行效率高，并且開發工具和開發手段可選擇性強。缺點是：所開發出來的系統相對比較封閉，主要適合于數據管理方式；系統結構復雜，開發周期長；安裝和維護比較麻煩。 二、Browser/Web Server體系結構 為了克服Client/Server體系結構所存在的問題，最近幾年來，隨著Internet技術的飛速發展和日益成熟，特別是瘦客戶機概念的提出和發展，提出了以Browser/Web Server體系結構為代表的多層Client/Server體系結構，作為對Client/Server體系結構的補充和發展。Browser/Web Server體系結構將Client/Server體系結構的兩層結構發展到三層結構，一般可以認為是在原有的Client層和Server層之間加入了Application Server層（也稱為中間件層）。Application Server層承擔了原來Client/Server體系結構中Client層和Server層的部分任務，這樣使得Client層和Server層所承擔的任務相對減輕。Client層變成比較統一的界面，Server層主要處理信息數據的存儲和管理任務，Application Server層負責具體數據的處理任務，而且可以根據處理任務的變化而變化。Browser/Web Server體系結構的主要優點是對Client端設備的要求逐步降低，運行維護量下降；Application Server層的中間件軟件日益豐富和模塊化，降低了系統開發的工作量，縮短了開發周期。主要缺點是Application Server層的中間件軟件目前還不夠豐富和完善，而且對網絡系統的運行環境要求較高。 3. CERS面臨的技術挑戰與我們的對策 3.1 CERS的分析 CERS實施的核心是要盡量提高事件反應速度，縮短事件反應和撲救的時間。CERS與其它集成系統相比，最大的特點是： 3.1.1 實時性要求高，應急反應要及時 CERS實時性要求高，這就要求實現各個層次的互聯互通，如有/無線數字鏈路、有/無線語音鏈路、有/無線圖像鏈路的互聯互通；實現數據的互操作、軟件的互操作與語義的互操作。 3.1.2 具有移動辦公的特點 這是CERS最大的特點。系統設計要重點考慮這個特點。 3.1.3 具有分布性、異構性、海量性和動態實時性特點 要實現各個層次的互操作。 一、數據的互操作 解決得不錯。 二、軟件的互操作 已有成熟的解決方案。 三、語義的互操作 還剛剛起步。 3.2 CERS面臨的挑戰 1．需要集成多個行業或部門的業務：CERS需要集成公安、消防、交管、120、供電、市政和政府等部門的應急業務。目前的集成大都專注于技術層面的互聯互通，并有效地實現了，而集成不僅需要找到、操作并獲取信息，還需要理解信息的含義。各應急服務系統間通訊會存在多詞一義、一詞多義或近義等語義沖突； 2．需要動態實時集成不同業務領域的已有或新建應急服務系統，這些系統是分布的、異構的，集成規模大； 3．集成的業務流程會動態增刪修改，如開始可能是110、120、119的聯動，隨著時間的推移，會有電力搶險、地震救急等業務加入； 4．系統不能理解應急預案，所以不能按預案自動調度； 5．GIS是應急指揮的重要手段，CERS需要實現時空集成。 3.3 我們的對策 3.3.1 采用的技術 XML 及相關技術，如Web Service、Ontology 元數據技術 3.3.2 實施思路：建立集成框架，實現各業務系統的集成 CERS是一個復雜的集成系統，必須堅持“總體設計、分步實施”的原則。本著業務是核心，技術是手段的原則。 深入分析業務流程，建立各聯動單位的業務模型、系統模型和功能需求。 (中國集群通信網 | 責任編輯：陳曉亮) |
