前幾天在一個碳素車間的智能天車無人化改造中遇到了如下問題：
網絡通訊正常但是ET200M IM153-4 Profinet IO遠程站無法實現和CPU315-2DP/PN的正常數據交換，IM153-4的BF指示燈一直紅色閃爍。經過對Profinet數據包分析最終實現了CPU和IM153-4的無線數據通訊。
首先對本項目做個簡單介紹，本項目旨在通過偉聯科技大功率高速WiFi模塊實現天車的自動行走，由於天車正常運行過程中需要往復行走，因此無法通過電纜實現地面狀態和控制信號向車輛上CPU的信號傳輸，地面設置2個IM153-4 系列IO站，每個站對應一臺天車；兩臺天車上分別安裝一套CPU315-2PN/DP和一個IM153-4系列IO站，每臺天車上設置一個WiFi的Client端，地面設置一個WiFi的AP端。詳細網絡圖如下：
上圖可以看到1號天車的CPU315帶了兩個IM153遠程站，一個是網線連接，一個是無線連接。同時還有一些變頻器。2號天車和1號天車同樣的配置。控制中心部署一臺工程師站，通過無線實現對車上PLC程序的上下載，同時WinCC監視兩輛大車的行走軌跡和運行狀態。地面控制中心和車輛高度差大約15米，我們在地面通過無線調試PLC省去了來回上下車輛的麻煩。
整個系統部署完成後我們發現地面可以正常對PLC程序進行上載，下載以及在線監視。Wincc也可以正常顯示車輛上的設備運行狀態，但是地面的編碼器以及車輛位置信號無法獲取到。
經過測試網絡延時均小於1ms，而且丟包率很低， 整個無線網絡Ping 30萬數據包基本沒有丟包，這是我們判斷西門子S7協議是正常的，因為PLC上下載和Wincc數據正常，那麼位置信號沒有隻有一個可能，地面的1號IO站和2號IO站數據沒有回到CPU。
這時我們 首先想到在地面測抓包進行分析，通過WireShark抓取5分鐘數據包，結果如下：
這是我們發現了一條 異常數據包，源地址為SIEMENS_8a:bd:e6,目的地址為PN-MC_00:00:00,協議為LLC； 我們知道目的MAC如果後三位為00，則改地址為組播地址。LLC不應該是802.2麼？通過對比我們發現所有SIEMENS的設備發出的LLDP_MultiCast（01：80：C2：00：00：0e）數據均是Ethernet II幀（參考第44條報文），協議類型為ProfiNet；唯有這條變成了一條802.3的幀（第43條）
繼續往下分析，我們可以判斷數據包中的 PN-PTCP為IO Device發出的組播包 ，這時我們猜測這條LLC的數據包為主站CPU發出。 為了驗證這個猜測，我們講天車停靠在離AP比較近的位置，拉一根網線講2號IO站連接到了2號天車的CPU櫃內交換機。我們繼續抓取數據包，結果如下：
對於一個搞工業通訊的人出現這個結果是非常興奮的，首先 同樣的源地址， 同樣的目的地址，協議由LLC變為了PN-DCP ，也就是說正常的報文是一條由主控制器下發的PN-DCP組播數據，但是經過無線傳輸後變成了一條LLC數據。 本是一條Ethernet II的Profinet數據幀，結果經過無線通訊後被識別為了802.3數據幀。感興趣的朋友可以自己查找802.3和Ethernet II數據幀的區別。
到這個節點我們把正常數據幀和異常數據幀進行對比
對比發現數據經過無線通訊後幀頭插入了一個長度字節 Length：58
而0x8892就變成了802.2 LLC的DSAP和SSAP，FEFE變成了LLC的控制域。
正常數據包幀頭為0x8892代表這條數據包是一個Profinet數據包，FEFE為ProfiNET RT的幀ID，FEFE代表這是一條DCP（Dynamic Configuration Protocol）數據包，緊跟著為ProfiNET組態中的站點名稱和端口號。Port 5922這個對西門子熟悉的工程師一定不陌生，這個就是ProfiNET網絡組態時的網絡端口。
最初我們認為造成這種現象的原因應該是 802.1d的限制，802.1d規定網橋必須過濾如下MAC地址：
MAC address Protocol
01-80-C2-00-00-00 Spanning Tree (STP/RSPT/MSTP)
01-80-C2-00-00-01 Ethernet Flow Control (pause frames)
01-80-C2-00-00-02 Link Aggregation Control Protocol (LACP)
01-80-C2-00-00-03 802.1X Port-Based Network Access Control
01-80-C2-00-00-08 Provider Bridge protocols (STP)
01-80-C2-00-00-0D Provider Bridge protocols (MVRP)
01-80-C2-00-00-0E 802.1AB Link Layer Discovery Protocol (LLDP)
而WIFI橋接剛好符合802.1d網橋的規定，使用上述MAC地址的協議，都會被網橋過濾掉，而最後一個地址01-80-C2-00-00-0E這個剛好就是SIEMENS的LLDP-MultiCast，也就是PN-PTCP。但是在下面這張圖中我們發現了SIEMENS_34:63:f5的這個地址，這個說明車上IO Device的數據通過無線正常發送到地面了。這也就說明了
LLDP數據包是可以通過無線網橋的。 第一種判讀排除。
組播也能傳送，LLDP數據也能經過無線傳到地面，那還有什麼原因會導致數據包發生變化呢？
根據以往經驗，我們將故障原因定位在了 無線網橋對組播數據的處理上。 ProfiNET IO協議將所有的實時數據全部封裝在了組播數據包內，因此我們將組播數據做了直通，啟用IGMPv3後，重新將無線模塊接回網絡，所有IO數據通訊均都正常。
本案重點難點在於通過無線實現ProfiNET IO的無線網絡數據傳輸，而且網絡內是四個ProfiNET IO Devices和兩個控制器實現數據交換，還有一點就是一個無線網絡內運行著兩個工業以太網協議，S7協議和ProfiNET協議。
最後也向大家證明了不是隻有SIEMENS的無線網橋才可以進行ProfiNET RT協議的無線傳輸。
閱讀更多 川哥工控界自媒體 的文章
