軌道交通視頻監(jiān)控子系統(tǒng)的研究與實現(xiàn)

趙軍鋒　李上　高曉軍　杜慶偉

[摘要]軌道交通綜合監(jiān)控系統(tǒng)中的視頻監(jiān)控子系統(tǒng)（CCTV）對于軌道交通的安全運行具有非常重要的作用，首先介紹了視頻監(jiān)控子系統(tǒng)的總體架構(gòu)和軟、硬件體系結(jié)構(gòu)，然后重點介紹了其實時監(jiān)控模塊的工作原理，特別是訂閱，發(fā)布機制，該機制可以有效地避免重復(fù)訂閱所導(dǎo)致的冗余視頻流。基于訂閱，發(fā)布機制，系統(tǒng)實現(xiàn)了序列監(jiān)控的功能。最后，針對性能的不足，系統(tǒng)分別對視頻頭處理、視頻數(shù)據(jù)傳輸?shù)葯C制進行了分析和優(yōu)化，取得了良好的效果。

[關(guān)鍵詞]軌道交通；視頻監(jiān)控；訂閱發(fā)布；模塊化；序列監(jiān)控

城市軌道交通視頻監(jiān)控系統(tǒng)是行車組織和客運組織重要的輔助設(shè)備，是保證運輸安全、應(yīng)對緊急事態(tài)的重要手段，是軌道交通綜合監(jiān)控系統(tǒng)中不可或缺的一環(huán)。對此，研究開發(fā)了不少的視頻監(jiān)控系統(tǒng)或解決方案，如文獻等。本司正在開發(fā)有軌電車綜合調(diào)度與控制系統(tǒng)（TICC），因為應(yīng)用背景和要求不同，所以對視頻監(jiān)控進行了重點投入，實現(xiàn)了一套適應(yīng)于大規(guī)模攝像頭環(huán)境下的高性能視頻監(jiān)控系統(tǒng)，并對系統(tǒng)的具體實現(xiàn)加以闡述，

1軌道交通的總體架構(gòu)

文獻指出，數(shù)字視頻監(jiān)控系統(tǒng)是城市軌道交通系統(tǒng)中的重要網(wǎng)絡(luò)應(yīng)用，應(yīng)以數(shù)字化、綜合化和智能化為基礎(chǔ)。為此，CCTV子系統(tǒng)采用了有軌電車綜合調(diào)度與控制系統(tǒng)的布局，分為三級控制，如圖l所示。其中實線是主要的控制，數(shù)據(jù)通路，而虛線是輔助通路。

這種架構(gòu)考慮了整個結(jié)構(gòu)的清晰性，三級層次分明：但是考慮到部分操作如果通過控制中心端系統(tǒng)來進行中轉(zhuǎn)，則降低了系統(tǒng)的效率，所以部分控制命令是由客戶端直接對車站端系統(tǒng)進行操縱的。

1.1系統(tǒng)的硬件體系架構(gòu)

根據(jù)總體架構(gòu)的思想，系統(tǒng)的硬件系統(tǒng)架構(gòu)如圖2所示。

在車站監(jiān)控一級，設(shè)置一臺工控機，通過高性能交換機與車站各設(shè)備相連，包括數(shù)字高清網(wǎng)絡(luò)攝像頭、NVR等。其中攝像頭具有字符疊加功能，能將攝像機的日期和時間等信息進行疊加。不同于文獻，本系統(tǒng)全部采用了遠程網(wǎng)絡(luò)進行視頻數(shù)據(jù)的傳輸，即采用了網(wǎng)絡(luò)攝像頭，通過TCP/IP協(xié)議直接進行遠程訪問。NVR負(fù)責(zé)讀取攝像頭的視頻數(shù)據(jù)形成歷史視頻，在規(guī)定的時間，備份到控制中心。

在控制中心，設(shè)置高性能服務(wù)器若干，進行整個監(jiān)控系統(tǒng)的信息處理（包括事件數(shù)據(jù)接收、事件分析和處理等）?？刂浦行男枰哂写笕萘看疟P控制器保存歷史視頻文件信息（稱為視頻數(shù)據(jù)庫服務(wù)器），需要有實時數(shù)據(jù)庫支持關(guān)鍵數(shù)據(jù)的處理，還要有歷史數(shù)據(jù)庫進行事件等的備份。以上數(shù)據(jù)庫服務(wù)器下文統(tǒng)一稱為數(shù)據(jù)庫服務(wù)器。

其中實時數(shù)據(jù)庫又稱為內(nèi)存數(shù)據(jù)庫，是開發(fā)實時監(jiān)控、數(shù)據(jù)實時采集等功能的支撐軟件，可以獲取企業(yè)運行過程中的各種數(shù)據(jù)，并將其轉(zhuǎn)化為對各類業(yè)務(wù)有效的公共信息，滿足對實時信息完整性、一致性、安全共享的需求，可以方便地進行系統(tǒng)監(jiān)控和優(yōu)化控制。實時數(shù)據(jù)庫在CCTV子系統(tǒng)中同樣起著重要的作用，例如，將部分運行參數(shù)、攝像頭的訂閱情況等信息備份在實時數(shù)據(jù)庫中，當(dāng)系統(tǒng)啟動，恢復(fù)時，可以及時快速地獲取相關(guān)參數(shù)，加快啟動/恢復(fù)過程。

客戶端由普通的PC組成，可以和控制中心，甚至車站端進行交互。

由于本系統(tǒng)采用專網(wǎng)，所以暫不考慮安全問題，沒有設(shè)置網(wǎng)絡(luò)防火墻等安全設(shè)備。

1.2系統(tǒng)的軟件體系架構(gòu)

系統(tǒng)采用分層、模塊化設(shè)計思想，采用C/S架構(gòu)，遵循以下原則：

1）兩層控制：客戶端、控制中心層協(xié)調(diào)運作，為操作員提供高性能的視頻監(jiān)控功能。

2）標(biāo)準(zhǔn)l生原則：平臺采用TCP/IP、NTP等通用協(xié)議。

3）控制信令與媒體數(shù)據(jù)分離原則：便于提高控制信令和媒體的處理能力。

4）低耦合性的設(shè)計原則，各個模塊獨立性盡可能高，可以有效提高系統(tǒng)的可維護性。

其系統(tǒng)結(jié)構(gòu)如圖3所示：

1）基礎(chǔ)/硬件平臺：提供最基礎(chǔ)的軟件平臺/硬件驅(qū)動程序，是整個系統(tǒng)的基礎(chǔ)。

2）接口A：系統(tǒng)通過接口A為軟件平臺服務(wù)組件提供網(wǎng)絡(luò)，硬件等的接入服務(wù)。

3）軟件支撐平臺：將自主開發(fā)的基礎(chǔ)性軟件模塊進行歸納，形成軟件支撐平臺，包括數(shù)據(jù)庫、通信平臺等底層軟件平臺，以及文件傳送、權(quán)限管理、告警管理等應(yīng)用支撐軟件平臺。

4）接口B：通過接口B為上層業(yè)務(wù)提供支持，實現(xiàn)性軟件模塊與系統(tǒng)應(yīng)用的有機整合。

5）系統(tǒng)應(yīng)用：由多個處理具體應(yīng)用邏輯的模塊組成，之間保持相互獨立。

6）人機界面：所有的應(yīng)用通過人機界面，實現(xiàn)應(yīng)用層次上的集成，形成一個完整的系統(tǒng)。

2實時視頻數(shù)據(jù)采集的設(shè)計和實現(xiàn)

2.1訂閱，分發(fā)模型的定義

實時視頻監(jiān)控是CCTV子系統(tǒng)的核心。軌道交通環(huán)境下，視頻監(jiān)控有著不同的特點：

1）攝像頭密度大，數(shù)量眾多。這對整個視頻監(jiān)控提出了很高的性能要求。

2）視頻數(shù)據(jù)與其它監(jiān)控數(shù)據(jù)通過同一個城域網(wǎng)進行數(shù)據(jù)傳輸，如果視頻流數(shù)據(jù)太多，很容易對其他監(jiān)控數(shù)據(jù)產(chǎn)生較大影響。

以上特點要求系統(tǒng)必須精心設(shè)計。

實時性的聯(lián)機服務(wù)要求，實時視頻監(jiān)控必須以信息流的方式把實時采集的視頻數(shù)據(jù)及時傳輸?shù)娇蛻舳说牟シ沤缑?。?dāng)前攝像頭廠商提供的例程往往采用直連模式，即將播放屏幕和攝像頭進行關(guān)聯(lián)，直接播放視頻。但是這種方式極易造成信息流的冗余，浪費帶寬。假設(shè)n個用戶同時監(jiān)控相同的m個攝像頭，那么就需要m×n個視頻信息流同時在網(wǎng)絡(luò)上傳輸，冗余度為n，極大的浪費了帶寬。為此系統(tǒng)采用了訂閱/分發(fā)模型，形成視頻分發(fā)矩陣，來降低視頻數(shù)據(jù)的冗余度。

定義1：視頻分發(fā)矩陣，是一種數(shù)據(jù)結(jié)構(gòu)，保存了視頻流與客戶播放屏幕的對應(yīng)關(guān)系。

定義2：訂閱，分發(fā)模型定義了一種一對多的依賴關(guān)系，基于中介讓多個訂閱者同時監(jiān)聽某一個實時視頻對象。當(dāng)視頻對象產(chǎn)生新數(shù)據(jù)，介會通知所有訂閱者對象接收新的視頻數(shù)據(jù)。

系統(tǒng)中，由服務(wù)器承擔(dān)中介的角色，對客戶端的訂閱請求進行監(jiān)聽，實時更改訂閱信息。流程見圖4。

通過訂閱，分發(fā)模型可以將這視頻產(chǎn)生者和視頻消費者封裝在獨立的對象中，它們可以各自獨立地改變和復(fù)用。訂閱/分發(fā)模型所做的工作其實就是解耦合。這樣，通過中介的一次中轉(zhuǎn)，使得長距離視頻數(shù)據(jù)的傳輸只需要一個副本，可以大大降低視頻數(shù)據(jù)的冗余度，降低網(wǎng)絡(luò)帶寬的負(fù)載。

在內(nèi)存以及實時數(shù)據(jù)庫中，保存了所有視頻攝像頭的信息（classgc_DataLIst），作為全局信息，提供服務(wù)。其中包括了相關(guān)的訂閱者信息，以及對應(yīng)的視頻頭信息。

2.2訂閱，分發(fā)模型的實現(xiàn)

圖3中，如果要登錄攝像頭，需要將一個回調(diào)函數(shù)注冊給指定的攝像頭，一旦登錄完成，攝像頭便利用此函數(shù)向系統(tǒng)返回視頻頭，視頻，系統(tǒng)收到數(shù)據(jù)后才能進行相關(guān)的處理。

void CALLBACK PsDataCallBack（LONG 1RealHandle，DWORDdwDataType，BYTE*pPacketBuffer，DWORD nPacketSize，void*pUser）

其中，1RealHandle是登錄攝像頭后給出的句柄，用于判斷是哪一個攝像頭發(fā)過來的數(shù)據(jù)。

dwDataType是攝像頭給出的數(shù)據(jù)類型，分為兩類信息，第一類是關(guān)鍵的視頻頭信息（dwDataType==NET DVR SYSHEAD），第二類是視頻本身數(shù)據(jù)。

由于視頻頭對于播放視頻來說至關(guān)重要，不能丟失，因此把視頻頭作為控制命令，利用TCP協(xié)議返回給訂閱者。特別的，對于第一個訂閱用戶，系統(tǒng)還無法在登錄攝像頭時立即獲得視頻頭，必須等待攝像頭返回其視頻頭。此后才能發(fā)給客戶端。一般來說，只有第一個訂閱者請求訂閱的時候才需要，但是考慮到并發(fā)性，必須對分發(fā)矩陣中所有訂閱該攝像頭的訂閱者進行返回。

視頻本身數(shù)據(jù)，丟掉若干幀，影響不大，所以可以采用效率高的UDP協(xié)議?？紤]到不同子系統(tǒng)（如環(huán)控、電力子系統(tǒng)等）和本子系統(tǒng)是獨立的，以及實現(xiàn)的簡單性，所以沒有采用RTP協(xié)議。

在刪除用戶的時候，必須進行上鎖，否則會導(dǎo)致視頻分發(fā)過程中，訪問已經(jīng)銷毀、不存在的用戶節(jié)點，進而導(dǎo)致系統(tǒng)崩潰。

服務(wù)器端在處理完畢視頻訂閱（包括相應(yīng)的登錄過程）后，就可以接收到攝像頭發(fā)送的視頻數(shù)據(jù)，并進行后續(xù)的視頻分發(fā)過程，如圖5所示。

3序列監(jiān)控

有了訂閱和發(fā)布機制，序列監(jiān)控就很容易實現(xiàn)了，系統(tǒng)在客戶端定義了一個線程進行序列監(jiān)控，每秒鐘執(zhí)行下面算法一次。for（每個播放屏幕）

{

當(dāng)前攝像頭的播放時間++：

if（當(dāng)前攝像頭的播放時間==當(dāng)前攝像頭的規(guī)定播放時間），//這個攝像頭播放時間已結(jié)束

{

Cancel_order（當(dāng)前攝像頭）；

當(dāng)前攝像頭的播放時間=0：

if（當(dāng)前攝像頭是序列中的最后一個攝像頭）

當(dāng)前攝像頭=序列中的第一個攝像頭：

else

當(dāng)前攝像頭=序列中的下一個攝像頭：

Order（當(dāng)前攝像頭）：

}}

4性能的優(yōu)化

4.1視頻頭的處理

在上面的實現(xiàn)中，發(fā)現(xiàn)視頻經(jīng)常延遲很久才能播放，甚至產(chǎn)生卡住的現(xiàn)象，分析認(rèn)為，可能是因為采用TCP傳輸視頻頭，導(dǎo)致視頻頭到達客戶端遲緩過大所造成的。為此，系統(tǒng)進行了針對視頻頭的優(yōu)化過程。

優(yōu)化后的系統(tǒng)將視頻頭事先保存入歷史數(shù)據(jù)庫中，當(dāng)系統(tǒng)啟動時，讀人每個攝像頭的視頻頭信息到實時數(shù)據(jù)庫，當(dāng)某個客戶的一個屏幕訂閱一個攝像頭時，先去實時數(shù)據(jù)庫中獲得視頻頭，放人播放屏幕，客戶端就可以不用接收從控制中心服務(wù)器發(fā)來的視頻頭信息了，然后再去進行訂閱，

這樣的處理，視頻頭的獲取模式，由控制中心查找視頻頭信息發(fā)給客戶端，轉(zhuǎn)變成為客戶端主動去拉取視頻頭信息，極大地減少了視頻頭的等待時間，同時改變了先有視頻數(shù)據(jù)，后有視頻頭的不正常順序。運行表明此項優(yōu)化取得了良好的效果，后續(xù)的視頻數(shù)據(jù)不再產(chǎn)生卡住的現(xiàn)象，播放也快多了。

4.2播放性能的優(yōu)化

實現(xiàn)后的系統(tǒng)，每秒鐘只有幾幀圖片，視頻很不連貫。在客戶端改為多線程機制進行處理依然效果不佳。為此，系統(tǒng)進行了代碼的分析和優(yōu)化。

未優(yōu)化的處理，每當(dāng)一個視頻數(shù)據(jù)到來，控制中心程序都是到gc DataLIst類中去遍歷一遍，查找到攝像頭后，再找到訂閱者列表，將該視頻數(shù)據(jù)列表中的各個客戶端。而客戶端則在自己的內(nèi)存中遍歷一個列表，找到播放屏幕號后，再把視頻數(shù)據(jù)填入該屏幕。兩邊的遍歷過程，降低了系統(tǒng)的處理性能，甚至導(dǎo)致UDP數(shù)據(jù)傳輸過程中的丟失。

為此，系統(tǒng)在客戶端和控制中心服務(wù)器端分別設(shè)置了—個Hash表，在控制中心以攝像頭句柄為Hash值，在客戶端以攝像頭編號為Hash值，省略了兩端的遍歷過程。該優(yōu)化取得了良好的效果，視頻非常流暢。

4.3負(fù)載均衡

未優(yōu)化前，在控制中心，只采用了一個UDP對象來進行傳輸，考慮到控制中心擔(dān)負(fù)著很重的負(fù)載，如果只通過一個UDP對象發(fā)送，可能會導(dǎo)致該UDP對象的緩存很快消耗完，為此，在控制中心設(shè)置了n（可以設(shè)置）個UDP對象，根據(jù)（攝像頭編號mod n）來確定使用哪一個UDP對象進行傳輸。實現(xiàn)了簡單的負(fù)載均衡。

在大規(guī)模驗證環(huán)境下，系統(tǒng)沒有表現(xiàn)出視頻卡、頓的情況，表現(xiàn)依然流暢。

5結(jié)束語

介紹了視頻監(jiān)控子系統(tǒng)的總體架構(gòu)，分為三個層次，分別是車站端系統(tǒng)、監(jiān)控中心端系統(tǒng)和客戶端系統(tǒng)?；诳傮w架構(gòu)，規(guī)劃了系統(tǒng)的軟、硬件體系架構(gòu)，然后重點介紹了視頻監(jiān)控子系統(tǒng)中重要的模塊——實時監(jiān)控模塊的工作原理，特別是其所采用的訂閱，分發(fā)機制，該機制可以有效地避免重復(fù)訂閱所導(dǎo)致的冗余視頻流?；谟嗛?架構(gòu)機制，視頻監(jiān)控子系統(tǒng)還實現(xiàn)了序列監(jiān)控的功能。最后，針對初步實現(xiàn)的系統(tǒng)所表現(xiàn)出的性能不足，系統(tǒng)分別對視頻頭處理、視頻數(shù)據(jù)傳輸?shù)葯C制進行了分析和優(yōu)化，取得了良好的效果。

[責(zé)任編輯：王偉平]