馬　納　趙國(guó)軍

(浙江工業(yè)大學(xué)特種裝備制造與先進(jìn)加工技術(shù)教育部重點(diǎn)實(shí)驗(yàn)室　浙江 杭州 310014)

?

基于ZigBee電梯無(wú)線轎廂通信的實(shí)時(shí)性優(yōu)化策略

馬納趙國(guó)軍

(浙江工業(yè)大學(xué)特種裝備制造與先進(jìn)加工技術(shù)教育部重點(diǎn)實(shí)驗(yàn)室浙江 杭州 310014)

摘要針對(duì)采用數(shù)據(jù)透明傳輸?shù)腪igBee電梯無(wú)線轎廂通信存在信息傳輸滯后、通信效率較低的缺點(diǎn)，闡述三種常用ZigBee協(xié)議棧并分析轎廂通信原理。以Stm32W108芯片為核心的ZigBee無(wú)線模塊作為應(yīng)用平臺(tái)，提出一種無(wú)線轎廂通信的實(shí)時(shí)性軟件優(yōu)化策略。該策略通過(guò)電梯主控制器端的無(wú)線模塊通過(guò)串口端、無(wú)線端分別收集詢問(wèn)幀及應(yīng)答幀，并由其在規(guī)定時(shí)間內(nèi)回復(fù)電梯主控制器信息，以滿足轎廂通信的時(shí)間要求，最后提出相關(guān)軟件的流程設(shè)計(jì)。經(jīng)實(shí)驗(yàn)表明，該優(yōu)化策略能滿足系統(tǒng)的實(shí)時(shí)性要求，無(wú)線轎廂通信系統(tǒng)的有效通信距離能夠達(dá)到165 m，滿足一般高層建筑的無(wú)線轎廂通信的距離要求。

關(guān)鍵詞ZigBee時(shí)序?qū)崟r(shí)性

0引言

目前，ZigBee無(wú)線技術(shù)作為一種低功耗、低成本、易應(yīng)用的新興無(wú)線通信技術(shù)被廣泛應(yīng)用于智能家居、工業(yè)控制等領(lǐng)域。ZigBee設(shè)備的有效通信距離可達(dá)1～3 km，其最大通信速率可達(dá)為250 kps[1]。因此ZigBee無(wú)線通信能夠很好地滿足電梯轎廂通信的通信距離以及通信速率的要求，這為實(shí)現(xiàn)電梯無(wú)線轎廂通信提供了可能。許多應(yīng)用場(chǎng)合常采用ZigBee的數(shù)據(jù)透明傳輸模塊實(shí)現(xiàn)有線通信系統(tǒng)的無(wú)線化，即由無(wú)線通信模塊轉(zhuǎn)發(fā)來(lái)自串口端的數(shù)據(jù)以及無(wú)線端的數(shù)據(jù)，對(duì)原有的通信設(shè)備無(wú)須作任何改變。但在無(wú)線轎廂通信的應(yīng)用中，采用透明傳輸?shù)臒o(wú)線轎廂通信不僅無(wú)法滿足通信的實(shí)時(shí)性要求，而且降低了通信效率。

針對(duì)上述問(wèn)題，本文基于STM32W108控制器為核心ZigBee無(wú)線模塊，提出一種無(wú)線轎廂通信的實(shí)時(shí)性優(yōu)化策略，解決轎廂通信的實(shí)時(shí)性問(wèn)題，并能兼容原有的轎廂通信系統(tǒng)。

1ZigBee協(xié)議棧分析

STM32W108控制器具有3種協(xié)議棧，分別是Simple MAC協(xié)議棧、ZigBee Pro協(xié)議棧、RF4CE協(xié)議棧。其中Simple MAC協(xié)議棧適用于小型無(wú)線局域網(wǎng)，其應(yīng)用層可直接訪問(wèn)介質(zhì)訪問(wèn)控制層(即MAC層)控制物理層，可控制無(wú)線數(shù)據(jù)的收發(fā)，通信效率高，時(shí)延短；ZigBee Pro協(xié)議棧能夠很好的支持大規(guī)模網(wǎng)絡(luò)，如智能家居、電網(wǎng)監(jiān)測(cè)等網(wǎng)絡(luò)，但ZigBee Pro協(xié)議棧采用隨機(jī)尋址，需要花費(fèi)較多的時(shí)間來(lái)解決地址沖突，無(wú)法較好地完成實(shí)時(shí)的業(yè)務(wù)；RF4CE協(xié)議棧面向消費(fèi)類電子產(chǎn)品的無(wú)線遙控設(shè)備，但是其應(yīng)用層需要通過(guò)網(wǎng)絡(luò)層間接地訪問(wèn)MAC層，所需無(wú)線數(shù)據(jù)收發(fā)處理時(shí)間較長(zhǎng)[2-4]。

圖1　Simple MAC協(xié)議棧軟件層次

由于電梯的轎廂通信系統(tǒng)為點(diǎn)對(duì)點(diǎn)主從通信系統(tǒng)，無(wú)需組建局域網(wǎng)絡(luò)且對(duì)通信時(shí)間要求較高，因此無(wú)線轎廂通信系統(tǒng)采用SimpleMac協(xié)議棧。其軟件層次如圖1所示，其中網(wǎng)絡(luò)層和SimpleMAC的標(biāo)準(zhǔn)函數(shù)庫(kù)已經(jīng)由芯片廠家固化在芯片內(nèi)部。MAC層和物理層使用IEEE802.10.4協(xié)議。用戶只需使用廠家提供的標(biāo)準(zhǔn)庫(kù)函數(shù)進(jìn)行相關(guān)應(yīng)用的開(kāi)發(fā)。所有通過(guò)ZigBee設(shè)備進(jìn)行無(wú)線通信的數(shù)據(jù)幀必須按照MAC數(shù)據(jù)幀格式收發(fā)數(shù)據(jù)，MAC數(shù)據(jù)幀的結(jié)構(gòu)體packet_mac定義如下[5]：

Struct packet_mac {

U_int length ;

//數(shù)據(jù)包長(zhǎng)度

U_char fcf;

//fcf幀低字節(jié)

U_char fcf;

//fcf幀高字節(jié)

U_char seq;

//幀序列號(hào)

U_ char dst_panl;

//目的PAN地址低字節(jié)

U_ char dst_panh;

//目的PAN地址高字節(jié)

U_ char dst_addrl;

//目的短地址低字節(jié)

U_ char dst_addrl;

//目的短地址高字節(jié)

U_ char *dat;

//有效數(shù)據(jù)

};

2轎廂通信協(xié)議分析

基于BP304電梯主控制器的轎廂通信，主要功能是轎廂控制器(CSLP)將采樣到的輸入信號(hào)反饋至電梯主控制器，并由電梯主控制器控制轎廂上的輸出信號(hào)[6]；CSLP上的輸入輸出信號(hào)主要包括開(kāi)門(mén)信號(hào)、關(guān)門(mén)信號(hào)、內(nèi)呼信號(hào)、到站鐘信號(hào)等等。圖2展示了BP304轎廂通信時(shí)序。

圖2　BP304轎廂通信時(shí)序

在一個(gè)通信周期Tc內(nèi)，轎廂通信系統(tǒng)需要完成3組通信幀；電梯主控制器在規(guī)定時(shí)刻輪流發(fā)送3幀詢問(wèn)幀；轎廂控制器在完成一幀詢問(wèn)幀接收后的ts內(nèi)必須回復(fù)相應(yīng)的應(yīng)答幀至電梯主控制器且在回復(fù)應(yīng)答幀后等待時(shí)間tq將收到下一幀詢問(wèn)幀數(shù)據(jù)。 其中ts、tq、Tc分別需滿足ts≤3ms、tq=4ms、Tc=40ms。

3無(wú)線轎廂通信時(shí)序具體實(shí)現(xiàn)

3.1無(wú)線轎廂通信時(shí)序初始方案

無(wú)線轎廂通信系統(tǒng)(如圖3所示)的初始方案采用數(shù)據(jù)透明傳輸?shù)姆绞竭M(jìn)行通信，即電梯主控制器端的無(wú)線模塊A將從串口處接收到數(shù)據(jù)幀按照Simple MAC的數(shù)據(jù)格式進(jìn)行打包，并啟動(dòng)無(wú)線發(fā)送功能；無(wú)線模塊B把來(lái)自無(wú)線模塊A的無(wú)線數(shù)據(jù)包進(jìn)行解包得到轎廂通信的詢問(wèn)幀，并將其通過(guò)串口發(fā)送至CSLP；而CLSP回復(fù)應(yīng)答幀的傳輸過(guò)程與詢問(wèn)幀傳輸過(guò)程相反。然而在實(shí)際現(xiàn)場(chǎng)測(cè)試時(shí)，上述無(wú)線通信方案存在著以下問(wèn)題：通信的實(shí)時(shí)性較差，降低了系統(tǒng)運(yùn)行的效率。通過(guò)示波器測(cè)試發(fā)現(xiàn)(如圖4所示)，電梯主控制器在完成詢問(wèn)幀發(fā)送后12 ms左右才能接收到來(lái)自CSLP回復(fù)的應(yīng)答幀數(shù)據(jù)，因此無(wú)法滿足系統(tǒng)通信的時(shí)間要求。

圖3無(wú)線轎廂通信系統(tǒng)結(jié)構(gòu)

圖4　采用數(shù)據(jù)透明傳輸?shù)臒o(wú)線轎廂通信波形

3.2無(wú)線轎廂通信時(shí)序優(yōu)化策略

為了滿足轎廂通信系統(tǒng)的時(shí)間要求，本文提出以下軟件優(yōu)化策略：電梯主控制器端的無(wú)線模塊A建立詢問(wèn)幀存儲(chǔ)區(qū)Mbuf以及應(yīng)答幀存儲(chǔ)區(qū)Sbuf；當(dāng)無(wú)線模塊A通過(guò)串口接收到詢問(wèn)幀后，將數(shù)據(jù)幀存儲(chǔ)至Mbuf，然后在應(yīng)答幀存儲(chǔ)區(qū)Sbuf內(nèi)搜索到相應(yīng)的應(yīng)答幀數(shù)據(jù)并在規(guī)定時(shí)間內(nèi)回復(fù)電梯主控制器；無(wú)線模塊A通過(guò)無(wú)線功能與轎廂控制器CSLP進(jìn)行無(wú)線通信。具體通信過(guò)程如下：在一個(gè)無(wú)線通信周期TW內(nèi)，由無(wú)線模塊A分時(shí)發(fā)送存儲(chǔ)在Mbuf內(nèi)的三幀詢問(wèn)幀數(shù)據(jù)，而無(wú)線模塊B負(fù)責(zé)將來(lái)自無(wú)線模塊A的詢問(wèn)幀轉(zhuǎn)發(fā)給CLSP并將其返回的應(yīng)答幀數(shù)據(jù)上傳至無(wú)線模塊A處，而無(wú)線模塊A收到應(yīng)答幀后將其存儲(chǔ)至Sbuf。系統(tǒng)通過(guò)合理安排無(wú)線通信的時(shí)序，可使得TW=Tc。無(wú)線轎廂通信的優(yōu)化時(shí)序如圖5所示。

圖5　無(wú)線轎廂通信系統(tǒng)優(yōu)化時(shí)序

系統(tǒng)上電后電梯主控制器端的串口通信的第一個(gè)周期Tc 1內(nèi)，無(wú)線模塊A接收到詢問(wèn)幀后，將其存儲(chǔ)至Mbuf處，然后將詢問(wèn)幀通過(guò)無(wú)線端發(fā)送至CSLP處。由于此時(shí)Sbuf內(nèi)不存在應(yīng)答幀數(shù)據(jù)，故在通信周期Tc 1內(nèi)無(wú)線模塊A無(wú)法回復(fù)電梯主控制器相應(yīng)的信息。又由于TW=Tc，這樣使得第二個(gè)通信周期Tc2內(nèi)，無(wú)線模塊A將有應(yīng)答幀數(shù)據(jù)回復(fù)電梯主控制器，且應(yīng)答幀為上一個(gè)通信周期Tc1內(nèi)詢問(wèn)幀的應(yīng)答幀數(shù)據(jù)。由上述可知，電梯主控制器實(shí)際得到的應(yīng)答幀數(shù)據(jù)將滯后時(shí)間TW，這樣就導(dǎo)致轎廂通信傳輸?shù)男盘?hào)將延遲TW，即40 ms。但由于轎廂通信主要用來(lái)傳輸轎廂開(kāi)門(mén)信號(hào)、關(guān)門(mén)到位信號(hào)、內(nèi)呼輸入輸出信號(hào)等，電梯系統(tǒng)對(duì)這些信號(hào)的時(shí)間要求在200 ms左右，故信號(hào)傳輸滯后并不影響電梯系統(tǒng)的性能。至此無(wú)線轎廂通信系統(tǒng)的時(shí)序要求理論上得到解決。

4無(wú)線轎廂通信軟件設(shè)計(jì)

圖6　系統(tǒng)主程序處理流程

無(wú)線模塊A的主程序流程如圖6所示。其中無(wú)線發(fā)送時(shí)序管理函數(shù)將分時(shí)向CSLP發(fā)送無(wú)線詢問(wèn)幀數(shù)據(jù)，串口發(fā)送管理函數(shù)則是在接收到一幀詢問(wèn)幀數(shù)據(jù)后的ts內(nèi)回復(fù)相應(yīng)的應(yīng)答幀數(shù)據(jù)；系統(tǒng)可通過(guò)Stm32W108內(nèi)部固化的回調(diào)函數(shù)ST_RadioReceiveIsrCallback讀取無(wú)線數(shù)據(jù)。下面將著重闡述串口通信接收的軟件設(shè)計(jì)及其軟件優(yōu)化方法。

無(wú)線通信模塊A采用串口中斷的方式接收數(shù)據(jù)。通過(guò)分析轎廂通信數(shù)據(jù)幀發(fā)現(xiàn)：一幀數(shù)據(jù)幀的首字節(jié)為固定數(shù)據(jù)0x7E且第二個(gè)字節(jié)為數(shù)據(jù)幀的字節(jié)長(zhǎng)度Len。因此系統(tǒng)以接收到0x7E作為接收一幀數(shù)據(jù)幀的起始時(shí)刻，并以接收到的數(shù)據(jù)字節(jié)長(zhǎng)度等于Len作為一幀數(shù)據(jù)接收的結(jié)束時(shí)刻。完成一幀數(shù)據(jù)接收后，系統(tǒng)須驗(yàn)證數(shù)據(jù)幀的正確性。圖7為串口接收中斷處理流程。

圖7　串口接收流程

由于通信過(guò)程中存在數(shù)據(jù)丟失的可能性，就會(huì)直接導(dǎo)致通信出錯(cuò)。因此為了提高通信幀數(shù)據(jù)的完整性與正確性，系統(tǒng)軟件使用以下方法對(duì)數(shù)據(jù)丟失的情況進(jìn)行處理：

接收一個(gè)字節(jié)所需時(shí)間[7]：

T=(Stbit+Dabit+SpBit)/Baud

(1)

圖8　定時(shí)器中斷處理流程

式中，Stbit、Dabit、Spbit分別為一個(gè)數(shù)據(jù)字節(jié)的起始位、數(shù)據(jù)位、停止位；Baud為傳輸波特率，T為串口接收一個(gè)字節(jié)所需時(shí)間。串口通信參數(shù)設(shè)置如下：Stbit=1位、Dtbit=8位、Spbit=8位、Baud=38 400 kps，將其代入式(1)中可知T=260 us。由于通信時(shí)數(shù)據(jù)發(fā)送是連續(xù)的，可知串口所接收數(shù)據(jù)字節(jié)之間的理論時(shí)間間隔Ti=260 us，因此可以認(rèn)為：若Ti>260 us，通信幀數(shù)據(jù)丟失。為此系統(tǒng)軟件中增加一個(gè)軟件看門(mén)狗計(jì)數(shù)器WtCounter，每接收到一個(gè)字節(jié)的串口數(shù)據(jù)復(fù)位WtCounter，即WtCounter=0。同時(shí)在定時(shí)器中斷程序中對(duì)WtCounter進(jìn)行加1計(jì)數(shù)，一旦監(jiān)控WtCounter>=Tcounter，即可認(rèn)為接收數(shù)據(jù)丟失，清零接收計(jì)數(shù)器RxCounter并清空接收緩存，等待接收新的數(shù)據(jù)幀?？紤]到系統(tǒng)運(yùn)行時(shí)處理其他事件的時(shí)間，同時(shí)為了提高系統(tǒng)的容錯(cuò)性，使得Tcounter=2且定時(shí)器中斷時(shí)間Tcycle=260 us。軟件看門(mén)狗WtCounter的處理流程如圖8所示。

5實(shí)驗(yàn)測(cè)試

為了驗(yàn)證無(wú)線轎廂通信的實(shí)時(shí)性軟件優(yōu)化策略的正確性，搭建實(shí)驗(yàn)平臺(tái)(如圖9所示),1是BP304電梯主控制器，2是無(wú)線通信模塊B，3是CSLP轎廂控制器，4是棒狀天線，5是無(wú)線模塊A。無(wú)線模塊采用REX3SP型ZigBee無(wú)線模塊，其主控核心為ARM Cortex-M3內(nèi)核的STM32W108芯片。無(wú)線模塊的接收靈敏度為-104 dBm，發(fā)射最大功率為+23 dBm，天線增益為2 dBi[8]。由于無(wú)線轎廂通信系統(tǒng)的使用環(huán)境為電梯井道且通信距離會(huì)直接影響到通信速率和信號(hào)，為了能模擬井道中空曠環(huán)境，因此本次實(shí)驗(yàn)選擇在浙江工業(yè)大學(xué)學(xué)校操場(chǎng)上進(jìn)行通信測(cè)試。若實(shí)驗(yàn)過(guò)程中BP304電梯主控制器端的轎廂通信出現(xiàn)通信延遲或者其他錯(cuò)誤，將在其液晶顯示屏上報(bào)告轎廂通信故障。

圖9　無(wú)線轎廂通信系統(tǒng)實(shí)驗(yàn)平臺(tái)

經(jīng)實(shí)驗(yàn)測(cè)試，電梯主控制器端一次串口通信波形如圖10所示。電梯主控制器發(fā)送完一幀詢問(wèn)幀后將在1 ms內(nèi)收到相應(yīng)的應(yīng)答幀數(shù)據(jù)；通信過(guò)程中電梯主控制器未報(bào)告轎廂通信故障(通信波形如圖11所示)，說(shuō)明電梯主控制器都能在規(guī)定時(shí)間內(nèi)收到應(yīng)答幀數(shù)據(jù)，滿足轎廂通信系統(tǒng)的時(shí)間要求；系統(tǒng)通信有

效通信距離為165 m，目前國(guó)內(nèi)一般高層建筑在100米以內(nèi)，故無(wú)線轎廂通信系統(tǒng)的有效通信距離能夠滿足實(shí)際要求[9]。

圖10　一次無(wú)線轎廂通信電梯控制系統(tǒng)端通信波形　　　圖11　無(wú)線轎廂通信電梯控制系統(tǒng)端通信波形

6結(jié)語(yǔ)

本文在對(duì)SimpleMAC協(xié)議以及轎廂通信的原理分析的基礎(chǔ)上，重點(diǎn)闡述了改善無(wú)線轎廂通信效率的軟件解決方案。針對(duì)相關(guān)軟件提出了軟件優(yōu)化方法，提高了系統(tǒng)通信的魯棒性。經(jīng)實(shí)驗(yàn)表明，該實(shí)時(shí)性優(yōu)化策略能夠提高無(wú)線轎廂通信的效率，符合系統(tǒng)的時(shí)間要求。實(shí)驗(yàn)所測(cè)得的系統(tǒng)有效通信距離為165 m，但根據(jù)自由空間傳播模型的定義，可選用較大增益的天線來(lái)增大系統(tǒng)的通信距離，這樣就可以滿足超高層建筑的使用要求[10]。目前國(guó)內(nèi)電梯控制領(lǐng)域尚無(wú)ZigBee技術(shù)相關(guān)的應(yīng)用，但是ZigBee技術(shù)在電梯控制領(lǐng)域具有廣泛的應(yīng)用前景。例如電梯外呼控制系統(tǒng)、電梯遠(yuǎn)程監(jiān)控系統(tǒng)、電梯群控系統(tǒng)等都可采用ZigBee進(jìn)行信息傳輸，這樣將大大降低電梯系統(tǒng)的材料成本、安裝成本以及故障排查的難度[11]。

參考文獻(xiàn)

[1] 翟雷,劉盛德,胡咸斌.ZigBee技術(shù)及應(yīng)用[M].北京:北京航空航天大學(xué)出版社,2010.

[2] 沈建華,郝立平.STM32無(wú)線射頻ZigBee單片機(jī)原理與應(yīng)用[M].北京:北京航空航天大學(xué)出版社,2010.

[3] ST Microelectronics Group of Companies.User manual STM32W108xx ZigBee RF4CE library[OL].2011-5.http://www.st.com/mcu,2010.

[4] http://www.ti.com.cn/general/cn/docs/gencontent.tsp?contentId=93552.

[5] ST Microelectronics Group of Companies.STM32W108xx simple MAC library[OL].2011-6.http://www.st.com/mcu,2011.

[6] 德國(guó)奔克公司.BP304系列電梯控制系統(tǒng)技術(shù)手冊(cè)[M].德國(guó)奔克公司,2010.

[7] 王富東,邵光慶.單片機(jī)多串口通信技術(shù)及其應(yīng)用[J].儀器儀表學(xué)報(bào),2002,23(3):267-269.

[8] 浙江瑞瀛網(wǎng)絡(luò)科技有限公司.REXBEE模塊產(chǎn)品手冊(cè)[OL].2011-6-4.http://www.rexense.cn/downloads,2011.

[9] 中華人民共和國(guó)建設(shè)部.GB50352-2005.民用建筑設(shè)計(jì)通則[S].中國(guó)建筑工業(yè)出版社,2005.

[10] 李迎春,朱詩(shī)兵.星間鏈路自由空間傳播衰減的分析[J].科學(xué)技術(shù)與工程,2009,9(13):256-259.

[11] 段登,邱意敏,周力.基于ZigBee技術(shù)+3G網(wǎng)絡(luò)的多電梯遠(yuǎn)程監(jiān)控系統(tǒng)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,2011,2(3):185-189.

OPTIMISATION STRATEGY FOR WIRELESS ELEVATOR CAR COMMUNICATION WITH REAL-TIME PROPERTY BASED ON ZIGBEE

Ma NaZhao Guojun

(KeyLaboratoryofSpecialEquipmentandAdvancedManufacturingTechnology,MinistryofEducation,ZhejiangUniversityofTechnology,Hangzhou310014,Zhejiang,China)

AbstractZigBee wireless elevator car communication using transparent data transmission has the deficiencies of information transmission delay and low communication efficiency. In light of this, we expounded three commonly used ZigBee protocol stacks, and analysed the principle of car communication. Taking ZigBee wireless module, having the core of Stm32W108 chip, as the application platform, we presented a software optimisation strategy for wireless car communication with real-time property. The strategy collects the query frame and response frame through the ends of serial port and wireless respectively with the wireless module of elevator’s main controller, and replies elevator’s main controller information within a specified time, so as to meet the time requirements of car communication. Finally, we gave the process design of correlated software. It has been demonstrated by experiment that the optimisation strategy can meet the real-time property requirement of the system; the effective communication distance for wireless car communication system can reach 165 m, this satisfies the distance demand of wireless car communication for general high-rise buildings.

KeywordsZigBeeTimingReal-time property

收稿日期：2014-11-19。馬納，碩士生，主研領(lǐng)域：電梯控制系統(tǒng)。趙國(guó)軍，教授。

中圖分類號(hào)TP3

文獻(xiàn)標(biāo)識(shí)碼A

DOI:10.3969/j.issn.1000-386x.2016.05.028