摘要：各地電梯事故頻發(fā),，電梯五方對講系統是乘客被困后用于緊急求援的重要手段,。針對電梯實時通話系統的需求和穩(wěn)定性問題，設計了一種基于物聯網的智能電梯監(jiān)控分布式系統的實現方案，在此基礎上詳細介紹了基于lwIP的實時網絡通話的軟件實現,，并使用Speex語音壓縮技術減少網絡帶寬占用,，優(yōu)化了通話實時性，保證了電梯監(jiān)控中心服務器在多部電梯通話請求并發(fā)情況下的穩(wěn)定性,。
關鍵詞：電梯監(jiān)控,；實時通話；網絡協議,；語音壓縮
0引言
電梯行業(yè)日益發(fā)展,，不同小區(qū)的電梯在地域上分布廣，數量多,，導致傳統人工維修和處理故障的方法效率低下,，電梯的維修保養(yǎng)成本高昂。
現有的電梯智能監(jiān)控系統［12］中,， 往往使用SIM卡作為監(jiān)控數據傳輸或通話的載體,，但是其通話及網絡均依賴井道里的信號強度。每個小區(qū)電梯需要SIM卡的數量比較多的情況下,，隨著時間增加,，產生了電梯維護成本高的問題。為此,，本文開發(fā)了一種基于互聯網的分布式電梯智能監(jiān)控系統,，實現了電梯狀態(tài)監(jiān)控和緊急情況下五方實時網絡通話的功能，具有很強的應用價值和前景,。
1分布式智能電梯監(jiān)控系統
許多小區(qū)電梯維修或者緊急救援效率低,，往往會影響到人們正常生活和生命安全。隨著智慧城市建設的展開,，基于物聯網設計一種新型的大規(guī)模分布式電梯智能監(jiān)控系統是必然的趨勢,。
整個分布式智能電梯監(jiān)控系統由底層監(jiān)控系統,、小區(qū)網絡部分,、電梯監(jiān)控服務中心三部分組成，如圖1所示,。底層監(jiān)控系統主控芯片選用意法半導體公司生產的STM32F407,，安裝在電梯轎廂頂部監(jiān)控電梯運行狀態(tài)，且獨立于電梯運行控制系統,，通過網絡連接到單元交換機,。小區(qū)網絡節(jié)點依托于小區(qū)電梯數量鋪設，每個節(jié)點按照設置規(guī)則管理每部電梯網絡數據的收發(fā),。電梯監(jiān)控服務中心的主要功能是與各個小區(qū)網關節(jié)點網絡通信,，接收各小區(qū)電梯運行狀態(tài)數據并建立數據庫,。在緊急情況發(fā)生時，電梯監(jiān)控服務中心需要通過網絡與轎廂內人員實時通話,。
在每部電梯頂部安裝的底層監(jiān)控系統采集電梯運行狀態(tài)和參數,，并將其通過交換機經小區(qū)光纖上傳到電梯監(jiān)控中心，如果出現電梯運行異常,，電梯監(jiān)控中心能夠及時收到報警信息［3］,。監(jiān)控中心將電梯出錯信息通過網絡或者短信推送到小區(qū)附近的維修人員［4］，從而提高了電梯維修效率,，降低了維修成本,。維修人員通過監(jiān)控系統提供的電梯運行狀態(tài)錯誤代碼能準確判斷出運行故障，從而節(jié)約維修時間,。
2通話系統技術實現
當電梯轎廂里緊急按鈕按下時,，五方對講系統啟動，電梯轎廂與電梯監(jiān)控中心可實時進行語音通話,，底層監(jiān)控系統通過網絡發(fā)送與接收通話時的語音數據流,。
在本電路系統中，采用LAN8720芯片作為物理層,，傳輸協議采用輕量級開源協議棧lwIP［5］,，移植語音壓縮Speex算法對音頻流進行編解碼，從而實現了低帶寬占用的語音數據流的雙向實時傳輸,。
通話系統核心程序采用C語言編寫,，為保證商業(yè)化使用方便及穩(wěn)定性，單片機STM32內部并未移植類似于RTThread的操作系統,，采用基本定時器的中斷方式解決狀態(tài)跳轉等問題,，系統成本低，穩(wěn)定性高,。
2.1數據流控制
單片機STM32的直接存儲訪問(Direct Memory Access，DMA) 控制器基于總線矩陣與獨立先入先出隊列（First Input First Output, FIFO）的結合,，比普通CPU內存拷貝操作更加快速［6］,。在通話系統中，音頻芯片WM8978音頻采樣的數據與STM32內部數組的雙向傳遞通過DMA技術能大大減小CPU占用率,，并解決了在全雙工對話時語音數據同步收發(fā)的問題,。
在移植的lwIP協議中，接收和發(fā)送以太網數據時STM32和內存之間的數據交換使用DMA技術能夠減小每包間相對延遲,，保證對話流暢度,。
2.1.1音頻接收與發(fā)送
在通話系統程序中DMA技術用于音頻采樣的數據流與STM32內部數組緩存空間的數據雙向傳遞，可以減少數據傳輸的延遲,。
如圖2所示,音頻芯片WM8978與STM32交換數據的流程中, DMA總線每次將編碼與解碼需要的數組填充好后自動切換數組進行下一次填充,，不涉及CPU操作,，節(jié)省數據拷貝時間。每次填充時根據標志位判定哪個數組為空,，每幀填充耗時為20 ms,，填充后更改標志位并觸發(fā)中斷通知CPU對數組里數據進行編解碼操作。
2.1.2網絡接收與發(fā)送
每幀語音數據經過Speex壓縮算法編碼后,，由lwIP協議循環(huán)發(fā)送到電梯安全監(jiān)控中心,。安全監(jiān)控中心將每幀語音數據發(fā)送到STM32，STM32接收數據后進行Speex解碼,，再將數據發(fā)送至音頻芯片播放,。
如圖3所示，通過lwIP協議接收時,，每幀數據（20 B）到達單片機時會觸發(fā)中斷,，接收標志位翻轉。單片機STM32檢測到接收標志位后會進行Speex解碼處理,，并將標志位清零,。每幀數據解碼后的緩存數據大小為320 B，存儲于數組中并通過I2S接口發(fā)送到左右聲道播放,，同時音頻芯片I2S接口錄音數據流也通過DMA技術傳輸到STM32芯片,。編碼時，通過檢測音頻數據接收標志位判斷DMA已填充數組（recbuf1［］或recbuf2［］）,，從而對錄音數組進行編碼,，更新發(fā)送標志位，通知lwIP協議發(fā)送,?！ ?/p>
在STM32中以太網接收和發(fā)送FIFO緩存數據，通過硬件DMA復制到內存中,，不需要經過內存拷貝memcpy函數,。在無操作系統的程序框架中，該操作保證數據交換時不占用CPU,，相比普通操作系統中雙線程交換數據穩(wěn)定性更高,。
2.2系統優(yōu)化
實時通話時，音頻數據需要與電梯監(jiān)控中心協同收發(fā),，要盡量減少通話過程中因延時造成的溝通問題,。
2.2.1網絡協議lwIP優(yōu)化
lwIP協議棧中使用pbuf結構體來描述以太網中緩存數據包，通過鏈表指針管理數據地址,。
制約UDP協議性能的瓶頸之一是內存數據的拷貝,，接收1 KB數據包時，內存拷貝在底層驅動讀入FIFO中的數據后會拷貝到lwIP協議棧中的pbuf緩存中,，而在用戶需要數據包時,，協議棧中對應的拷貝庫函數會將pbuf中數據拷貝到用戶開辟的內存數組中,。整個數據流程約占用總接收時間的一半［7］，導致數據包延遲和處理器低效,。
單片機頻繁接收數據會太過占用內存,，同時因解碼時間相對長，會存在緩沖棧溢出的問題,。普通中斷方式接收對話數據時,，會導致CPU頻繁進入中斷降低效率，造成對話較大延遲甚至丟包的現象,。
在本系統中修改lwIP源代碼［8］,，對lwIP協議內存占用率進行了很大改進，協議棧中內存拷貝不通過CPU,，而是采用STM32 的DMA控制器接收和發(fā)送數據,。
如圖4所示，STM32以太網DMA控制器描述符采用鏈式結構,，每個描述符都有相應指針存儲緩沖區(qū)地址,，當以太網數據包比較大的時候會跨越多個描述符存儲。描述符列表的最后一個描述符會指向第一個,，形成鏈式結構［9］,。
發(fā)送或接收時,，每個描述符緩沖區(qū)存儲設置為1 KB大小,，STM32芯片中硬件DMA控制器直接參與以太網數據交換。CPU不用參與數據拷貝,，相比于普通方式效率提高一倍,，并且大幅減小了CPU與中斷線負擔。 如表1所示,，若單片機工作頻率為100 MHz,，那么CPU拷貝每幀數據需要花費的時間約為3.3 μs。通過DMA總線操作能將這部分時間省略掉,，提高效率,，也能將CPU空閑出來用于表1優(yōu)化前后運行時間比較拷貝時間/μs優(yōu)化前3.30優(yōu)化后0處理其他函數。
2.2.2語音壓縮與帶寬優(yōu)化
在大型分布式電梯管理系統中,，并發(fā)情況下多部電梯請求五方對講通話時對電梯控制中心服務器的帶寬壓力非常大，會導致對話延時,、服務器死機等諸多問題,，因此需要減少單部電梯占用的帶寬。
語音芯片采樣率為8 kHz,，采樣位數為16位,，每秒通過DMA控制器的錄音或放音數據大小為31.25 KB,。在系統沒有移植Speex語音壓縮算法前，每秒由單片機傳輸到監(jiān)控中心的錄放音數據大小都為31.25 KB,，那么每部電梯所占上下行帶寬比較大,，均為512 Kb/s。因此在多小區(qū)分布式電梯智能管理系統中,，需要解決音頻流數據流太大的問題,。
Speex壓縮算法是一種基于碼激勵線性預測編碼(Code Excited Linear Prediction，CELP)技術的語音壓縮算法［910］,，在網絡通話中有著極強的應用性［11］,。
線性預測編碼（Linear Predictive Coding, LPC）使用過去樣值對新樣值進行預測,，計算出最小誤差信號,。設樣值序列為x1,x2…,xN,，預測序列為y1,y2…,yN，則：
進行線性預測分析得到一組線性預測系數a1,a2…,aN,，使得在該幀語音波形中均方預測誤差E最小。
式中L為線性預測器階數,。由于誤差信號動態(tài)范圍比樣本值小，對誤差信號進行量化編碼可以有效降低編碼比特位數,。
如圖5所示，Speex算法解碼過程中,，激勵信號e［n］是由基音尖峰預測信號與固定碼書激勵信號c［n］加權得到的,。
e［n］=βe［n-T］+c［n］(3)
式中T為尖峰周期,，β為尖峰增益。e［n］通過感知加權合成濾波器,，使得在該幀語音波形中均方預測誤差最小，從而合成出語音數據,。
在窄帶模式（采樣率8 kHz）下,每幀數據信號長度為20 ms,，將其分為4個長度為5 ms的子幀,。對每個子幀確定基音預測系數，并用固定碼本中某一激勵矢量經過加權合成濾波器并求解最小均方誤差方程,，從而選取到最佳激勵矢量計算誤差信號并進行量化編碼,。解碼時借助于合成濾波器，將最佳激勵信號通過濾波器產生近似合成語音,。
如圖6所示，實時網絡通話時,，每部電梯與音頻芯片交換的音頻數據流速率為62.50 KB/s,，單部電梯通話時所占網絡實際帶寬為512 Kb/s,。經單片機STM32移植的Speex算法處理后,，與電梯控制中心交換的上下行數據流約為1.95 KB，所占網絡實際帶寬減少為15.625 Kb/s,。
本系統中通過單片機移植Speex算法實現音頻流壓縮編解碼，使得每秒語音上下行占用帶寬大大減小,，降低了智能電梯管理系統對服務器性能的要求，使得電梯智能監(jiān)控中心能夠同時管理幾千余部電梯,。
3結論
本文提出了基于物聯網的分布式智能電梯監(jiān)控系統設計方案和電梯五方實時通話的技術實現流程。該系統為保證硬件工作的穩(wěn)定性,，不移植操作系統,，而是修改移植網絡協議lwIP實現系統網絡連接，并通過STM32芯片DMA功能同步控制音頻流，實現了全雙工實時網絡通話,，優(yōu)化了通話延時,。在大型分布式電梯管理系統中,，底層硬件通過移植Speex語音壓縮編解碼算法將網絡帶寬占用減少至原來的1/32，極大減少了單部電梯的帶寬占用,，滿足了智能工業(yè)應用的生產需求和大規(guī)模使用要求,。
參考文獻
［1］ 吳衛(wèi), 鄭建立, 孫佳新. 基于 RFID 電梯遠程監(jiān)測系統的設計與實現［J］. 微型機與應用,，2011，30(3）: 9294.
?。?］ 閆學勤, 謝麗蓉，程志江,，等. ZigBee+ 3G 網絡在新型井道式電梯監(jiān)控系統中的應用［J］. 自動化儀表，2015,，36（1）:14.
?。?］ 李保禮. 電梯實時監(jiān)控與故障報警系統設計研究［J］. 中國機械,，2014(15):10.
?。?］ 祝尊震, 蘇宇,，張玉亮,，等. 基于物聯網技術的電梯安全管理系統［J］. 微型機與應用,，2015,，34(1):7274.
?。?］ DUNKELS A. Design and implementation of the lwIP TCP/IP stack［J］. Swedish Institute of Computer Science， 2001（27): 7792.
?。?］ ST Microelectronics. STM32F405xx and STM32F407xx advanced ARMbased 32bit MCUs reference manual［DB/OL］.（2015xxxx）［20160228］http://www.st.com/stweb-ui/static/active/cn/resource/technical/document/reference_manual/DM00031020.pdf.
?。?］ 徐鑫,曹奇英. 基于 LwIP 協議棧的 UDP 協議分析與優(yōu)化［J］. 計算機應用與軟件, 2011, 28(3): 246249.
?。?］ DUNKELS A. LwIP source code［EB/OL］.（2008323）［20160229］ http://download.savannah.nongnu.org/release/lwip/lwip1.3.0.zip.
?。?］ 施純啟,吳景東.LwIP在LPC23/24XX以太網MAC控制器上的移植與應用［J］.微型機與應用,2014,33(19):6770,75.
［10］ VALIN J M. The Speex codec manual version 1.2 Beta 3［Z］.Xiph.org Foundation,2007.
?。?1］ 謝曉鋼,，蔡駿，陳奇川,，等.基于Speex語音引擎的VoIP系統設計與實現［J］.計算機應用研究,，2007，24（12）：320323.