摘要：各地電梯事故頻發(fā)，電梯五方對講系統(tǒng)是乘客被困后用于緊急求援的重要手段。針對電梯實時通話系統(tǒng)的需求和穩(wěn)定性問題，設(shè)計了一種基于物聯(lián)網(wǎng)的智能電梯監(jiān)控分布式系統(tǒng)的實現(xiàn)方案，在此基礎(chǔ)上詳細介紹了基于lwIP的實時網(wǎng)絡(luò)通話的軟件實現(xiàn)，并使用Speex語音壓縮技術(shù)減少網(wǎng)絡(luò)帶寬占用，優(yōu)化了通話實時性，保證了電梯監(jiān)控中心服務(wù)器在多部電梯通話請求并發(fā)情況下的穩(wěn)定性。

　　關(guān)鍵詞：電梯監(jiān)控；實時通話；網(wǎng)絡(luò)協(xié)議；語音壓縮

0引言

　　電梯行業(yè)日益發(fā)展，不同小區(qū)的電梯在地域上分布廣，數(shù)量多，導(dǎo)致傳統(tǒng)人工維修和處理故障的方法效率低下，電梯的維修保養(yǎng)成本高昂。

　　現(xiàn)有的電梯智能監(jiān)控系統(tǒng)［12］中， 往往使用SIM卡作為監(jiān)控數(shù)據(jù)傳輸或通話的載體，但是其通話及網(wǎng)絡(luò)均依賴井道里的信號強度。每個小區(qū)電梯需要SIM卡的數(shù)量比較多的情況下，隨著時間增加，產(chǎn)生了電梯維護成本高的問題。為此，本文開發(fā)了一種基于互聯(lián)網(wǎng)的分布式電梯智能監(jiān)控系統(tǒng)，實現(xiàn)了電梯狀態(tài)監(jiān)控和緊急情況下五方實時網(wǎng)絡(luò)通話的功能，具有很強的應(yīng)用價值和前景。

1分布式智能電梯監(jiān)控系統(tǒng)

　　許多小區(qū)電梯維修或者緊急救援效率低，往往會影響到人們正常生活和生命安全。隨著智慧城市建設(shè)的展開，基于物聯(lián)網(wǎng)設(shè)計一種新型的大規(guī)模分布式電梯智能監(jiān)控系統(tǒng)是必然的趨勢?！?/p>

　　整個分布式智能電梯監(jiān)控系統(tǒng)由底層監(jiān)控系統(tǒng)、小區(qū)網(wǎng)絡(luò)部分、電梯監(jiān)控服務(wù)中心三部分組成，如圖1所示。底層監(jiān)控系統(tǒng)主控芯片選用意法半導(dǎo)體公司生產(chǎn)的STM32F407，安裝在電梯轎廂頂部監(jiān)控電梯運行狀態(tài)，且獨立于電梯運行控制系統(tǒng)，通過網(wǎng)絡(luò)連接到單元交換機。小區(qū)網(wǎng)絡(luò)節(jié)點依托于小區(qū)電梯數(shù)量鋪設(shè)，每個節(jié)點按照設(shè)置規(guī)則管理每部電梯網(wǎng)絡(luò)數(shù)據(jù)的收發(fā)。電梯監(jiān)控服務(wù)中心的主要功能是與各個小區(qū)網(wǎng)關(guān)節(jié)點網(wǎng)絡(luò)通信，接收各小區(qū)電梯運行狀態(tài)數(shù)據(jù)并建立數(shù)據(jù)庫。在緊急情況發(fā)生時，電梯監(jiān)控服務(wù)中心需要通過網(wǎng)絡(luò)與轎廂內(nèi)人員實時通話。

　　在每部電梯頂部安裝的底層監(jiān)控系統(tǒng)采集電梯運行狀態(tài)和參數(shù)，并將其通過交換機經(jīng)小區(qū)光纖上傳到電梯監(jiān)控中心，如果出現(xiàn)電梯運行異常，電梯監(jiān)控中心能夠及時收到報警信息［3］。監(jiān)控中心將電梯出錯信息通過網(wǎng)絡(luò)或者短信推送到小區(qū)附近的維修人員［4］，從而提高了電梯維修效率，降低了維修成本。維修人員通過監(jiān)控系統(tǒng)提供的電梯運行狀態(tài)錯誤代碼能準(zhǔn)確判斷出運行故障，從而節(jié)約維修時間。

2通話系統(tǒng)技術(shù)實現(xiàn)

　　當(dāng)電梯轎廂里緊急按鈕按下時，五方對講系統(tǒng)啟動，電梯轎廂與電梯監(jiān)控中心可實時進行語音通話，底層監(jiān)控系統(tǒng)通過網(wǎng)絡(luò)發(fā)送與接收通話時的語音數(shù)據(jù)流。

　　在本電路系統(tǒng)中，采用LAN8720芯片作為物理層，傳輸協(xié)議采用輕量級開源協(xié)議棧lwIP［5］，移植語音壓縮Speex算法對音頻流進行編解碼，從而實現(xiàn)了低帶寬占用的語音數(shù)據(jù)流的雙向?qū)崟r傳輸。

　　通話系統(tǒng)核心程序采用C語言編寫，為保證商業(yè)化使用方便及穩(wěn)定性，單片機STM32內(nèi)部并未移植類似于RTThread的操作系統(tǒng)，采用基本定時器的中斷方式解決狀態(tài)跳轉(zhuǎn)等問題，系統(tǒng)成本低，穩(wěn)定性高。

　　2.1數(shù)據(jù)流控制

　　單片機STM32的直接存儲訪問(Direct Memory Access，DMA) 控制器基于總線矩陣與獨立先入先出隊列（First Input First Output, FIFO）的結(jié)合，比普通CPU內(nèi)存拷貝操作更加快速［6］。在通話系統(tǒng)中，音頻芯片WM8978音頻采樣的數(shù)據(jù)與STM32內(nèi)部數(shù)組的雙向傳遞通過DMA技術(shù)能大大減小CPU占用率，并解決了在全雙工對話時語音數(shù)據(jù)同步收發(fā)的問題。

　　在移植的lwIP協(xié)議中，接收和發(fā)送以太網(wǎng)數(shù)據(jù)時STM32和內(nèi)存之間的數(shù)據(jù)交換使用DMA技術(shù)能夠減小每包間相對延遲，保證對話流暢度。

　　2.1.1音頻接收與發(fā)送

　　在通話系統(tǒng)程序中DMA技術(shù)用于音頻采樣的數(shù)據(jù)流與STM32內(nèi)部數(shù)組緩存空間的數(shù)據(jù)雙向傳遞，可以減少數(shù)據(jù)傳輸?shù)难舆t。

　　如圖2所示,音頻芯片WM8978與STM32交換數(shù)據(jù)的流程中, DMA總線每次將編碼與解碼需要的數(shù)組填充好后自動切換數(shù)組進行下一次填充，不涉及CPU操作，節(jié)省數(shù)據(jù)拷貝時間。每次填充時根據(jù)標(biāo)志位判定哪個數(shù)組為空，每幀填充耗時為20 ms，填充后更改標(biāo)志位并觸發(fā)中斷通知CPU對數(shù)組里數(shù)據(jù)進行編解碼操作。

　　2.1.2網(wǎng)絡(luò)接收與發(fā)送

　　每幀語音數(shù)據(jù)經(jīng)過Speex壓縮算法編碼后，由lwIP協(xié)議循環(huán)發(fā)送到電梯安全監(jiān)控中心。安全監(jiān)控中心將每幀語音數(shù)據(jù)發(fā)送到STM32，STM32接收數(shù)據(jù)后進行Speex解碼，再將數(shù)據(jù)發(fā)送至音頻芯片播放。

　　如圖3所示，通過lwIP協(xié)議接收時，每幀數(shù)據(jù)（20 B）到達單片機時會觸發(fā)中斷，接收標(biāo)志位翻轉(zhuǎn)。單片機STM32檢測到接收標(biāo)志位后會進行Speex解碼處理，并將標(biāo)志位清零。每幀數(shù)據(jù)解碼后的緩存數(shù)據(jù)大小為320 B，存儲于數(shù)組中并通過I2S接口發(fā)送到左右聲道播放，同時音頻芯片I2S接口錄音數(shù)據(jù)流也通過DMA技術(shù)傳輸?shù)絊TM32芯片。編碼時，通過檢測音頻數(shù)據(jù)接收標(biāo)志位判斷DMA已填充數(shù)組（recbuf1［］或recbuf2［］），從而對錄音數(shù)組進行編碼，更新發(fā)送標(biāo)志位，通知lwIP協(xié)議發(fā)送。　　

　　在STM32中以太網(wǎng)接收和發(fā)送FIFO緩存數(shù)據(jù)，通過硬件DMA復(fù)制到內(nèi)存中，不需要經(jīng)過內(nèi)存拷貝memcpy函數(shù)。在無操作系統(tǒng)的程序框架中，該操作保證數(shù)據(jù)交換時不占用CPU，相比普通操作系統(tǒng)中雙線程交換數(shù)據(jù)穩(wěn)定性更高。

　　2.2系統(tǒng)優(yōu)化

　　實時通話時，音頻數(shù)據(jù)需要與電梯監(jiān)控中心協(xié)同收發(fā)，要盡量減少通話過程中因延時造成的溝通問題。

　　2.2.1網(wǎng)絡(luò)協(xié)議lwIP優(yōu)化

　　lwIP協(xié)議棧中使用pbuf結(jié)構(gòu)體來描述以太網(wǎng)中緩存數(shù)據(jù)包，通過鏈表指針管理數(shù)據(jù)地址。

　　制約UDP協(xié)議性能的瓶頸之一是內(nèi)存數(shù)據(jù)的拷貝，接收1 KB數(shù)據(jù)包時，內(nèi)存拷貝在底層驅(qū)動讀入FIFO中的數(shù)據(jù)后會拷貝到lwIP協(xié)議棧中的pbuf緩存中，而在用戶需要數(shù)據(jù)包時，協(xié)議棧中對應(yīng)的拷貝庫函數(shù)會將pbuf中數(shù)據(jù)拷貝到用戶開辟的內(nèi)存數(shù)組中。整個數(shù)據(jù)流程約占用總接收時間的一半［7］，導(dǎo)致數(shù)據(jù)包延遲和處理器低效。

　　單片機頻繁接收數(shù)據(jù)會太過占用內(nèi)存，同時因解碼時間相對長，會存在緩沖棧溢出的問題。普通中斷方式接收對話數(shù)據(jù)時，會導(dǎo)致CPU頻繁進入中斷降低效率，造成對話較大延遲甚至丟包的現(xiàn)象。

　　在本系統(tǒng)中修改lwIP源代碼［8］，對lwIP協(xié)議內(nèi)存占用率進行了很大改進，協(xié)議棧中內(nèi)存拷貝不通過CPU，而是采用STM32 的DMA控制器接收和發(fā)送數(shù)據(jù)。

　　如圖4所示，STM32以太網(wǎng)DMA控制器描述符采用鏈?zhǔn)浇Y(jié)構(gòu)，每個描述符都有相應(yīng)指針存儲緩沖區(qū)地址，當(dāng)以太網(wǎng)數(shù)據(jù)包比較大的時候會跨越多個描述符存儲。描述符列表的最后一個描述符會指向第一個，形成鏈?zhǔn)浇Y(jié)構(gòu)［9］?！　?/p>

　　發(fā)送或接收時，每個描述符緩沖區(qū)存儲設(shè)置為1 KB大小，STM32芯片中硬件DMA控制器直接參與以太網(wǎng)數(shù)據(jù)交換。CPU不用參與數(shù)據(jù)拷貝，相比于普通方式效率提高一倍，并且大幅減小了CPU與中斷線負擔(dān)。 如表1所示，若單片機工作頻率為100 MHz，那么CPU拷貝每幀數(shù)據(jù)需要花費的時間約為3.3 μs。通過DMA總線操作能將這部分時間省略掉，提高效率，也能將CPU空閑出來用于表1優(yōu)化前后運行時間比較拷貝時間/μs優(yōu)化前3.30優(yōu)化后0處理其他函數(shù)。

　　2.2.2語音壓縮與帶寬優(yōu)化

　　在大型分布式電梯管理系統(tǒng)中，并發(fā)情況下多部電梯請求五方對講通話時對電梯控制中心服務(wù)器的帶寬壓力非常大，會導(dǎo)致對話延時、服務(wù)器死機等諸多問題，因此需要減少單部電梯占用的帶寬。

　　語音芯片采樣率為8 kHz，采樣位數(shù)為16位，每秒通過DMA控制器的錄音或放音數(shù)據(jù)大小為31.25 KB。在系統(tǒng)沒有移植Speex語音壓縮算法前，每秒由單片機傳輸?shù)奖O(jiān)控中心的錄放音數(shù)據(jù)大小都為31.25 KB，那么每部電梯所占上下行帶寬比較大，均為512 Kb/s。因此在多小區(qū)分布式電梯智能管理系統(tǒng)中，需要解決音頻流數(shù)據(jù)流太大的問題。

　　Speex壓縮算法是一種基于碼激勵線性預(yù)測編碼(Code Excited Linear Prediction，CELP)技術(shù)的語音壓縮算法［910］，在網(wǎng)絡(luò)通話中有著極強的應(yīng)用性［11］。

　　線性預(yù)測編碼（Linear Predictive Coding, LPC）使用過去樣值對新樣值進行預(yù)測，計算出最小誤差信號。設(shè)樣值序列為x1,x2…,xN，預(yù)測序列為y1,y2…,yN，則：

　　進行線性預(yù)測分析得到一組線性預(yù)測系數(shù)a1,a2…,aN，使得在該幀語音波形中均方預(yù)測誤差E最小。

　　式中L為線性預(yù)測器階數(shù)。由于誤差信號動態(tài)范圍比樣本值小，對誤差信號進行量化編碼可以有效降低編碼比特位數(shù)。

　　如圖5所示，Speex算法解碼過程中，激勵信號e［n］是由基音尖峰預(yù)測信號與固定碼書激勵信號c［n］加權(quán)得到的。

　　e［n］=βe［n-T］+c［n］(3)

　　式中T為尖峰周期，β為尖峰增益。e［n］通過感知加權(quán)合成濾波器，使得在該幀語音波形中均方預(yù)測誤差最小，從而合成出語音數(shù)據(jù)?！　?/p>

　　在窄帶模式（采樣率8 kHz）下,每幀數(shù)據(jù)信號長度為20 ms，將其分為4個長度為5 ms的子幀。對每個子幀確定基音預(yù)測系數(shù)，并用固定碼本中某一激勵矢量經(jīng)過加權(quán)合成濾波器并求解最小均方誤差方程，從而選取到最佳激勵矢量計算誤差信號并進行量化編碼。解碼時借助于合成濾波器，將最佳激勵信號通過濾波器產(chǎn)生近似合成語音。

　　如圖6所示，實時網(wǎng)絡(luò)通話時，每部電梯與音頻芯片交換的音頻數(shù)據(jù)流速率為62.50 KB/s，單部電梯通話時所占網(wǎng)絡(luò)實際帶寬為512 Kb/s。經(jīng)單片機STM32移植的Speex算法處理后，與電梯控制中心交換的上下行數(shù)據(jù)流約為1.95 KB，所占網(wǎng)絡(luò)實際帶寬減少為15.625 Kb/s。

　　本系統(tǒng)中通過單片機移植Speex算法實現(xiàn)音頻流壓縮編解碼，使得每秒語音上下行占用帶寬大大減小，降低了智能電梯管理系統(tǒng)對服務(wù)器性能的要求，使得電梯智能監(jiān)控中心能夠同時管理幾千余部電梯。

3結(jié)論

　　本文提出了基于物聯(lián)網(wǎng)的分布式智能電梯監(jiān)控系統(tǒng)設(shè)計方案和電梯五方實時通話的技術(shù)實現(xiàn)流程。該系統(tǒng)為保證硬件工作的穩(wěn)定性，不移植操作系統(tǒng)，而是修改移植網(wǎng)絡(luò)協(xié)議lwIP實現(xiàn)系統(tǒng)網(wǎng)絡(luò)連接，并通過STM32芯片DMA功能同步控制音頻流，實現(xiàn)了全雙工實時網(wǎng)絡(luò)通話，優(yōu)化了通話延時。在大型分布式電梯管理系統(tǒng)中，底層硬件通過移植Speex語音壓縮編解碼算法將網(wǎng)絡(luò)帶寬占用減少至原來的1/32，極大減少了單部電梯的帶寬占用，滿足了智能工業(yè)應(yīng)用的生產(chǎn)需求和大規(guī)模使用要求。

參考文獻

　?。?］ 吳衛(wèi), 鄭建立, 孫佳新. 基于 RFID 電梯遠程監(jiān)測系統(tǒng)的設(shè)計與實現(xiàn)［J］. 微型機與應(yīng)用，2011，30(3）: 9294.

　　［2］ 閆學(xué)勤, 謝麗蓉，程志江，等. ZigBee+ 3G 網(wǎng)絡(luò)在新型井道式電梯監(jiān)控系統(tǒng)中的應(yīng)用［J］. 自動化儀表，2015，36（1）:14.

　?。?］ 李保禮. 電梯實時監(jiān)控與故障報警系統(tǒng)設(shè)計研究［J］. 中國機械，2014(15):10.

　?。?］ 祝尊震, 蘇宇，張玉亮，等. 基于物聯(lián)網(wǎng)技術(shù)的電梯安全管理系統(tǒng)［J］. 微型機與應(yīng)用，2015，34(1):7274.

　?。?］ DUNKELS A. Design and implementation of the lwIP TCP/IP stack［J］. Swedish Institute of Computer Science， 2001（27): 7792.

　　［6］ ST Microelectronics. STM32F405xx and STM32F407xx advanced ARMbased 32bit MCUs reference manual［DB/OL］.（2015xxxx）［20160228］http://www.st.com/stweb-ui/static/active/cn/resource/technical/document/reference_manual/DM00031020.pdf.

　?。?］ 徐鑫,曹奇英. 基于 LwIP 協(xié)議棧的 UDP 協(xié)議分析與優(yōu)化［J］. 計算機應(yīng)用與軟件, 2011, 28(3): 246249.

　?。?］ DUNKELS A. LwIP source code［EB/OL］.（2008323）［20160229］ http://download.savannah.nongnu.org/release/lwip/lwip1.3.0.zip.

　　［9］ 施純啟,吳景東.LwIP在LPC23/24XX以太網(wǎng)MAC控制器上的移植與應(yīng)用［J］.微型機與應(yīng)用,2014,33(19):6770,75.

　?。?0］ VALIN J M. The Speex codec manual version 1.2 Beta 3［Z］.Xiph.org Foundation,2007.

　?。?1］ 謝曉鋼，蔡駿，陳奇川，等.基于Speex語音引擎的VoIP系統(tǒng)設(shè)計與實現(xiàn)［J］.計算機應(yīng)用研究，2007，24（12）：320323.