1、系統主要設備
監控管理層主要設備：服務器、交換機、通信前置機、工作站
控制層設備：大型PLC、遠程IO、交換機
管理層和控制層之間的通信協議：modbus tcp
2、系統網絡結構
控制層通過PLC將數據上傳到管理層的通信前置機，管理層將數據處理後存儲並顯示。
3、問題現象
在管理層工作站報警記錄中控制層某些遠程IO站點會無規律的出現短暫的掉站報警。
4、故障分析過程
· 第一次故障分析
出現這種故障後首先懷疑的是控制層交換機組成的環網，到現場看了一下控制層交換機的日誌記錄，發現環網中大部分交換機的環網端口存在短時間內的'link up'、'link down'狀態切換。
但由於之前系統並沒有對控制層交換機校時，這種現象發生的時間和管理層報警時間無法對應，所以參考意義不大。
雖然在管理層工作站看到了相關報警，但到目前為止，還沒有確切的證據證明故障源就在控制層的設備，所以需要對故障進行捕捉記錄，分析故障源位置。
· 故障捕捉部署
首先，在控制層內設置交換機校時功能，確保在故障發生時交換機產生的日誌有參考意義。
其次，在PLC中添加故障點位記錄程序，當相關點位為報警狀態時，記錄報警次數和報警時間，可以和管理層報警記錄對比。
再次，在控制層的維護工作站上，添加相關點位的報警功能，輔助報警對比。
最後，在管理層通信前置機上打開通信報文記錄功能，記錄和控制層通信的所有報文，以便在發生報警時進行對比分析。
· 故障捕捉結果分析
經過2天時間記錄，又有幾次此類報警發生，到現場核對相關記錄，發現，控制層交換機、PLC、控制層維護工作站均無此故障記錄。
由此可以基本確定，問題存在於管理層於控制層的通信上，通過通信前置機的報文分析，發現報文確實存在問題。
問題1、前置機向PLC發送請求後未收到響應，重複3次無響應後，進行了下一包數據的請求，但這時連續收到了上面4次請求的響應數據。這說明，管理層和控制層之間存在較大的網絡延時，在這種控制系統中屬於不正常狀態。
問題2、通信前置機向PLC發送的請求報文中，事務處理標識符沒有變化，網絡延時同時收到4包回覆數據，導致數據錯亂。
問題3、在這兩天的記錄中控制層交換機沒再出現'link up'、'link down'狀態切換問題，初步判斷是調試時由於人為操作或設備掉的造成的問題，此問題暫不處理，待後續觀察。
5、解決問題
第一步，解決問題2中報文事務處理標識符的問題，確保數據正確。
第二部，檢查管理層交換機，查找網絡延時問題，確保數據的實時性。
6、其它啟發
1、多交流討論，廣大網友可以提供新思路。
2、大型控制系統的時間同步，並非都如電力輸送系統那麼高的精度要求，甚至不是業務邏輯上的需求。但系統內時間同步是非常必要的，至少在查看系統、設備故障日誌時，對排查故障提供極大的方便。
過年了，祝大家新年快樂！
閱讀更多 工控野人 的文章
