XBee3与XBee S2C混合应用注意事项（石油A11领域）
中石油在油氣產業自動化走在國內的前列，采用了標準的Zigbee無線協議，A11協議是多年前召集多家無線供應商共同研討并制定的標準，中石油也對該協議的應用提出許多自己的要求。雖然中石油的數字化油田戰略已經實施多年，有A11作為一種標準體系，但是由于各個廠家的技術水平，產品的可靠性和智能化水平不盡相同，在具體實施環節常會碰到一些障礙，容易發生不同廠家的數據互通問題，影響生產效率。具體而言，在無線儀表這塊，由于有不同廠家的參與，雖然有A11標準確立了大方向，但各廠家的適配上有時仍需要相互協調，一般以RTU為主，不同廠家的傳感器為輔。具體到項目環節，由于不同傳感器廠家的自適應能力和兼容性測試驗證做得不充分，在項目實施環節的表現差異較大。
目前能入圍且批量部署并穩定運行的，大多是采用XBee無線模塊的產品和方案。隨著XBee系列產品的更新換代，能符合Zigbee 3.0標準的XBee3橫空出世，慢慢地將替換原有的XBee S2C。A11協議并沒有隨時代變化而演進，而XBee3提供了許多新的特性，但也為向前兼容S2C 做了許多兼容優化。在實際應用中，不論是傳感器還是RTU，XBee3都可以直接替換S2C部署在產品上。對于S2C和XBee3混合組網的場景，需要了解這兩代產品的異同，以便盡可能在軟件上實現無憂的混合組網智能部署，減少等待時間和丟包率以及人工干預的情況。本文試圖從產品設計和兼容性驗證，無線ZigBee協議的注意事項等方方面面來討論如何讓自家產品做到兼容百搭，智能部署。
一、初級篇
本節主要是針對初級用戶，希望能簡單地對無線模塊進行配置，而不想在程序上做太多的智能部署設置的用戶。雖然簡單配置也能滿足基本的項目實施和應用，但由于缺少程序的網絡管理和智能部署功能，在參數和模塊選型上要多下功夫。
1. 模塊選型。
Digi XBee Zigbee模塊是應用最為廣泛的符合ZigBee聯盟協議規范的無線模塊。ZigBee系列模塊從第一代的XBee S2B，演進到S2C，以及目前最新的XBee3，只要是ZigBee協議的模塊，都可以相互兼容通信。
如果是新項目設計，盡量采用XBee3，老產品也應盡快升級，在PCB封裝設計上盡量做到大小模塊封裝兼容，以應對供應鏈緊張時帶來的風險。Digi的無線模塊分為普通型和增強型，只有發射功率的區別，應盡量選擇增強型版本，以在復雜的電磁環境中增強信號，減少丟包率。
2. 固件。
Digi會定期發布XBee模塊的新固件，主要是增加功能特性并修復已知bug。如果沒有解決bug或是新特性的需求，現有的模塊并不需要升級到最新的固件版本。但XBee模塊在生產時總是會以最新發布的固件來進行生產，反應到模塊的標簽上，就是不同的revision。一般情況下固件會在充分測試后發布，由于每個用戶的應用配置不盡相同，很難保證某些特定配置下不會有一些bug出現，因此最好的方式是閱讀Release Note，根據相關描述避開或繞過潛在的影響。建議客戶在新的項目上馬之前，對現用產品的當前可用的固件做充分測試，確保沒問題后再量產。
下面列出近兩年來一些中國區用戶常碰到的固件問題和解決方案：
XBee S2C
問題固件：405F；主要問題：休眠節點的polling timeout異常。
問題固件：4061；主要問題：當休眠節點NJ<FF時，rejoin機制不可用，并且無法加回原父節點。
解決問題：回退或升級4059、4060、4062等固件版本。
XBee3
和XBee S2C混合組網時，協調器應至少用100B固件，不可用更早期的固件，以便真正兼容原S2C的協調器行為。
3. 參數配置。
中石油A11無線儀表規范在設立之初參考了當時Zigbee協議的標準和知名的XBee無線模塊API標準，而ZigBee協議作為一種開放的無線物聯網協議有許多優勢，首先是安全性，中石油的物聯網通信時需采用加密的ZigBee協議通信，因此各廠家的RTU和儀器儀表均需要開啟加密模式。要做到互聯互通，各廠家在加密參數上需要保持一致。傳感器設備上，休眠參數上應盡量和協調器的休眠參數保持大致相同或接近。
有關XBee的休眠參數，許多人并未深刻理解其意義，可以參考附錄1。
XBee3還應該設置C8＝10，ET的值應該略大于休眠時長。此外，開啟入網公告的功能有助于進階用戶的程序設計，因此通常JN＝1。其它常見的參數請參考A11的協議要求。
值得注意的是，由于ZigBee 3.0的升級，XBee3和S2C中有些默認參數并不一樣，通常您可以按S2C的參數來設置XBee3。但在ZigBee 3.0中引入分布式網絡概念，其中EO默認是配置成2，也就是集中式網絡；而在S2C上，并沒有這個概念，因此S2C的EO默認值是0，而實際應用上也大多是使用S2C協調器來作為集中式網絡的中心。因此通常在中石油的A11的加密網絡中不用按S2C的EO值去設置XBee3，而是保持XBee3的EO=2，以防止在兩種模塊的混合網絡中的出現協調器默認的0地址無效的情況。詳情可以參考附錄2。
二、進階篇
ZigBee是一種無線網絡協議，而ZigBee設備都必須支持ZigBee網絡的基本功能。雖然XBee模塊可以不需要應用程序配合來管理最基本的ZigBee網絡，但在實際應用中，通?？梢灾鲃永肸igBee協議的網絡功能實現智能部署和安裝調試。
設備列表：一個完備的ZigBee產品，是能夠在程序空間建立一張通信設備的列表，它有一系列好處，比如可以記錄并采用16位短地址的方式通信，減少出錯機率。RTU可以對在網設備進行鑒權，主動剔除第三方設備，可以同時和多個目標設備通信，比如傳感器不僅可以把數據傳給RTU，還可以發給router設備等。通?？梢栽诓渴鹉Ｊ诫A段主動掃描或是通過入網通知的API幀來添加設備到列表當中。對于設備列表，還應該有剔除的機制，畢竟有些設備會損壞，更新或替換，通常是以一定時間都無法成功通信上來作為設備已不在現場標志。
有兩種API幀可作為設備入網通知來把設備添加到列表中，一種是利用ZigBee本身的Joining Announce，它的不依賴于JN參數，缺點是只有入網時有一次通知，并且不太好識別設備類型，因此這種方式通常還需要配合在部署時主動掃描。另一種是利用XBee的JN參數，當JN＝1時，設備會在入網或reset后向網內其它設備公告自己的身份。油田上的設備經常有reset動作，即使錯過了首次入網通知，還可以后續在對方設備reset后獲取，因此這種方式添加設備列表比較容易。
運行模式：無線網絡通常會有入網，離網等動作，因此在程序中制定產品的工作模式，有利于更高效組建好網絡并保障可靠通信。比如在產品的部署階段，可以定義為部署模式，此時以加快網絡部署為目標，可以增加主動掃描的功能和一些握手鑒權等功能，在產品的正常工作模式下，可以關閉一些功能以便產品能無負擔地專注于應用的實現。調試模式則可以開啟一段調試代碼，方便現場調試，雖然這些模式在產品設計中并非不可或缺，但合理安排仍可能最大化保障產品對各種異常環境的兼容能力。對于RTU來說，可以很方便通過按鈕來切換模式；對于無按鈕的傳感器，則應該主要考慮在程序中智能實現各種模式的切換。
三、高級篇
XBee3已經推出有一段時間了，在許多項目上可以直接替換。但在一些特別的應用場景，仍可能存在一些尚未解決的兼容性bug。盡管由于zigbee 3.0協議的升級，一些兼容性的功能只能通過專用參數或在特定的參數組合下實現，Digi仍然會致力于讓XBee3能完全取代和替換S2C，而不需要對傳統使用S2C的產品作出修改。
最新發現的一個bug是在開啟APS加密的情況下出現。XBee模塊在開啟EE后，網絡包已經是加密了，但由于許多早期用戶對ZigBee了解不深，在產品中還額外開啟了APS加密。APS加密實際上是在加密網絡包內對任意兩點的應用層的payload再做進一步加密，意義不大，工業場景很少被使用。在XBee API模式中有個transmit option字段，默認為0x00，中石油不少RTU和傳感器的早期用戶就在XBee中采用了transmit option=0x60這種方式進行通訊。
下面做S2C和XBee3開啟APS層加密通訊的兼容性測試。本次測試所用固件：100D和4061。
一、XBee3作為協調器, S2C作為路由器
方向：S2C –> XB3
剛開始時通訊正常，大約過5分鐘后， S2C發不成功，錯誤代碼：21 (Network ACK Failure)。
如果對S2C進行reset，仍不能修復，但錯誤代碼變成：24 (Address not found)。
使用00作為協調器16位地址，結果仍一樣。
方向：XB3 –> S2C
剛開始時通訊正常，大約過5分鐘后，發不成功，錯誤代碼：24 (Address not found)。
使用真實的16bit地址而不用FFFE，結果仍一樣。
把S2C的EO改為和XBee3一樣的0x2看看結果，要讓雙向通訊恢復，只有S2C發ATNR退網才行。
二、XBee3作為路由器，S2C作為協調器
奇怪的是，如果S2C作為協調器，XBee3作為路由器，并不會有這個bug。
初步結論：這是一個不常用的bug，只有當XBee3作為協調器時，S2C作為路由器時，并且API幀中的發送選項開啟了APS加密（0x20或0x60），才會出現。
解決思路：
是否能在XBee3的配置中解決？很可能是NK或trust center的因素，需要測試以下幾種臨時解決方案：
1. 設置XBee3的EO＝0。這個設置會導致地址0不能代表XBee3作為協調器了，S2C發XBee3只能用FFFE或是真實的16位短地址。如果用0作為短地址發不通，并且會阻塞后續的發送（除非退網）。
2. 固定NK的值。實驗表明，NK即使雙方配置成一樣的默認值，這個bug也依然存在。
這個bug的解決要等Digi發布新版的XBee3固件。對于混合組網的設備產家來說，在程序中不盲目采用部分廠家的0x60發送選項的設備制造商，在S2C到XBee3換代升級過程中受到的影響最小。
補充：RTU為XBee S2C, 傳感器為XBee3
1、因ET參數默認值產生傳感器多次入網短地址發生變化的問題
問題描述：根據報告，當休眠參數SPSN的值大于ET定義的時間，則ET時間到后會有退網的現象。
用開發板重現：
S2C（4060固件）協調器配置：ZS＝2, ID＝58, CE＝1, AP=1, AO=1，BD＝7，SP＝AF0，SN＝7，SO＝6，EE＝1，EO＝0，KY＝11，NK＝0, NI=end
XBee3（100B固件）休眠終端配置：ZS＝2, ID＝58, CE＝0, AP=1, AO=1，BD＝7，SP＝AF0，SN＝7，SO＝6，EE＝1，EO＝0，KY＝11，NK＝0, NI=cord
測試時一般要記錄一下MY的值，以觀察是否有變化。
在XCTU上兩個模塊都可以觀察到cluster 0013的入網通告，可見休眠節點有離網過程。由于重新加網，所以休眠節點的短地址會變化。這個問題可以歸結于，ET比休眠周期小，它認為自己時間到了要重入網，而協調器為S2C只看休眠參數，并沒有ET值。
解決方法：將ET值改為大于休眠周期的值，則這個問題消失。
2、更換協調器問題
參數配置同1，在S2C時，不論NJ<FF還是NJ＝FF，都不需要發ATNR來離網，而是通訊不上時會自動離網，在XBee3時，需要發ATNR0, 通訊不上, polling沒有時不會主動退網。
附錄1：詳解XBee ZigBee模塊的休眠參數和相關意義
ZigBee設備可分為協調器，路由器和終端節點三種角色，其中只有終端節點可以休眠，在睡眠期間可以實現極低功耗，在醒來后又可獲取休眠時期收到的數據。休眠參數不僅對終端節點有意義，在作為父節點的協調器或路由器，也同樣有著重要的功能。
XCTU上，在配置界面的Sleep Modes區塊，列出了所有的休眠參數：SP、SN、SM、ST、SO、WH、PO、ET，不同版本可用參數略有差異，下面詳述：
SP：休眠周期。
休眠節點的SP代表休眠時間，也就是每隔SP*10ms的時間，休眠模塊會醒來查詢自己的數據。而在協調器或路由器上，它代表的是父節點收到數據后能為其子節點緩存多久。
SN：周期倍數。
這個參數用于設置polling timeout，算法是：3 * SN * (SP * 10ms)。休眠節點醒來時會向父節點查詢自己的數據，這個過程叫polling。如果在polling timeout規定的時間內，父節點沒有收到子節點查詢請求，則父節點會把子節點從它的子節點列表中移除。XBee的協調器或路由器都能作為父節點為子節點緩存數據，每個模塊最多可以掛20個子節點。當子節點從網絡中移除，需要有個機制在父節點中也把該節點從列表中除名，也就是父節點不再為該子節點緩存數據，從而讓出空間給其它節點，這個機制就叫polling timeout。值得注意的是，XBee3支持最新的ZigBee 3.0協議，支持休眠子節點設備入網時向父節點報告自己的polling timeout時間，也就是不同的設備可以有不同的超時時間，而不需要在父節點處統一設置。
ET：子節點超時時間。
這個ET是ZigBee 3.0后引入XBee3的，主要是用在休眠節點。對于混合組網的情況，當XBee3作為協調器或路由器，而網內有S2C的休眠節點時，應該把父節點的ET也配置得和休眠周期差不多，略大些即可。
ST：醒來時間。
該參數僅在周期休眠中使用（SM＝4，5)，其代表沒數據活動多久后進入休眠。當XBee在收發數據時，模塊不能立即進入休眠狀態，它必須等待收發結束后一段空閑時間都再無數據，以保證收發數據能順利完成。這個時間正是ST定義的。休眠節點醒來時polling父節點后，發現沒有數據一般可以立即休眠，而無需等待ST時間，但有時模塊不僅是接收，也需要外發信息，因此我們也可配置模塊醒后保持ST時間，以有足夠的時間通過串口來發送數據或命令，這是在后面的SO中配置。
SO：休眠選項。
這是兩個字節的參數，注意bit0不用，目前僅bit1,bit2有定義。bit1: 在SN個休眠周期后，強制醒來ST時間。bit2: 啟用擴展休眠周期，即休眠SN*SP時間。由于父節點在收到數據后只為子節點緩存SP定義的時間，而SP最大只能設置28秒，所以啟用擴展休眠周期是有可能丟數據的。
WH：喚醒主機時間。
設備從睡眠中醒來，到發送數據到串口的允許時間。有些設備是通過XBee模塊的信號喚醒或給處理器上電的，而主機醒來是需要時間，通過這個參數來確保從父節點收到的數據通過串口吐出給MCU時，MCU能準備好接收。
PO：查詢時間。
這個參數定義模塊醒著時，多久向父節點查詢一次數據。默認是100ms。
通過理解模塊的休眠參數，我們可很好的利用它的性能，靈活安排程序任務，最大少減少不必要的丟包。
附錄2：從S2C升級到XBee3需要注意哪些問題
ZigBee 3.0對網絡安全有著遠比過去更嚴格的定義，為了適應這一變化，一些默認參數值在XBee3時代有了一些變化，在實際使用中，程序的邏輯應針對這些變化做相應的調整，特別是NJ參數和C8參數。
1、NJ
NJ是一個允許模塊開放網絡的參數。在S2C時代，它默認值是0xFF，表示任何時候都允許其它模塊加入該網絡；而在XBee3，它的默認值是0xFE，也就是在上電254秒后，會自動關閉加入功能。因此，如果和之前S2C混合組網，可以將該參數改為0xFF。必須注意的是，一個更安全的網絡，應該是在適時開啟加入，也就是一個網絡出于安全考慮，應該只在開放部署時，才允許終端加入，應用程序設置有不同的模式（部署模式，開放部署維護模式，封網運作模式……)，能更好地維護和管理無線網絡。
2、C8
XBee3使用更新的zigbee協議棧，它計算LQI曲線和S2C不同，如果一個網絡內全用XBee3，并不需要設置該參數，默認值就可以。如果一個網絡內有S2C和XBee3混合組網，則需要把XBee3的C8設置成10，以便達到最好的效果。混合組網中，C8不設置的話，S2C會更容易成為router跳點。該參數在1009后引后，所有混合組網的用戶，都建議把XBee3升級到1009之后的版本。
3、ET
在ZigBee 3.0中，子節點掛在父節點下的timeout時間可以自己申報，而不像以前一樣由父節點的休眠參數來決定。這樣會更靈活一些，在實際應用中，建議ET比休眠參數略大一些。
4、EO
在XBee3為了支持ZigBee 3.0的默認安全機制，參數中默認使用中心化的信任中心（EO=2），在S2C，默認是分布式的信任中心（EO=0). 在一個網絡中，EO的bit1必須相同，以便它們知道如何做密鑰交換。由于在S2C中，CE=1代表協調器，由它維護著集中式安全的網絡。在ZigBee 3.0引入了分布式網絡的概念，CE不再特指協調器。XBee3的Router為了加入之前S2C協調器維護的集中式網絡，應該使用EO=2，而非和S2C一樣配置為EO=0，該參數值在XBee3中無需更改。
5、DO
DO在S2C和XBee3有不同的定義，因此大多數情況下您無需更改它，使用默認值即可。
除了NJ參數外，其它一些參數默認值的不同也大多不會影響入網和通訊體驗。如果您的應用程序在初始化時寫入一些參數，請仔細檢查程序是否將不適用的S2C參數值寫入XBee3。
ZigBee 3.0在安全機制上做了一些修改。Digi為了保證和S2C老用戶有一樣的用戶體驗，在固件上做了一些適應。因此，在使用XBee3作為協調器的情況下，當有混合組網需求時，為了達到最好的向前兼容效果，需要使用100A以后的固件。
總結
以上是生活随笔為你收集整理的XBee3与XBee S2C混合应用注意事项（石油A11领域）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 数字化油田解决方案
- 下一篇： 测试用例模板（个人习惯使用）