專利名稱：：安全生產(chǎn)應(yīng)急指揮無(wú)線遠(yuǎn)程監(jiān)控系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
：本實(shí)用新型涉及一種無(wú)線遠(yuǎn)程監(jiān)控系統(tǒng)，特別涉及一種安全生產(chǎn)應(yīng)急指揮無(wú)線遠(yuǎn)程監(jiān)控系統(tǒng)。
背景技術(shù)：
：近年來(lái)，隨著信息化產(chǎn)業(yè)的飛速發(fā)展，無(wú)線網(wǎng)絡(luò)通信系統(tǒng)越來(lái)越多的應(yīng)用于防災(zāi)減災(zāi)，應(yīng)急指揮中，從而完善國(guó)家和地方災(zāi)情監(jiān)測(cè)、預(yù)警、評(píng)估、應(yīng)急救助指揮體系。視頻監(jiān)控在世界上已經(jīng)非常成熟，但是這些僅限于通信線纜可以到達(dá)的地方，對(duì)于人煙稀少的地方以及突發(fā)事故，卻沒(méi)法解決，目前，國(guó)外已經(jīng)有很多關(guān)于這方面的研究工作，但是，這些在我國(guó)都不適用，我國(guó)在此方面研究尚處于起步階段，雖然有不少探討性文章發(fā)表，但都未有太大的成果。無(wú)線網(wǎng)絡(luò)通信中，不可避免地會(huì)發(fā)生帶寬不足，網(wǎng)絡(luò)擁塞、丟包、包亂序、以及延遲等問(wèn)題，直接導(dǎo)致接收端視頻播放的流暢性和清晰性受到損害。
發(fā)明內(nèi)容本實(shí)用新型的目的在于克服上述現(xiàn)有技術(shù)的缺點(diǎn)，提供了一種安全生產(chǎn)應(yīng)急指揮無(wú)線遠(yuǎn)程監(jiān)控系統(tǒng)。為達(dá)到上述目的，本實(shí)用新型采用的技術(shù)方案是包括中心CPU以及與中心CPU的輸入端相連接的視頻采集壓縮模塊和音頻采集壓縮模塊，中心CPU通過(guò)無(wú)線網(wǎng)絡(luò)通信模塊將數(shù)據(jù)傳輸給服務(wù)器，同時(shí)通過(guò)以太網(wǎng)接口向客戶端發(fā)布本實(shí)用新型的中心CPU還連接有接收或輸出報(bào)警信號(hào)的報(bào)警模塊；視頻采集壓縮模i央采用海思3511芯片進(jìn)行視頻硬壓縮及控制；中心CPU上還連接有程序存儲(chǔ)器和數(shù)據(jù)存儲(chǔ)器。本實(shí)用新型通過(guò)視頻采集模塊采集到視頻數(shù)據(jù)，音頻采集模塊采集到音頻數(shù)據(jù)，并作壓縮處理，在中心CPU的組織管理下，這些數(shù)據(jù)通過(guò)無(wú)線網(wǎng)絡(luò)通信模塊發(fā)送到服務(wù)器端進(jìn)行處理并通過(guò)網(wǎng)絡(luò)向客戶端發(fā)布；中心CPU對(duì)其做處理并通過(guò)無(wú)線網(wǎng)絡(luò)通訊模塊發(fā)送到服務(wù)器，從而實(shí)現(xiàn)了安全生產(chǎn)應(yīng)急指揮的無(wú)線遠(yuǎn)程監(jiān)控。圖1是本實(shí)用新型的整體結(jié)構(gòu)示意圖。具體實(shí)施方式以下結(jié)合附圖對(duì)本實(shí)用新型作進(jìn)一步詳細(xì)說(shuō)明。參見圖1，本實(shí)用新型包括中心CPU以及與中心CPU的輸入端相連接的視頻采集壓縮模塊和音頻采集壓縮模塊，中心CPU通過(guò)無(wú)線網(wǎng)絡(luò)通信模塊將數(shù)據(jù)傳輸給服務(wù)器，同時(shí)通過(guò)以太網(wǎng)接口向客戶端發(fā)布，中心CPU還連接有接收或輸出報(bào)警信號(hào)的報(bào)警模塊;視頻采集壓縮模塊采用海思3511芯片進(jìn)行視頻硬壓縮及控制，中心CPU上還連接有程序存儲(chǔ)器和數(shù)據(jù)存儲(chǔ)器。視頻采集模塊采集到視頻數(shù)據(jù)，音頻采集模塊采集到音頻數(shù)據(jù)，并作壓縮處理，在中心CPU的組織管理下，這些數(shù)據(jù)通過(guò)無(wú)線網(wǎng)絡(luò)通信模塊發(fā)送到服務(wù)器端進(jìn)行處理并通過(guò)網(wǎng)絡(luò)向客戶端發(fā)布；報(bào)警模塊接收或者輸出報(bào)警信號(hào)，CPU對(duì)其做處理并通過(guò)無(wú)線網(wǎng)絡(luò)通訊模塊發(fā)送到服務(wù)器。本系統(tǒng)的第一個(gè)特點(diǎn)在研究和比較了主流的視頻壓縮算法如Mpeg4、h.264等的壓縮質(zhì)量及壓縮比例之后，最終系統(tǒng)決定采用h.264視頻壓縮編碼。鑒于目前此類壓縮算法相對(duì)比較成熟以及從縮短開發(fā)周期及成本的角度考慮，最后決定采用海思3511芯片來(lái)進(jìn)行視頻硬壓縮及控制，經(jīng)測(cè)試此芯片能夠在32K帶寬下傳輸6幀圖象，非常適合通過(guò)移動(dòng)通信網(wǎng)絡(luò)來(lái)傳輸本系統(tǒng)的第二個(gè)特點(diǎn)在無(wú)線IP網(wǎng)絡(luò)和盡力服務(wù)(best-effort)的Internet中傳輸數(shù)據(jù)時(shí)會(huì)發(fā)生丟包、超時(shí)等傳輸差錯(cuò)。由于視頻壓縮編碼技術(shù)極大程度地去掉了視頻幀內(nèi)和幀間的冗余性，一個(gè)視頻數(shù)據(jù)包的丟失會(huì)影響其它數(shù)據(jù)包的解壓縮，一個(gè)視頻幀的丟失或損壞同樣會(huì)影響到其它相關(guān)幀的解壓縮，直接損害接收端視頻播放的流暢性和清晰性。因此，需要在視頻傳輸?shù)耐瑫r(shí)進(jìn)行傳輸?shù)牟铄e(cuò)控制處理。目前許多多媒體應(yīng)用通信中使用UDP協(xié)議傳輸數(shù)據(jù)，但UDP協(xié)議不提供TCP提供的差錯(cuò)控制功能。在TCP協(xié)議中，發(fā)送端通過(guò)發(fā)送窗和計(jì)時(shí)器管理所發(fā)送的數(shù)據(jù)包的信息，接收端對(duì)收到的正確數(shù)據(jù)包回送ACK響應(yīng)。發(fā)送端通過(guò)ACK響應(yīng)和計(jì)時(shí)器超時(shí)決定數(shù)據(jù)包重傳。為避免無(wú)效重傳，計(jì)時(shí)器時(shí)限往往設(shè)置較大，不適合傳輸實(shí)時(shí)數(shù)據(jù)，另外，視頻流數(shù)據(jù)量大，ACK響應(yīng)本身也將耗費(fèi)相當(dāng)多的網(wǎng)絡(luò)和處理器資源。基于上述分析，在本系統(tǒng)中，針對(duì)CDMA模式下無(wú)線IP網(wǎng)絡(luò)中視頻流傳輸出現(xiàn)的丟包問(wèn)題使用了一種基于UDP協(xié)議的包丟失處理算法。本系統(tǒng)的數(shù)據(jù)包丟失處理機(jī)制由視頻轉(zhuǎn)發(fā)服務(wù)器實(shí)現(xiàn)緩沖管理、差錯(cuò)檢測(cè)、請(qǐng)求重傳以及重傳信息管理，發(fā)送端負(fù)責(zé)重傳所請(qǐng)求的數(shù)據(jù)包。在CDMA網(wǎng)絡(luò)模式下，采用UDP協(xié)議來(lái)實(shí)現(xiàn)視頻流的實(shí)時(shí)傳輸，容易發(fā)生數(shù)據(jù)的丟包。因此系統(tǒng)采用RTP/UDP/IP方案，利用RTP協(xié)議在UDP數(shù)據(jù)包中添加時(shí)間戳和序列號(hào)控制信息，實(shí)現(xiàn)丟包重傳，提高網(wǎng)絡(luò)傳輸?shù)目煽啃?。設(shè)從發(fā)送端到接收端(中心管理服務(wù)器)網(wǎng)絡(luò)傳輸時(shí)延為Tl，系統(tǒng)RTT為T2。發(fā)送端發(fā)送的視頻碼率為V，數(shù)據(jù)包大小為N，發(fā)送端和接收端緩存大小分別為S和R。本系統(tǒng)的第三個(gè)特點(diǎn)由于單個(gè)CDMA或者GPRS帶寬有限，而無(wú)線監(jiān)控系統(tǒng)的視頻、音頻數(shù)據(jù)傳輸流量的較大，單一數(shù)據(jù)鏈路根本無(wú)法承擔(dān)，必須采用多條數(shù)據(jù)鏈路協(xié)同工作，提高系統(tǒng)的數(shù)據(jù)傳輸能力，以滿足當(dāng)前視頻、音頻傳輸業(yè)務(wù)量的需求。而如何在完成同樣功能的多個(gè)網(wǎng)絡(luò)鏈路之間實(shí)現(xiàn)合理的業(yè)務(wù)量分配，使之不會(huì)出現(xiàn)某一鏈路過(guò)忙、而其他的數(shù)據(jù)通道卻沒(méi)有充分發(fā)揮數(shù)據(jù)傳輸能力的情況。要解決這一問(wèn)題，可以采用負(fù)載均衡的方法。負(fù)載均衡有兩個(gè)方面的含義首先，把大量的數(shù)據(jù)流量分擔(dān)到多個(gè)數(shù)據(jù)鏈路上分別處理，減少用戶等待響應(yīng)的時(shí)間；其次，單個(gè)重負(fù)載的數(shù)據(jù)傳輸分擔(dān)到多個(gè)數(shù)據(jù)鏈路上做并行處理，每個(gè)鏈路數(shù)據(jù)傳輸結(jié)束后，在服務(wù)器端將各個(gè)數(shù)據(jù)鏈路傳輸?shù)臄?shù)據(jù)匯總，并按照一定的算法完成數(shù)據(jù)還原重組，再返回給用戶，使得監(jiān)控系統(tǒng)的數(shù)據(jù)傳輸能力可以得到大幅度提高。其理論來(lái)源于磁盤陣列RAID0，再配合VPN技術(shù)，將多個(gè)無(wú)線通信網(wǎng)絡(luò)與服務(wù)器端組成虛擬局域網(wǎng)，這樣在理論上可以成倍的增加上行帶寬，以達(dá)到視頻數(shù)據(jù)的實(shí)時(shí)傳輸。本實(shí)用新型的工作過(guò)程如下-1、首先由視頻采集壓縮模塊和音頻采集壓縮模塊采集相應(yīng)的視頻和音頻信息，將發(fā)送緩沖中的視頻幀打包發(fā)送，并將當(dāng)前發(fā)送的數(shù)據(jù)包壓入緩存，同時(shí)丟棄緩存中最早的數(shù)據(jù)包。2、視頻數(shù)據(jù)包到中心CPU，中心CPU對(duì)其進(jìn)行有效性檢驗(yàn)，如有效則壓入數(shù)據(jù)存儲(chǔ)器，否則丟棄。部分?jǐn)?shù)據(jù)包在傳輸時(shí)丟失，中心CPU通過(guò)失序差錯(cuò)檢測(cè)，對(duì)丟失的數(shù)據(jù)包發(fā)出NACK重傳請(qǐng)求，并將NACK壓入請(qǐng)求隊(duì)列。3、發(fā)送端即視頻采集壓縮模塊和音頻采集壓縮模塊收到NACK請(qǐng)求后立刻檢査緩存，如果所請(qǐng)求的數(shù)據(jù)包存在則立即重發(fā)，否則丟棄該請(qǐng)求。4、接收端即中心CPU對(duì)重傳數(shù)據(jù)包進(jìn)行同樣的有效性檢驗(yàn)和壓入緩存操作，并刪除相應(yīng)請(qǐng)求。請(qǐng)求隊(duì)列管理對(duì)可能丟失的請(qǐng)求進(jìn)行多次重傳，并刪除失效請(qǐng)求。5、接收端即中心CPU同時(shí)周期地將緩存的數(shù)據(jù)打包通過(guò)無(wú)線網(wǎng)絡(luò)通信模塊將數(shù)據(jù)傳輸給服務(wù)器。當(dāng)接收端即中心CPU等待重傳數(shù)據(jù)包的時(shí)間超過(guò)一定的閥值，放棄等待，直接采用誤碼掩蓋技術(shù)。如何確定這個(gè)閥值成為誤碼控制比較關(guān)鍵的方面，這里采用測(cè)量往返時(shí)間來(lái)確定這個(gè)閥值，往返時(shí)間是RTCP質(zhì)量參數(shù)中重要的一項(xiàng)，它是指發(fā)送端發(fā)送一個(gè)包到接收端，接收端相應(yīng)并返回一個(gè)數(shù)據(jù)包，當(dāng)發(fā)送端接收到反饋包時(shí)所用的時(shí)間，本系統(tǒng)在公網(wǎng)上來(lái)測(cè)量數(shù)據(jù)，向服務(wù)器端發(fā)送一個(gè)600字節(jié)數(shù)據(jù)包，等待服務(wù)器響應(yīng)，表1為測(cè)試結(jié)果-<table>tableseeoriginaldocumentpage7</column></row><table>其中特網(wǎng)絡(luò)條件即AT+CSQ指令返回的信號(hào)強(qiáng)度，30為信號(hào)滿，0為無(wú)信號(hào)，通過(guò)在不同的網(wǎng)絡(luò)條件下的測(cè)試，最后把這個(gè)超時(shí)值定在3s。另外在移動(dòng)網(wǎng)絡(luò)上傳輸數(shù)據(jù)，數(shù)據(jù)包封包大小直接影響了傳輸效率，采用較小的數(shù)據(jù)包傳輸，雖然可以有效的減少丟包，但效率太低，采用大數(shù)據(jù)包傳輸，會(huì)造成大量數(shù)據(jù)包丟失，確定包的大小也成為傳輸中重要的方面，下表為不同封包大小測(cè)試結(jié)果<table>tableseeoriginaldocumentpage7</column></row><table>由測(cè)試結(jié)果綜合丟包率和傳輸速率確定封包大小為600字節(jié)比較合適。具有差錯(cuò)反應(yīng)迅速、狀態(tài)信息和重傳控制信息少、資源需求低的特點(diǎn)，符合實(shí)際應(yīng)用要求。本文通過(guò)請(qǐng)求隊(duì)列實(shí)現(xiàn)多次有效重傳，進(jìn)一步提高了包丟失恢復(fù)率。能夠有效降低視頻數(shù)據(jù)包在無(wú)線網(wǎng)絡(luò)環(huán)境中的包丟失率。權(quán)利要求1、一種安全生產(chǎn)應(yīng)急指揮無(wú)線遠(yuǎn)程監(jiān)控系統(tǒng)，其特征在于包括中心CPU以及與中心CPU的輸入端相連接的視頻采集壓縮模塊和音頻采集壓縮模塊，中心CPU通過(guò)無(wú)線網(wǎng)絡(luò)通信模塊將數(shù)據(jù)傳輸給服務(wù)器，同時(shí)通過(guò)以太網(wǎng)接口向客戶端發(fā)布。2、根據(jù)權(quán)利要求1所述的安全生產(chǎn)應(yīng)急指揮無(wú)線遠(yuǎn)程監(jiān)控系統(tǒng)，其特征在于所說(shuō)的中心CPU還連接有接收或輸出報(bào)警信號(hào)的報(bào)警模塊。3、根據(jù)權(quán)利要求1所述的安全生產(chǎn)應(yīng)急指揮無(wú)線遠(yuǎn)程監(jiān)控系統(tǒng)，其特征在于所說(shuō)的視頻采集壓縮模i央采用海思3511芯片進(jìn)行視頻硬壓縮及控制。4、根據(jù)權(quán)利要求1所述的安全生產(chǎn)應(yīng)急指揮無(wú)線遠(yuǎn)程監(jiān)控系統(tǒng)，其特征在于所說(shuō)的中心CPU上還連接有程序存儲(chǔ)器和數(shù)據(jù)存儲(chǔ)器。專利摘要一種安全生產(chǎn)應(yīng)急指揮無(wú)線遠(yuǎn)程監(jiān)控系統(tǒng)，包括中心CPU以及與中心CPU的輸入端相連接的視頻采集壓縮模塊和音頻采集壓縮模塊，中心CPU通過(guò)無(wú)線網(wǎng)絡(luò)通信模塊將數(shù)據(jù)傳輸給服務(wù)器，同時(shí)通過(guò)以太網(wǎng)接口向客戶端發(fā)布。本實(shí)用新型通過(guò)視頻采集模塊采集到視頻數(shù)據(jù)，音頻采集模塊采集到音頻數(shù)據(jù)，并作壓縮處理，在中心CPU的組織管理下，這些數(shù)據(jù)通過(guò)無(wú)線網(wǎng)絡(luò)通信模塊發(fā)送到服務(wù)器端進(jìn)行處理并通過(guò)網(wǎng)絡(luò)向客戶端發(fā)布；中心CPU對(duì)其做處理并通過(guò)無(wú)線網(wǎng)絡(luò)通訊模塊發(fā)送到服務(wù)器，從而實(shí)現(xiàn)了安全生產(chǎn)應(yīng)急指揮的無(wú)線遠(yuǎn)程監(jiān)控。文檔編號(hào)H04N7/18GK201312363SQ200820228389公開日2009年9月16日申請(qǐng)日期2008年12月22日優(yōu)先權(quán)日2008年12月22日發(fā)明者于義亮,洋李,白延清,靖許,賈玉堂申請(qǐng)人:延安供電局;陜西銀河景天電子有限責(zé)任公司