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

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

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

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

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