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設備等。通??梢栽诓渴鹉J诫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领域)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 数字化油田解决方案
- 下一篇: 测试用例模板(个人习惯使用)