次分享的內容是我在某制藥廠進行網絡診斷的分析過程。該制藥廠控制系統是使用西門子的PCS7；控制系統的網絡是由2個OSM TP62和6個SCALANCE X200系列交換機組成的光纖環網，其中的1個OSM TP62作為環網管理器。

系統的數據歸檔服務器系統采用的是PI系統軟件（經過了FDA認證的軟件），此系統軟件通過KEPSERVER（專業的OPC Server）的S7驅動協議與西門子的8個S7-400 PLC實現數據通信如下圖1所示。

圖1

客戶現場的問題是當341車間斷電時（交換機和PLC都斷電）如下圖2所示， 在PI系統上監視到其與各個PLC發給PI系統的通信心跳檢測出現異常（正?？吹降男奶且? 遞增；異常時會出現不是以1遞增）如下圖3所示，且有時會在431車間產生PI系統發給431車間的PLC的心跳檢測超出設定時間15S的報警信息如下圖4所示?？蛻魬岩煽赡苡捎诰W絡的問題導致上述的情況的出現。認為網絡出現中斷的現象使得一些心跳數值得丟失。

圖4

根據問題描述判斷產生的原因有以下幾種可能：

網絡拓撲結構的變化使網絡出現了問題，如環網管理出現了不正常等造成了通信的異常。

KEPSERVER OPC服務器的S7驅動在網絡結構發生變化時出現了異常

PI系統的OPC 客戶端與KEPSERVER OPC服務器之間的通信出現了異常導致問題的產生。網絡中接入了新的設備，且此新設備的IP地址與KEPSERVER OPC服務器產生沖突導致了與所有PLC站的通信的時通時段

根據上面的分析判斷與用戶進行了溝通，用戶給出的答案是上面的第三和第四是沒有可能的。原因是PI系統的專家遠程診斷了PI與KEPSERVER OPC服務器之間的通信，結果是沒有出現任何異?，F象。當321車間斷電時，網絡也沒有接入任何新的設備。所以只可能的是第一條和第二條中的原因。

為了確認確切的故障原因讓用戶再次斷321車間的電，看是否問題能重新浮現。當321車間斷電后，故障現象確實能再次浮現。更進一步的排除了第三條與第四條造成問題的可能性。

那么第一條與第二條中究竟是哪一條導致的故障現象？于是我們在KEPSERVER OPC服務器的出口和331車間的PLC的出口上接入了TAP（網絡分析工具）進行抓包。如下圖5所示。圖中KEPSERVER OPC服務器的IP地址為192.168.0.20/24；331車間PLC的IP地址為192.168.0.4/24。

圖5

在KEPSERVER OPC服務器的出口處抓包后分析發現，斷電前與斷電后數據包的發送間隔會出現變化，在斷電前數據包的發送間隔為1s左右，而斷電后數據的發送間隔在某個時刻會變為7－10s左右，如圖6和圖7所示。但從這里只能說明數據包的發送出了問題，沒有足夠的證據能夠說明是KEPSERVER OPC服務器的S7驅動的問題，而不是網絡的問題。

圖6　斷電前的數據包發送情況

圖7 斷電后的數據包發送情況

為了更進一步的確認問題的原因，于是在現場斷開321車間的OSM TP62的所有的光纖如下圖8所示

圖8

斷開后發現PI系統監視到321車間發來的心跳檢測仍然異常，此時把321車間的OSM TP62換為SCALANE X204-2交換機后心跳檢測仍然異常，這樣判斷不是交換機網絡引起的問題。為了更好的說明問題，把321車間的一端的光纖斷開，另一端的光纖保持連接狀態如圖9所示，此時在PI系統上監視到321車間發來的心跳檢測為正常，更進步說明了與網絡無關。

圖9

此時已基本確定是KEPSERVER OPC服務器的S7驅動的問題導致了故障現象。為了讓客戶能確認，我們又做了一個測試，環網保持正常的連接斷開231車間PLC與SCALANCE X200的以太網雙絞線如圖10所示。斷開后發現心跳檢測出現了異常，在此基礎上繼續斷開241車間PLC與SCALANCE X200的以太網雙絞線，發現異?，F象更為嚴重。

圖10

造成問題的原因找到了，但為什么會出現此現象，我們查看了KEPSERVER OPC服務器的設置，在通訊通道的設置中有一項是當KEPSERVER OPC服務器與下面的PLC通信時，當連接不能建立時有重新請求的機制，這會造成延時。如圖11所示。而KEPSERVER OPC服務器對所有的站采用的是輪訓機制。一個PLC站點造成的延時會影響其后站的數據刷新。這也就是為什么當有PLC出現掉站，系統就會出現用戶所描述的問題。

圖11

Zui終處理的方式是更換KEPSERVER 的OPC服務器為西門子的SIMATIC Net的OPC服務器，SIMATIC Net的OPC服務器采用的不是輪訓機制，所有的站都是并行發送數據，一個站點的掉站是不會影響其它的站。