機場飛行區安防系統架構設計探究

丁寧

(博康云信科技有限公司上海分公司,上海200233)

機場飛行區安全防范系統主要取決于飛行區機坪及圍界安全。飛行區圍界作為空側與陸側隔離的主要安全屏障,建設過程存在時間長、范圍廣、數量多、更新快的現狀,需建設一套擴展性好、兼容性強、運行穩定的安防系統,針對多廠家不同設備要能兼顧共性和差異,同時為后期建設提供前瞻性,將需增加的功能或者接入的設備預留對接接口,避免后期安防系統結構大面積重寫和替換。

1 項目概況

本項目屬于改造擴建項目,視頻監控系統將標清攝像機升級為高清攝像機,同時按機場7003 規范擴大了錄像時間到90 天。圍界探測報警系統從原來總線型的報警設備更換為物聯網報警設備,將報警精度提高到3-5 米一個防區單位,設備數量增加到8 千多個。輔助照明系統保留了原有圍界位置的兩套系統,在新建設的區域增加了一套新的輔助照明系統。圍界廣播保留了原有圍界位置的兩套圍界廣播系統,在新建設的圍界區域新增一套廣播系統。新增一套智能分析系統用于圍界越界預警。因此,機場飛行區安防系統需要將一套視頻監控系統、一套圍界報警系統、一套智能分析系統、三套輔助照明系統和三套圍界廣播系統統一控制管理。

2 系統工作流程

2.1 日常工作模式,主要使用視頻監控系統對圍界的環境進行了解掌控,通過圍界廣播系統與崗亭或者巡邏人員進行語音溝通,每日定時對輔助照明系統進行開關操作,檢查系統運行狀況和故障信息。

2.2 報警工作模式,出現報警信息,系統自動切換,對圍界報警系統和智能分析系統的接入獲取圍界闖入或觸碰攀爬圍欄報警信息,將報警信息采集后交給事件管理服務進行清洗、匹配、轉換、聯動控制消息生成等工作,最后將聯動控制消息交給呈現端進行報警信息的電子地圖位置顯示、報警實時視頻圖像在電視墻或者大屏幕顯示系統進行切換,同時控制視頻系統的報警防區關聯的球機實現預置位轉向,向圍界廣播系統發送前端報警音并打通控制中心與前端圍界廣播的喊話通道,對前端入侵行為進行勸阻警示,部分報警區域的輔助照明系統執行開啟操作,補充光源。當工作人員處理完畢后,關閉輔助照明系統、關閉語音廣播、關閉報警視頻聯動,系統恢復到日常工作模式。

3 系統集成平臺管理系統架構

以高內聚、松耦合為理念,通過采用微服務架構將業務系統組件化和服務化,整個集成平臺分為三層：設備接入層、服務管理層和應用框架層,如圖1 所示。

3.1 設備接入層

圖1 系統集成平臺管理系統架構示意圖

設備接入層用于屏蔽不同廠商安防產品接口的差異性,對平臺提供統一的設備接入接口及適配服務,在開發中使用了微服務的架構設計方法[1],針對每個廠商產品提供獨立組件,不同組件間沒有業務上的耦合調用,可以獨立開發和獨立部署,極大的提高了工作效率。

以報警設備為例,首先設計用于保存報警設備編碼、IP 地址、訪問用戶名、密碼等信息的數據庫表結構,報警設備的接入組件讀取這些信息后,調用廠家提供的SDK,輸入以上設備信息后連接到所有的報警設備。建立好連接后,通過SDK提供的報警上報接口獲取非法觸碰、攀爬等信息,然后將信息進行篩選,同一個設備在一個時間段內重復的報警信息只向上層服務發送一次。

對于廣播設備,采用同樣方式設計用于保存廣播設備的設備編碼、廣播終端通道、廣播是否空閑狀態、音量大小等信息的數據庫表結構,由于廣播設備采用的是TCP 網絡通信的方式來下發控制命令和狀態信息上傳的,因此要根據廠家提供的TCP 通信協議來解析和創建命令包。考慮到有三種不同的圍界廣播設備,為每種設備開發了一個接入服務,服務之間不會有消息交互,通過各自的通信協議來管理圍界廣播設備。

其它幾種設備也采用相類似的微服務架構進行設計。

根據現場需接入設備類型將對應的接入組件啟動,若某些設備需升級更換,只要把對應的組件停止運行即可從系統架構中移除。其中各個廠商的安防子系統獨立運行,自行實現內部業務流程,和集成平臺的接入僅有數據交互而無功能耦合,集成平臺中的組件是否運行正常也不會影響各個廠商安防子系統的正常工作。

3.2 服務管理層

服務管理層提供各類運行服務,包括統一管理服務和事件管理服務兩大部分。其中統一管理服務包括身份認證管理、資源管理和系統配置管理。事件管理服務包括事件配置服務、事件轉換服務和報警聯動服務。

身份認證管理使用非對稱加密算法對用戶密鑰進行管理[2],設計了身份認證服務供需要認證的終端訪問,終端連接上身份認證服務后,向服務端請求服務公鑰,然后用服務公鑰加密終端公鑰然后將加密的信息發送給服務端,服務端收到信息后,用服務私鑰進行解密,同時保存這個連接提供的終端公鑰,這樣服務端和終端完成了服務公鑰和終端公鑰的交換。終端然后向服務端發送登錄信息,包含用戶名、密碼的登錄信息經過服務公鑰加密后發送服務端,服務端用服務私鑰解密后來進行用戶名和密碼的認證,通過認證后,根據不同用戶分配對應權限。

資源管理考慮到圍界報警設備數量有8 千多個探測器,首先采用防區分級的方式將探測器劃歸不同的防區,例如現場劃分了150 個防區,這樣每個防區就只有60 個左右的探測器,通過給每個探測器分配一個地址碼作為在歸屬的防區內唯一標識這個設備,例如01-23 指01 號防區的第23 號地址碼的探測器,當收到報警消息時,上傳的信息中帶有防區號和地址碼,通過這兩個信息可以唯一確定這個探測器,然后在數據庫的聯動配置中,可以檢索到這個探測器關聯的攝像機、廣播、輔助照明等設備信息。由于這些數據都存放在數據庫中,每次訪問數據庫都會給數據庫造成一定的壓力,在報警量比較頻繁的時候就會引起排隊檢索,訪問數據積壓問題又會影響報警的響應,不能滿足即時的性能要求。考慮到數據庫主要進行資源配置信息的檢索,頻繁寫入的要求不高,數據庫中的配置數據一般不會發生變化,因此在設計時采用了高性能的Redis 來對關系型數據庫進行補充。Redis 是Key-Value 數據庫,可以將關系型數據庫中的資源配置信息緩存在內存中,通過哈希算法進行快速的訪問。例如將防區號和地址碼作為參數查詢對應的探測器時,服務首先通過Redis 的接口查詢在內存中是否已經保存了這個探測器的信息,如果沒有保存,服務會訪問關系型數據庫把存放在設備數據表中對應的探測器信息獲取出來,同時保存一份在Redis 的內存中,可以將“01-23”這個字符串作為Key,其它的信息數據作為Value,這樣當下次服務再進行查詢時會發現Redis 中已經保存了這個探測器的信息,就直接獲取此信息,無需再到關系型數據庫中獲取數據了。在實際中通過使用Redis,可以將檢索的時間從2s 縮短到20ms,極大的提高了效率。

事件配置服務保存了每種事件類型所應當攜帶的信息,例如不同的圍界報警設備有的帶有設備ID,有的帶有IP 地址,這些信息需要記錄在事件中進行傳輸。筆者設計統一的事件信息結構,包括設備ID、設備IP 地址、設備地址碼等,如果圍界報警設備不包含設備地址碼,只有IP 地址,那么設備地址碼字段設置為空,通過這種統一的事件信息結構才能在接入層和服務層用一套標準的數據結構解析出正確的信息,再轉給事件轉換服務進行轉換。

事件轉換服務根據配置信息,將報警事件轉換為發送給不同聯動設備,其中包括：發送給呈現端的包含防區ID、區域位置、聯動的攝像機以及球機預置位的信息。發送給圍界廣播接入服務的包含廣播設備ID、播放警示音的索引、播放音量大小和播放自動關閉時間的信息。發送給輔助照明接入服務的包含照明設備ID、開關照明命令的信息。

報警聯動服務將轉換好的事件信息發送給呈現端因為包含了防區ID、區域位置,系統電子地圖就可以查詢出應當將哪個區域進行居中高亮顯示,然后將聯動的攝像機編號輸入到視頻模塊進行視頻切換。如果聯動的是球機,就將球機的預置位發送給視頻模塊,視頻模塊給球機發送調用預置位的命令,進行球機預置位移動。發送給輔助照明接入服務的信息帶有照明設備ID 和開關命令,輔助照明接入服務通過調用廠家的SDK,將設備ID 和開關命令作為參數調用相應的接口,來控制照明設備的開啟關閉。發送給廣播接入服務的信息通過廠家的SDK 接口打開指定設備ID 的廣播號角,根據警示音的索引來播放對應的聲音文件,通過音量數值調整播放聲音的大小。

由于需要在多個分布式系統間同步數據,在不同進程間進行消息交換,雖然單個數據量不大,但是數據的數量多,對于反應速度和可靠性要求極高,通過傳統的TCP 服務監聽轉發的模式無法滿足項目的需求。通過研究,選擇了RabbitMQ消息服務中間件,采用發布/訂閱消息的模式進行數據的傳輸。當報警接入服務產生報警信息時,需要將數據“發布”到RabbitMQ 的消息隊列中,消息隊列會自動將數據推送到事先“訂閱”該消息的系統,例如事件轉換服務。所以,若某個接入服務需要獲得接入消息,只需事先“訂閱”該消息即可,如果不需要該類消息,只需“取消訂閱”即可。同樣,例如廣播和輔助照明接入服務需要獲取控制命令信息,只要通過消息服務中間件訂閱這些消息即可。通過消息服務中間件,報警聯動管理平臺軟件內部的各個接收和轉發模塊,就可以徹底的解耦了。同時,消息傳輸的實時性和可靠性,都獲得極大的提高。

3.3 應用框架層

應用框架層是平臺的最終用戶GUI,提供各類應用及前端呈現,以友好的用戶界面進行平臺數據的查詢和管理。它具有更強的業務性,可以統一監視、控制和管理所有可視、可控的安防設備,并快速可視化定義跨系統的信息交換或設備聯動規則。

3.4 平臺物理架構

平臺的物理架構根據業務系統劃分為安防業務、視頻業務和通用業務,主要由相關的服務器設備來承載。每個服務器作為負責業務模塊的獨立單位進行部署。平臺物理架構如圖2 所示。

4 系統功能架構設計

安防系統主要對多個子系統進行集成,將孤立的系統整合為有機整體,實現信息交互,保證在報警發生時,聯動子系統完成突發事件處理。因此將系統功能設計為兩種模式：日常模式和報警模式。在日常模式下,主要包含視頻調閱、電子地圖、輔助照明、廣播控制和系統配置等功能。在報警模式下,主要包含報警管理和視頻、廣播、燈光聯動功能。

圖2 系統集成平臺物理架構示意圖

4.1 日常模式

該模式主要為了機場工作人員日常工作時通過檢查圍界視頻圖像,判斷飛行區周圍環境是否正常,是否存在不明人員徘徊,對智能分析系統進行報警區域規劃調整。

通過圍界廣播與現場巡邏以及崗亭工作人員進行指揮和溝通,上報正常或者異常情況。

在現場光照不足時,通過手動開啟輔助照明系統對現場環境進行補光,并按照季節變化,進行夜間打開輔助照明,白天關閉輔助照明的自動配置。

在電子地圖上查看所有設備的狀態和分布,同時能快速的預覽每一個攝像頭的視頻圖像。

針對歷史的報警信息進行檢索、分類、過濾、打印等工作,供機場工作人員分析和預測。

日常模式的功能主要在應用框架層實現,根據視頻設備廠家提供的SDK,實現實時視頻調閱、歷史錄像查詢、錄像播放控制、錄像下載、球機控制等功能。

在應用框架層實現輔助照明控制的應用界面,通過調用廠家的SDK,實現輔助照明的開關控制。

在應用框架層實現廣播控制的應用界面,通過調用廠家的SDK,實現廣播的遠程喊話功能和播放警示音功能。

4.2 報警模式

該模式是圍界在發生人員進入警戒區域或者觸碰攀爬圍界時引發的一系列聯動操作,在系統的呈現端電子地圖上居中顯示發生報警的防區以及報警的級別、類型等。

在大屏顯示系統中切換發生報警的防區關聯的攝像機的視頻圖像,如果該防區配置了一體化球機,則調用相應的球機預置位指向防區位置,顯示清晰的詳情信息。

聯動圍界廣播系統,在報警發生的防區播放警示音,同時打通指揮室或者附近崗亭的喊話通道,對前端的報警行為進行勸阻和警示。

聯動輔助照明系統,打開報警防區范圍的燈光,照亮周圍環境,確保工作人員能夠清晰了解現場情況。

工作人員處理完畢該防區報警信息后,聯動關閉,系統返回到日常模式中。

報警模式的功能主要在服務層實現,由聯動服務完成子系統的聯動控制功能,聯動服務設計為windows 服務的方式,隨服務器系統啟動。

通過RabbitMQ 注冊報警消息,當RabbitMQ隊列里收到圍界報警消息和視頻預警消息時,轉發給聯動服務,調用預先定義好的聯動配置,調用視頻的SDK,驅動球機移動到報警點位置。在聯動配置中取出報警防區對應的廣播功放ID,調用廣播系統的SDK,在指定的廣播號角播放報警語音。調用輔助照明系統提供的SDK,打開對應照明。

5 系統調試與優化

穩定性調試采用由局部到整體的方案：調試每個微服務模塊的穩定性,再整體聯調,跟蹤平臺的穩定性,避免微服務模塊出現問題后在系統運行中不斷放大。

性能調試采用由整體到局部的方案：將經過穩定性調試完畢的系統根據功能列表逐一檢查運行效率,找出性能不足,檢查實現該功能的整個環節的性能指標加以完善。

調試時發現,微服務架構隔離了不同模塊間的差異,避免了連鎖反應,增強了穩定性,但導致日志信息過于分散,無法進行篩選檢索。為此,使用日志分析組件,調整代碼,將微服務日志都調用日志分析組件的接口,由日志分析組件來接收所有日志信息,并通過其檢索篩選工具定位問題。

Redis 數據庫改善了檢索性能,但設備呈現性能出現了瓶頸,過多設備一次性顯示在電子地圖上會出現感覺延遲。為此,采用分組顯示、延遲加載,將所有設備根據區域不同分成多組,在需要顯示設備時,將設備信息在內存中緩存好,當要查看某個區域設備時,只呈現這部分的數據,大幅提升顯示速度。

6 結論

基于機場飛行區新舊安防系統并存從而導致管理難度提升的現狀,提出解決方案：放棄直觀單體架構,采用微服務架構將新舊安防系統從設計上隔離,實現模塊間松耦合和高內聚。減少模塊間關聯程度,在保證獨立性的同時為模塊更新、部署、問題調試提供便利,降低開發調試工作量與維護成本。采用Redis 內存數據庫,緩存大量設備配置、聯動配置信息,通過哈希算法快速查詢數據,避免頻繁訪問數據庫引起性能瓶頸,加快響應速度。微服務和Redis優缺點并存,需平衡二者結合實踐摸索完善,讓技術更好地為項目服務。