鎮海煉化三重整裝置UOP控制系統和DCS通訊調試總結
來源:用戶上傳
作者:
摘要：本文主要闡述了在鎮海煉化三重整裝置UOP控制系統更新項目中，如何調試和解決新系統與DCS系統之間的三個通訊問題。
關鍵詞：UOP;通訊;DCs;TRICON
原三重整裝置UOP控制系統已經使用近17年，電子設備老化嚴重，已發現卡件通道出現故障，只能通過短接處理，同時UOP公司已不提供技術支持服務，也不提供控制卡件等關鍵備件，一旦控制設備出現故障，將面臨沒有備件更換的地步，嚴重影響裝置的長周期穩定運行，經公司綜合考慮決定進行系統升級，期間三重黎裝置停止運行，歷時7天時間。本次檢修主要內容是對老控制系統進行拆除，調試新的控制系統。下面著重對新系統與DCS系統之間的三個通訊問題進行探討總結。
橫河DCS系統與UOP控制系統的串行通訊建立完成，通訊卡的運行狀態正常。但是在通訊測試中，發現模擬量輸入瀆到DCS后顯示為“零”問題與模擬量輸出不能寫入TRICON的問題，同時由于UOP組態沒置問題，UOP公司提供的通訊點清單中通訊所需的量程類型較多而且混亂，數據轉換過程中每一個模擬量DCS -側都需要設置不同的轉換系數，而且清單中部分位號量程有誤，導致數據轉換不正確，DCS側需對每一個模擬參數進行數據轉換，通訊速率較慢，大數據量通訊時，延時最長達16秒。由于UOP服務人員無權修改程序，這些通訊不正常的問題我們已向UOP工程師提出，后面他們會再發一份修改過的通訊清單給我們。待總部修改程序后才能進行下裝調試，DCS廠家與UOP正在查找通訊偏慢的原因，等新程序到位后，下一步還將進行下裝和測試。因為工藝平時操作大都通過DCS完成，考慮到通訊偏慢的問題，無法滿足工藝的要求，日前DCS寫入LHCS的信號延遲時間太長工豈方面是無法接受的，特別是原來YS80控制的3個壓差調節器，如果調節速度太慢，甚至可能會導致閉鎖料斗的熱停車。我們提出了一個備用方案，新UOP控制系統有兩臺操作站，一用一備，我們將備用的操作站移至中控室的工程師站，以防萬一通訊問題解決不了時使用。在機柜間及中控室各安裝一個光電轉換器，操作站的以太網通訊線路利用以前的三重整DCS備用通訊光纖。
由于之前發現DCS與UOP控制系統通訊偏慢的現象，我們要求UOP服務人員繼續到儀表控制部CRT中心進行通訊調試，經過雙方兩天的努力，終于解決了一系列通訊問題。
1模擬量輸入讀到DCS后顯示為“零”問題
測試位號“PDIC406一SP”，由UOP 工程師在TRICON操作站上改變“PDIC406”的SP值，在DCS側讀到的數值與設定值不能對應且不會改變，但DCS通訊卡狀態指示燈正常，無系統報警。經仔細核對發現UOP提供的量程與實際有出人，應該為“0-5kPa”，而在提供的資料上卻寫成“0-500mmH2O”，同時UOP 工程師確定必須嚴格按表格中“Raw Range”一欄進行量程轉換后，才能顯示正確數值。修改橫河通訊組態后，指示正常，再次與UOP 工程師核對所有模擬量數據，確認量程及“Raw Range”轉換范圍。
2模擬量輸出不能寫入TRICON的問題
測試位號“PDIC406一SP DCS”，按模擬量輸入通訊調試經驗與UOP 工程師討論，確認所有模擬輸出信號也必須進行相應量程轉換，前期DCS組態對模擬量輸出信號并沒有進行轉換處理，所以數值無法寫入TRICON系統。修改橫河通訊組態后，可以正常寫入TRICON系統。
3 UOP與橫河DCS通訊速度慢的問題
用秒表計時，分別測試開關量和模擬量讀人DCS速度，測試結果與前期基本一致，通訊時間在12-18秒之間;測試開關量和模擬量寫入TRICON速度，先由UOP 工程師配合在TRICON1131組態軟件中增加MODBUS通訊寄存器地址監控表，然后由DCS改變相應數值寫入TRICON，直接讀取TRICON通訊寄存器中數值，DCS寫入TRICON時間在11-16秒之間。
檢查各通訊接口和電纜，確認接線端子連接緊密，觀察通訊卡件狀態燈情況未發現明顯問題。更換DCS的ALR121通訊卡做試驗，速度慢問題仍在。采用筆記本電腦加USB-RS422/485通訊適配器與TRICON系統通訊，讀入125個模擬量寄存器時間只需1秒，連續測試5分鐘未發現異常，說明TRICON系統收發通訊數據包是正常的。
清空DCS與TRICON通訊的所有組態，只在DCS增加TRICON系統時間通訊地址，共6個模擬量寄存器，分別為年、月、日、時、分、秒，DCS修改并下載后，監視這6個數值，發現“秒”的變化速率較快，基本上1秒鐘就能改變1次，但比TRICON系統時間中的秒數一直慢4秒，說明通訊數據包減少有助于提高通訊速度，而一直有個時間差則可能是“全雙工”收發速率不一致造成的。
原通訊設置采用19200bps，even/8/1，RS485/4-Wire（全雙工）模式，采用“全雙工”模式工作時，收和發分別使用獨立電纜進行，互不干擾，如果通訊雙方不能互相協調一致，會引起收和發不同步現象，從上面一直慢4秒現象來看，應該能確定DCS和TRICON通訊卡之間存在不匹配現象。經與UOP工程師協商，對方也同意通訊設置有問題的判斷，決定明天修改通訊設置，將速率降低至9600bps，并將4-Wire（全雙工）改為2-Wire（半雙工）通訊，9600 bps速率每秒可以傳送480多個字，而目前UOP與DCS之間通訊數據不到200字，9600bps速率足夠使用。
第二天UOP 工程師對Tricon系統通訊參數進行修改，并重新確認通訊電纜接線方法，橫河工程師對DCS系統通訊參數進行修改下載，并按UOP提供的接線方法重新連接ALR121卡上通訊電纜。雙方完成后，用秒表測試從DCS寫入到TRICON的速度，第1次只用了2秒，但之后系統出現ALR121卡中斷報警，幾秒后自動恢復，然后每隔10-20秒ALR121卡通訊中斷報警后自動恢復，寫入速度也隨通訊中斷變化而變化，最快能達到5秒，最慢要18秒。
將所有通訊參數和接線恢復到修改前，重啟TRICON系統，插拔ALR121通訊卡，完成后再次測試，ALR121通訊中斷報警仍然存在，說明該現象不是因通訊參數修改引起，前期測試時也出現過該問題，只是在昨天通訊調試中未出現而已。針對該中斷現象分析認為，通訊參數設置仍是關鍵點，TRICON通訊卡的掃描及處理能力較快，橫河DCS較慢，通訊雙方協調機制不匹配，可能出現DCS發出請求（ request）指令，而TRICON通訊卡無應答（response）狀況，最終導致通訊中斷的表象。
重新將通訊參數設置成9600bps/2-Wire模式，因通訊中斷時間為10-20秒，也就是說發生無應答現象，最長間隔是20秒鐘，將DCS的“Response Timeout”加長到30秒，原采用默認時間“4 sec（秒）”，TRICON系統只要在30秒內對DCS請求作出應答，通訊就不會出錯，修改后完成后測試，中斷現象消失，且通訊讀寫速率穩定在7秒左右。
繼續查找通訊慢問題，發現TRICON的通訊卡在半雙工模式下要求有“HandShake“握手信號，而橫河DCS通訊參數中未找到相同參數，但有“InLer-Character Time-OutValue（數據包結束特殊字長度）”即當1個數據包結束后插入N個間隔字表示該數據包已發完，下個數據包還未開始發送，這個參數定義與“HandShake”握手信號基本一致，原DCS采用默認沒置“1000 msec（毫秒）”，與DCS的掃描周期相一致，而TRICON系統掃描周期設置為“200msec”，將此參數修改成“200 msec”與TRICON的掃描周期相一致，下載后測試，通訊讀寫速率達到1秒，通訊速度慢問題徹底解決。
通訊問題解決后，我們對DCS與UOP之間的370通訊點進行逐一測試，為整個系統的更新順利完成打下基礎。
參考文獻：
[1] Process Inforrnation and Control （contro systems for processcontrol）UOP.
轉載注明來源:http://www.hailuomaifang.com/1/view-14910777.htm
