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

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

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

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

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