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

圖1 系統(tǒng)的硬件總體架構(gòu)
2 系統(tǒng)的軟件架構(gòu)
以S3C2416為核心的信號處理板，需要分別與上位機和信號轉(zhuǎn)換板進行通信。信號處理板需要為上位機提供查詢服務和設置服務。上位機端軟件通過切換不同的算法，可以適應例如的不同的應用場景，可以下發(fā)經(jīng)PC端算法處理后得到的控制信號，也可以發(fā)送相關(guān)指令，讓信號處理板上傳實時圖像和設備的運行狀態(tài)等。信號處理板也需要為信號轉(zhuǎn)換板提供控制服務，信號處理板根據(jù)實時的處理結(jié)果或者上位機下發(fā)的控制信號，下發(fā)對應的控制信號給信號轉(zhuǎn)換板，信號轉(zhuǎn)換板依據(jù)接收到數(shù)據(jù)，生成相應的控制信號以驅(qū)動對應的執(zhí)行機構(gòu)。
2．1設備間通信協(xié)議設計
信號處理板與上位機之間的通信數(shù)據(jù)類型主要有三大類，種是信號處理板實時的圖像信息，第二種是信號處理板上傳的設備的運行狀態(tài)信息，第三種是上位機下發(fā)的控制指令。由于涉及圖像的傳輸，而且本系統(tǒng)中單幀數(shù)據(jù)就達到640*512個字節(jié)，為了保證圖像傳輸?shù)膶崟r性，信號處理板與上位機之間的通信采用網(wǎng)絡通信。
信號處理板與信號轉(zhuǎn)換板之間的通信數(shù)據(jù)類型主要有兩大類，種是信號處理板下發(fā)的控制信號的指令，第二種是信號轉(zhuǎn)換板上傳的應答信號。由于信號處理板與信號轉(zhuǎn)換板之間傳輸?shù)膯未螖?shù)據(jù)量較小，所以通過UART來進行通信。
2．1．1網(wǎng)絡通信協(xié)議
針對網(wǎng)絡通信，本系統(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ù)傳輸過程的準確性。由于有些應用場景需要上位機對圖像進行算法分析再將控制信號下發(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ù)的幾個像素點對應的字符很有可能與固定字符相重復，因此若采用以固定字符區(qū)分的方法2，必須對原始圖像數(shù)據(jù)進行遍歷，并對相關(guān)字符進行轉(zhuǎn)義，但這樣計算量過大，會增加系統(tǒng)額外開銷，所以方法2也不合適。本系統(tǒng)采用方法3來設計網(wǎng)絡通信協(xié)議，終的網(wǎng)絡通信協(xié)議格式如圖2所示：

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

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