一種智能樓宇的視頻監控系統的設計

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

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

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

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

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