基于lwIP的電梯實時通話系統(tǒng)實現(xiàn)

郭曉天，宋克柱, 高林林

(1.中國科學(xué)技術(shù)大學(xué) 物理學(xué)院，安徽 合肥 230026；2.核探測技術(shù)與核電子學(xué)國家重點實驗室，安徽 合肥 230026)

?

基于lwIP的電梯實時通話系統(tǒng)實現(xiàn)

郭曉天1,2，宋克柱1,2, 高林林1,2

(1.中國科學(xué)技術(shù)大學(xué) 物理學(xué)院，安徽 合肥 230026；2.核探測技術(shù)與核電子學(xué)國家重點實驗室，安徽 合肥 230026)

摘要：各地電梯事故頻發(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é)議；語音壓縮

引用格式：郭曉天，宋克柱, 高林林. 基于LWIP的電梯實時通話系統(tǒng)實現(xiàn)[J].微型機與應(yīng)用，2016,35(12)：1-3，6.

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)是必然的趨勢。

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

整個分布式智能電梯監(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)錯誤代碼能準確判斷出運行故障，從而節(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ù)標志位判定哪個數(shù)組為空，每幀填充耗時為20 ms，填充后更改標志位并觸發(fā)中斷通知CPU對數(shù)組里數(shù)據(jù)進行編解碼操作。

圖2　DMA流程框圖

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

圖3　網(wǎng)絡(luò)通話流程

在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控制器描述符采用鏈式結(jié)構(gòu)，每個描述符都有相應(yīng)指針存儲緩沖區(qū)地址，當(dāng)以太網(wǎng)數(shù)據(jù)包比較大的時候會跨越多個描述符存儲。描述符列表的最后一個描述符會指向第一個，形成鏈式結(jié)構(gòu)[9]。

圖4　DMA描述符結(jié)構(gòu)圖

發(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空閑出來用于處理其他函數(shù)。

表1　優(yōu)化前后運行時間比較

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，則：

(1)

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

(2)

式中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ù)。

圖5　CELP語音編碼器模型(解碼)

在窄帶模式(采樣率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。

圖6　單部電梯通話系統(tǒng)占用帶寬示意圖

本系統(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ī)模使用要求。

參考文獻

[1] 吳衛(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.

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

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

[5] 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.

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

[8] 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.

[10] VALIN J M. The Speex codec manual version 1.2 Beta 3[Z].Xiph.org Foundation,2007.

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

中圖分類號：TP274

文獻標識碼：A

DOI：10.19358/j.issn.1674- 7720.2016.12.001

(收稿日期：2016-02-29)

作者簡介：

郭曉天(1994-)，男，碩士研究生，主要研究方向：數(shù)據(jù)采集與處理。

宋克柱(1966-)，通信作者，男，博士，主要研究方向：物理電子學(xué)。E-mail：skz@ustc.edu.cn。

高林林(1990-)，男，碩士研究生，主要研究方向：數(shù)據(jù)采集與處理。

Implementation of real-time talking system on elevators based on lwIP

Guo Xiaotian1,2，Song Kezhu1,2，Gao Linlin1,2

(1. School of Physics, University of Science and Technology of China, Hefei 230026, China;2. State Key Laboratory of Particle Detection and Electronics, Hefei 230026, China)

Abstract:Recently, as many elevator accidents occurred in several areas of our country, the five party intercom system of elevator used for emergency rescue is important to the trapped people. Aiming at the demand of the real-time talking system of elevator and its stability, this paper gives an implementation project for distributed intelligent elevator monitoring system based on Internet of Things(IoT). Then, it introduces the details of software solution to real-time network talking based on lwIP protocol. To reduce the network bandwidth consuming, the system transplant the Speex algorithm to achieve speech codec compression. The Speex technology enhances the real-time performance and reduces the network width occupancy. When many elevator call requests burst, it ensures the stability of server in elevator monitoring center.

Key words:elevator monitoring; real-time talking; network protocol; voice compression