視頻監(jiān)控是智能樓宇重要的組成部分，傳統(tǒng)的視頻監(jiān)控只停留在本地化的人機監(jiān)控狀態(tài)，未能實現(xiàn)樓宇的自動化管理，這很大地限制了智能樓宇的發(fā)展。隨著網(wǎng)絡(luò)技術(shù)的成熟和發(fā)展，智能化視頻監(jiān)控在智能樓宇中得到廣泛應(yīng)用。介紹了智能化視頻監(jiān)控在智能樓宇中的典型應(yīng)用場景，包括周界防范、區(qū)域防空報警、智能人臉識別以及煙火檢測報警。
本文設(shè)計了一種智能樓宇的視頻監(jiān)控系統(tǒng)，并從硬件設(shè)計和軟件設(shè)計兩方面來闡述該系統(tǒng)。
1 系統(tǒng)的硬件框架
整個硬件系統(tǒng)由信號處理板、信號轉(zhuǎn)換板、上位機以及CMOS圖像傳感器組成。信號處理板以S3C2416處理器為核心。S3C2416是一款以SAMSUNGARM9（ARM926EJ）為內(nèi)核的處理器，由于低功耗、高性能、低成本的性價比優(yōu)勢，在實際中具有廣泛應(yīng)用。為了簡化信號處理板的硬件設(shè)計，同時兼顧系統(tǒng)與實際場所的兼容性，本系統(tǒng)設(shè)計了一種以STM32為核心處理器的信號轉(zhuǎn)換板，信號轉(zhuǎn)換板可根據(jù)接收的數(shù)據(jù)生成對應(yīng)的控制信號來驅(qū)動相應(yīng)的執(zhí)行機構(gòu)。這樣只需修改信號轉(zhuǎn)換板的硬件設(shè)計，就能使系統(tǒng)很好地適應(yīng)各種不同的應(yīng)用場景。上位機與信號處理板之間通過網(wǎng)線連接。CMOS圖像傳感器直接與信號處理板連接。
系統(tǒng)的硬件總體架構(gòu)如圖1所示。

圖1 系統(tǒng)的硬件總體架構(gòu)
2 系統(tǒng)的軟件架構(gòu)
以S3C2416為核心的信號處理板，需要分別與上位機和信號轉(zhuǎn)換板進行通信。信號處理板需要為上位機提供查詢服務(wù)和設(shè)置服務(wù)。上位機端軟件通過切換不同的算法，可以適應(yīng)例如的不同的應(yīng)用場景，可以下發(fā)經(jīng)PC端算法處理后得到的控制信號，也可以發(fā)送相關(guān)指令，讓信號處理板上傳實時圖像和設(shè)備的運行狀態(tài)等。信號處理板也需要為信號轉(zhuǎn)換板提供控制服務(wù)，信號處理板根據(jù)實時的處理結(jié)果或者上位機下發(fā)的控制信號，下發(fā)對應(yīng)的控制信號給信號轉(zhuǎn)換板，信號轉(zhuǎn)換板依據(jù)接收到數(shù)據(jù)，生成相應(yīng)的控制信號以驅(qū)動對應(yīng)的執(zhí)行機構(gòu)。
2．1設(shè)備間通信協(xié)議設(shè)計
信號處理板與上位機之間的通信數(shù)據(jù)類型主要有三大類，種是信號處理板實時的圖像信息，第二種是信號處理板上傳的設(shè)備的運行狀態(tài)信息，第三種是上位機下發(fā)的控制指令。由于涉及圖像的傳輸，而且本系統(tǒng)中單幀數(shù)據(jù)就達到640*512個字節(jié)，為了保證圖像傳輸?shù)膶崟r性，信號處理板與上位機之間的通信采用網(wǎng)絡(luò)通信。
信號處理板與信號轉(zhuǎn)換板之間的通信數(shù)據(jù)類型主要有兩大類，種是信號處理板下發(fā)的控制信號的指令，第二種是信號轉(zhuǎn)換板上傳的應(yīng)答信號。由于信號處理板與信號轉(zhuǎn)換板之間傳輸?shù)膯未螖?shù)據(jù)量較小，所以通過UART來進行通信。
2．1．1網(wǎng)絡(luò)通信協(xié)議
針對網(wǎng)絡(luò)通信，本系統(tǒng)采用TCP／IP協(xié)議，該協(xié)議在傳輸層分別有TCP協(xié)議和UDP協(xié)議，雖然UDP協(xié)議在傳輸速度上有較大優(yōu)勢，但是數(shù)據(jù)傳輸?shù)臏蚀_性得不到保障，而TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，所以采用TCP協(xié)議便可保證數(shù)據(jù)傳輸過程的準確性。由于有些應(yīng)用場景需要上位機對圖像進行算法分析再將控制信號下發(fā)給信號處理板，所以本系統(tǒng)中傳輸層的通信協(xié)議選用TCP協(xié)議，但是TCP是基于字節(jié)流的，所以必須解決半包讀寫和粘包問題。
常見的處理方法有如下幾種：
方法1：定長消息，每個報文長度固定，不夠補空格；
方法2：使用回車換行符分割，在包尾加上分割符，例如FTP協(xié)議；
方法3：消息分割，頭為長度（消息總長度或消息體長度），通常頭用一個int32表示。
其中方法1通常適合長度不是很長的數(shù)據(jù)，但在本系統(tǒng)中傳輸?shù)囊粠瑘D像數(shù)據(jù)就達到640*512個字節(jié)，數(shù)據(jù)量較大，所以方法1不合適。由于傳輸?shù)氖菆D像數(shù)據(jù)，圖像中連續(xù)的幾個像素點對應(yīng)的字符很有可能與固定字符相重復(fù)，因此若采用以固定字符區(qū)分的方法2，必須對原始圖像數(shù)據(jù)進行遍歷，并對相關(guān)字符進行轉(zhuǎn)義，但這樣計算量過大，會增加系統(tǒng)額外開銷，所以方法2也不合適。本系統(tǒng)采用方法3來設(shè)計網(wǎng)絡(luò)通信協(xié)議，終的網(wǎng)絡(luò)通信協(xié)議格式如圖2所示：

圖2 網(wǎng)絡(luò)通信協(xié)議格式
1）數(shù)據(jù)長度：前4個字節(jié)代表數(shù)據(jù)長度n，對應(yīng)一個int32型整數(shù)，所以該協(xié)議傳輸?shù)拇髷?shù)據(jù)長度為232個字節(jié)。
2）數(shù)據(jù)類型：第5個字節(jié)代表不同的數(shù)據(jù)類型，例如0x01表示圖像數(shù)據(jù)的上傳，0x02代表控制指令的下發(fā)，0x04表示算法切換，此位可依據(jù)系統(tǒng)的功能進行拓展。
3）數(shù)據(jù)：從第6個字節(jié)開始的n個字節(jié)代表數(shù)據(jù)。
2．1．2串口通信協(xié)議
對于串口通信，必須解決數(shù)據(jù)傳輸過程中的可靠性問題，為此本系統(tǒng)設(shè)計了如圖3的串口通信協(xié)議。

圖3 串口通信協(xié)議格式
1）起始標志：1個字節(jié)，用十六進制可表示為F0H。
2）數(shù)據(jù)長度：1個字節(jié)代表數(shù)據(jù)長度n，所以該協(xié)議傳輸?shù)拇髷?shù)據(jù)長度為256個字節(jié)。
3）數(shù)據(jù)類型：1個字節(jié)代表數(shù)據(jù)類型，例如0x01表示要求信號轉(zhuǎn)換板根據(jù)有效數(shù)據(jù)生成對應(yīng)的繼電器信號，此位可進行拓展以驅(qū)動不同的驅(qū)動機構(gòu)。
4）數(shù)據(jù)：n個字節(jié)的數(shù)據(jù)。
5）校驗位：n個字節(jié)的數(shù)據(jù)按位異或。
6）結(jié)束標志：1個字節(jié)，用十六進制可表示為FFH。
同時，在串口的通信的設(shè)計過程中，參考了TCP協(xié)議中ACK的思想，當信號轉(zhuǎn)換板收到一個命令后，會對數(shù)據(jù)格式進行校驗，校驗后則會回復(fù)一個包含一位數(shù)據(jù)校驗是否通過的確認信號。信號處理板如果在發(fā)送指令500ms依舊沒有收到確認信號或者收到的確認信號表明數(shù)據(jù)接收有誤，則再次發(fā)送該命令，如果累計發(fā)送10次后依舊沒有收到正確的確認信號，則認為此鏈路存在通信故障，信號處理板則通過網(wǎng)絡(luò)將鏈路通信故障的錯誤信息反饋給上位機。
2．2信號處理板中軟件設(shè)計
信號處理板中主要有兩個線程：一個線程專門負責圖像的采集和處理，主要完成對圖像的實時采集，并對采集到的一幀圖像按照上位機設(shè)定的模式，完成上傳圖像、算法分析以及生成控制信號并通過UART口發(fā)送到信號轉(zhuǎn)換板中的部分或全部過程。信號處理板作為C／S架構(gòu)的服務(wù)器端，為了保證響應(yīng)的實時性；第二個線程專門監(jiān)聽網(wǎng)絡(luò)端口，如果有命令發(fā)送過來，則根據(jù)解析的結(jié)果，完成參數(shù)的讀取、模式的切換、算法的切換、控制信號的生成以及通信鏈路通斷的判斷等。
網(wǎng)絡(luò)通信過程中的I／O模型主要分為同步I／O和異步I／兩大類。同步I／O的主要缺點是在進行I／O的過程中函數(shù)無法立即返回，從而導(dǎo)致其他任務(wù)無法執(zhí)行，但是在異步I／O中，無論數(shù)據(jù)是否完成交換都立即返回函數(shù)，因此不影響執(zhí)行其他任務(wù)，所以異步方式比同步方式能更有效地使用CPU資源，同時系統(tǒng)的響應(yīng)實時性也較好。由于信號處理板上運行的是Linux系統(tǒng)，以本系統(tǒng)采用epoll模型。信號處理板的業(yè)務(wù)流程如圖4所示。

圖4 信號處理板的業(yè)務(wù)流程圖
2．3上位機軟件設(shè)計
本系統(tǒng)基于Qt開發(fā)了一套上位機監(jiān)控軟件，該軟件主要提供監(jiān)控界面，界面的要素包括所連接設(shè)備（即信號處理板）的IP地址和端口號的設(shè)置、實時圖像顯示框、設(shè)備的運行狀態(tài)以及應(yīng)用場景的切換等。同時上位機軟件也能對實時的圖像數(shù)據(jù)按照設(shè)定要求進行分析處理，并將分析處理后生成的控制信號通過網(wǎng)絡(luò)下發(fā)至信號處理板。
該上位機軟件與信號處理板構(gòu)成C／S架構(gòu)，該軟件作為客戶端，信號處理板作為服務(wù)器端?？紤]服務(wù)器端的套接字資源，并且鑒于此客戶端和服務(wù)器端的通信屬于長連接，所以上位機軟件在與信號處理板建立連接后，需要定時發(fā)送一個心跳包，以此來判斷通信鏈路是否正常，如果服務(wù)器端長時間沒有接收到此心跳包，則斷開對應(yīng)的socket連接，釋放相應(yīng)套接字資源。客戶端軟件通過對發(fā)送心跳包時所使用的系統(tǒng)函數(shù)write()的返回值，便可以判斷鏈路是否正常，如果異常，則釋放之前的套接字資源后再次進行連接，如果嘗試10次后依舊不能正常建立連接，則在界面上顯示網(wǎng)絡(luò)連接失敗。
2．4信號轉(zhuǎn)換板中軟件設(shè)計
信號轉(zhuǎn)換板主要完成接收來自信號處理板的數(shù)據(jù)，并根據(jù)解析結(jié)果產(chǎn)生相應(yīng)的控制信號以驅(qū)動對應(yīng)的執(zhí)行機構(gòu)。ST*提供了豐富的庫函數(shù)，這樣使得STM32的軟件開發(fā)過程大大簡化，在完成基本的配置后，只需完成應(yīng)用層程序的編寫即可。終，考慮實時性，設(shè)計的程序在中斷中完成數(shù)據(jù)的接收，并將接收的數(shù)據(jù)拷貝到一個靜態(tài)緩沖區(qū)中。主線程循環(huán)對靜態(tài)緩沖區(qū)中的數(shù)據(jù)進行讀取，并根據(jù)自定義的串口通信協(xié)議對數(shù)據(jù)進行解析和校驗，如果校驗通過則回復(fù)表示數(shù)據(jù)接收正確的ACK信號，并生成對應(yīng)的控制信號，如果校驗不通過則回復(fù)表示數(shù)據(jù)接收錯誤的ACK信號。
2．5圖像分析算法設(shè)計
本系統(tǒng)作為一種視頻監(jiān)控，可以根據(jù)不同的場景切換不同的算法。一些識別算法，例如煙火檢測報警，只要在PC端通過訓練和測試過程得到模型后，就可以編寫代碼，然后移植到嵌入式設(shè)備中，當然此類識別算法也可以集成在上位機軟件中。
但是一些匹配算法，例如基于人臉識別的門禁系統(tǒng)中所用的算法，在完成人臉識別后，需要將提取的特征與數(shù)據(jù)庫中的特征進行匹配，以確定此人是否具有相應(yīng)的權(quán)限，如果運行在嵌入式設(shè)備上，不僅浪費有限的存儲空間，而且在匹配過程中消耗大量的系統(tǒng)資源，影響系統(tǒng)的實時性；再者門禁系統(tǒng)存在添加和刪除某些人的權(quán)限的可能，如果將特征存放在嵌入式設(shè)備中，這樣后期的維護升級難度較大，因此這類算法應(yīng)該運行在上位機。
3 結(jié)束語
可拓展性和兼容性是本系統(tǒng)的一大特色，現(xiàn)今樓宇中存在的大量傳感器，例如微波傳感器、濕度傳感器等，這些可以直接與本系統(tǒng)中的信號轉(zhuǎn)換板相連，信號轉(zhuǎn)換板接收到傳感器數(shù)據(jù)后上傳至信號處理板，為信號處理板生成控制信號提供依據(jù)，這些在軟件層面進行修改便可實現(xiàn)，減少了后期的升級改造成本。