ZigBee星狀網絡故障修復仿真方案

摘? 要：針對大范圍低速率數據采集ZigBee星狀網絡中協調器節點故障導致系統癱瘓的問題進行了分析，提出了協調器節點發生故障后，其他數據采集節點通過競爭產生新的協調器節點，從而組建和維護新的網絡的自適應組網方案，實現網絡故障的自動修復。并重點設計了數據采集節點的競爭組網算法，以及該算法的基于計算機網絡和桌面平臺軟件的仿真驗證方案。

關鍵詞：數據采集;網絡修復;仿真

Abstract：Aiming at the problem of system paralysis caused by the failure of coordinator node in large range low speed data acquisition ZigBee star network. After the failure of the coordinator node，other data acquisition nodes produce new coordinator nodes through competition，so as to set up and maintain the new network and realize the automatic repair of the network fault. And focused on the design of the data collection nodes competitive networking algorithm，and the algorithms simulation verification program based on computer network and desktop platform software.

Keywords：data acquisition;network repair;simulation

0? 引? 言

ZigBee無線網絡通信技術基于IEEE 802.15.4協議構建，具有價格低廉、功耗低、組網靈活的優點，被廣泛應用于電力塔數據采集、光伏發電系統數據采集、農業數據采集等需要大范圍低速率數據采集的場景。ZigBee具有星狀、網狀和樹狀三種典型的網絡結構[1]。具體采用哪種網絡結構需要根據采集對象的區域分布狀況而定，如電力塔分布區域呈長條狀，其數據采集網絡宜采用網狀結構[2]。農業數據采集因土地分布區域一般呈類圓形分布，宜采用星狀網絡以降低功耗、提高效率[3]。ZigBee星狀網絡的建立和維護均依賴于協調器類型節點，如果協調器類型節點發生故障，將導致整個系統的癱瘓[4]。為提升可靠性，需對ZigBee星狀網絡故障問題進行分析，提出自適應組網的故障修復方案，并在此基礎之上，利用計算機網絡和桌面平臺軟件開發仿真系統，以評估和驗證故障修復方案的可行性。將經過仿真驗證的ZigBee星狀網絡修復方案應用于工程實際，可提升網絡的可靠性。

1? 網絡故障問題分析

如圖1所示為數據采集星狀網絡的系統結構，系統由四個環節組成：數據采集終端、數據中轉站、運營商網絡和系統服務器。數據采集終端由ZigBee網絡的終端類型節點實現，它負責采集數據并將數據以ZigBee網絡的點播通信方式傳輸至數據中轉站。數據中轉站由ZigBee網絡的協調器類型節點及其攜帶的DTU模塊（Data Transfer Unit，其功能為通過GPRS協議連接到運營商網絡）組成，其ZigBee協調器節點接收到數據后按照設計的報文格式，使用DTU模塊將數據傳輸至服務器[3]。

這種方案僅使用了ZigBee網絡的終端和協調器兩種節點類型，未使用路由器類型，免去了ZigBee網絡內部數據經路由器中轉帶來的額外能源和時間開銷，具有結構簡單、運行效率高的優點[5]。但這種方案又同時存在一個重大缺陷：數據中轉站的穩定性成了保證系統正常運行的關鍵，當數據中轉站發生故障，所有數據采集終端將無法把采集到的數據上傳到服務器，整個系統處于癱瘓狀態。此時，必須人為干預進行系統故障的排查和修復，降低了系統數據時效性的同時，提升了系統的運維成本。

2? 網絡故障修復總體方案設計

如上文所述，數據中轉站故障導致整個系統癱瘓問題的原因在于：所有數據采集終端均通過一個數據中轉站上傳數據至服務器。為解決這個問題，需在系統中部署冗余設備，為冗余設備配置DTU模塊。當冗余設備檢測到數據中轉站發生故障后，立刻充當新的數據中轉站，完成傳感器網絡維護和數據中轉的工作，以下為部署冗余設備的兩種方案。

2.1? 方案一

第一種方案是將原有系統中使用的ZigBee星狀網絡改為ZigBee網狀網絡，由網絡中ZigBee路由器類型節點充當冗余設備。

如圖2所示為ZigBee網狀網絡結構，正方形表示協調器類型節點，圓形表示路由器類型節點，三角形表示終端類型節點。ZigBee網絡中只能有一個協調器類型節點，但可以有多個路由器節點，當網絡在協調器的組織下建立起來后，協調器類型節點的缺失并不影響已經建立起來的網絡的運行。當協調器發生故障，路由器繼續保持對網絡的維護，并收集網絡中其他節點的數據后，通過運營商網絡上傳至服務器。

這種方案在現有技術基礎之上構建，具有部署簡單，技術成熟可靠的優點，但同時也存在兩個問題：

（1）網狀網絡結構比原有星狀網絡結構復雜，在系統正常運行期間，路由器節點將始終負責節點之間的數據轉發工作，加大了路由器節點的運作負載和能源開銷。

（2）為提升系統的可靠性，可在網狀網絡中部署多個路由器類型節點，當協調器發生故障，通過何種方法從多個路由器中選擇出合適的節點來充當數據中轉站也需要進一步研究。

2.2? 方案二

第二種方案是構建新型的自適應無線網絡。這種網絡同樣基于IEEE 802.15.4協議，依然采用星狀結構，但不再使用ZigBee中協調器、路由器和終端類型的概念。

如圖3（a）所示，在網絡建立前，每個節點的地位是平等的且均攜帶DTU模塊（休眠狀態），可稱其為Free節點（圓形節點）。如圖3（b）所示，上電后，所有Free節點通過競爭的方式產生Root節點（正方形節點），其余節點則作為Leaf節點（三角形節點）。Root節點負責接收Leaf節點的數據并將其通過DTU模塊上傳服務器。如圖3（c）所示，當Root節點發生故障（黑色正方形節點），網絡中的所有Leaf節點再回到Free狀態。如圖3（d）所示，所有Free節點重新通過競爭的方式產生新的Root節點，組建新的網絡。

這種方案的優點是采用星狀的網絡結構，避免了網狀結構中數據的轉發，系統運行效率高，降低能耗，提升了系統的續航能力。此外，系統結構扁平，每個節點的類型完全一致，不像普通的ZigBee網絡分為終端、路由器和協調器的節點類型，需要對各種類型的節點單獨進行程序設計。但這種方案不再直接使用ZigBee協議棧的自動組網功能，需要對網絡建立和維護的協議，特別是節點間的競爭算法進行設計。

3? 節點運行流程及競爭算法設計

上文所述的兩種方案中，方案二相對方案一的運行效率和部署靈活性更高，因此，筆者選擇了這種方案，并對其節點運行流程及組網競爭算法進行設計。

3.1? 節點運行流程設計

為實現方案二中的組網方式，將網絡中的節點工作狀態設計為3種（故障狀態不做單獨設計）：

（1）Free狀態。當節點沒有加入任何網絡時的狀態，即節點設備剛上電時的狀態，或當網絡中Root節點剛發生故障時Leaf節點的狀態。

（2）Root狀態。此狀態的節點接收從Leaf節點發來的數據，并將其通過DTU模塊上傳至服務器，此外，它還將完成對網絡的維護工作（主要為查詢Leaf節點狀態）。

（3）Leaf狀態。此狀態節點負責定時采集數據，并將其發送到Root節點。

系統網絡結構的宏觀變化將反映到微觀每一個節點的狀態轉換上。如圖4所示，當上電初始化時，節點設備狀態為Free，它首先廣播詢問周圍是否存在Root節點。若收到Root節點的應答，將把自身狀態設置為Leaf。若未收到應答，說明尚不存在Root節點，開始與周圍的Free節點競爭，競爭成功則將自身狀態設置為Root，否則將自身狀態設置為Leaf。若Leaf節點檢測到網絡故障，即失去與Root節點的連接，將自身狀態設置為Free。

3.2? 競爭機制設計

當Free節點通過廣播詢問后未能找到Root節點，將與周圍的Free節點通過競爭產生Root節點。為提高系統運行效率和盡可能擴展網絡的覆蓋面積，競爭的原則是：與周圍節點建立的連接數最多的節點成為Root節點，否則成為Leaf節點。競爭分以下三個階段進行：

第一階段：Free節點首先向周圍節點發出啟動競爭報文，然后啟動定時器1。定時器1計時滿之前，它將收到其他Free節點發來的啟動競爭報文，并統計該類報文的數量，這標志著它具有連接的Free節點數量。

第二階段：定時器1計時滿，啟動定時器2，每個Free節點將自己具有連接的Free節點數量打包成報文向具有連接的Free節點發送出去，同時會收到別的Free節點發來的同類型報文，并記錄下各個Free節點的具有連接的Free節點數量。

第三階段：定時器2計時滿，各個Free節點比較自己具有連接的Free節點數量與其他Free節點具有連接的Free節點數量。如果自己的數量最多，則將自身狀態設為Root，等待其他設備登錄，否則將自身狀態設置為Leaf，并且向Root節點發出請求連接的報文。需要注意此時可能會出現特殊情況，即當自己的數量與其他Free節點的數量相等，則約定ID號小的設備為Root節點。

4? 故障修復仿真方案設計

上文設計的方案不直接使用ZigBee協議棧自動組網功能，需自行開發實現節點的競爭組網算法。由于無線數據采集網絡節點數量較多，直接針對多個節點硬件設備設計軟件，開發成本較高且多節點組網調試難度較大。為此，在針對節點硬件進行開發之前，可利用計算機軟件對系統進行仿真，以驗證故障修復競爭組網算法的可行性，并提升開發效率。

4.1? 仿真系統設計

在Microsoft Windows平臺Visual Studio環境下使用C++語言開發一個模擬系統服務器的服務器應用和一個模擬數據采集節點的節點應用。多個數據采集節點由一個節點應用的若干個實例進程來模擬，這樣既保證了可靈活創建若干個節點實例進程，又保證了各個實例的完全一致。各個節點應用實例進程使用不面向連接的UDP/IP協議通信以模擬數據采集節點間基于IEEE802.15.4協議的無線通信。各個節點應用實例進程與服務器應用通過面向連接的TCP/IP協議通信以模擬數據中轉站通過運營商網絡與系統服務器的通信。

4.2? 仿真驗證過程及結果

整個仿真系統較復雜，因此重點對節點間故障修復競爭自組網功能進行驗證。

首先，在系統中同時運行節點應用的四個實例。如圖5所示，圖中每個對話框對應一個節點應用實例。手動為四個實例設置不同的ID（該ID同時為該應用實例的網絡端口號）后，分別點擊其“打開節點”按鈕，以模擬節點上電初始化后的Free狀態。

系統中不存在Root節點實例，四個Free節點實例啟動競爭。由于四個實例運行于同一臺計算機環境，四個實例之間均具有網絡物理連接（即每個節點實例具有連接的節點實例數相等，均為3），按照競爭算法的約定，ID最小的節點狀態將轉換為Root，其余節點狀態將轉換為Leaf。如圖6所示，通過競爭后ID為6000的節點實例狀態轉換為Root，其余均轉換為Leaf。

手動點擊狀態為Root的節點實例（ID為6000）對話框中的“關閉節點”按鈕，以模擬Root節點的故障狀態。此時如圖7所示，三個Leaf節點實例（ID分別為6001，6002，6003）因失去與Root節點實例的連接，自身狀態轉換為Free。

三個Free節點實例在沒有找到Root節點實例后再次啟動競爭。三個實例之間均具有網絡物理連接，按照競爭算法的約定，ID最小的節點狀態將轉換為Root，其余節點狀態將轉換為Leaf。如圖8所示，通過競爭后ID為6001的節點實例狀態轉換為Root，其余均轉換為Leaf。

5? 結? 論

在數據采集中應用ZigBee星狀網絡可提升系統效率。本文作者針對這種網絡結構中協調器節點故障將導致系統癱瘓的問題，提出新型的自適應網絡方案，并對網絡中節點的運行流程及競爭組網算法進行設計。為提升開發效率并驗證組網競爭算法的可行性，還基于Windows平臺和計算機網絡設計了仿真系統方案。新型的自適應網絡具有組網靈活、適應能力強的優點，能有效提升數據采集系統的可靠性和運行效率。

參考文獻：

[1] 黃超，普平貴，王偉.基于ZigBee技術的無線傳輸網絡應用 [J].電工文摘，2016（4）：32-33.

[2] 陳少華，鄭紫微，茅迿.用于電力塔遠程監控的無線傳感器網絡裝置 [J].電力自動化設備，2011，31（7）：136-139.

[3] 莫章潔.基于ZigBee與GPRS的農業數據采集系統設計 [J].貴州師范學院學報，2016，32（9）：40-43.

[4] 盧俊文.Zigbee技術的原理及特點 [J].通訊世界，2019，26（3）：35-36.

[5] 蔣挺，趙成林.紫蜂技術及其應用 [M].北京：北京郵電大學出版社，2006：9-12.

作者簡介：莫章潔（1987—），男，壯族，廣西南丹人，講師，碩士，研究方向：標準化數據采集。