日本在线www-日本在线播放一区-日本在线不卡免费视频一区-日本在线不卡视频-成人影院久久久久久影院-成人影院一区二区三区

    朱亞清：廣東省電力試驗研究所

    廣東韶關發電廠8號200MW機組的DCS和DEH改造，DCS采用西屋公司的OVATION分散控制系統，DEH采用新華公司的由XDPS 400分散控制系統組成的DEH―ⅢA。在改造設計中，DEH系統配備工程師站和歷史站各一臺，沒有專用的操作員站。DEH系統采用與DCS系統共享操作員站的方案，通過通訊的方法，實現在DCS的操作員站上對DEH系統進行全部監控的功能。

    1  DEH與DCS通訊原理

    如圖1所示，DEH側的工程師站和歷史站同時兼作通訊站，其第3塊網卡通過RJ45通訊電纜與DCS側的1、2號FDDI（光纖分布數據接口）交換機連接起來，實現與DCS側的07、57號控制器（Drop07、Drop57）通訊。通訊協議采用TCP/IP上的MODBUS，DEH側為從站（SLAVE），DCS側為主站（MASTER）。

圖1 DEH與DCS通訊結構圖

    DEH側運行新華公司開發的“Hbgtw.exe”程序與OVATION系統進行通訊，該程序當初是新華公司為XDPS400系統與H&B公司的CONTRONIC DCS系統通訊而開發的，后來成為新華公司的XDPS400系統與其它系統進行通訊的一部份，并且與多個DCS系統通訊取得了成功。

    DCS側利用OVATION系統的虛擬IO（Input & Output）設備與DEH系統進行通訊，虛擬IO設備是OVATION系統集成的與第三方系統通訊的功能，利用虛擬IO設備，OVATION可以直接與AB PLC、MODBUS PLC、GE Mark Ⅴ/Ⅵ、RTP I/O等第三方系統進行通訊。在本工程中，將DEH系統虛擬為OVATION系統的MODBUS PLC設備，實現與DEH系統的通訊。

    2  DEH與DCS通訊存在的問題

    2.1 DCS無法正常向DEH發送操作指令

    新華公司的XDPS400系統采用“HBGTW.EXE”程序與H&B公司的CONTRONIC、ABB BAILEY的SYMPHENY等系統進行通訊都取得了成功，但與OVATION系統通訊還是第一次。
在韶關電廠8號機組改造中，DEH與DCS通訊一開始調試時，就發現雖然DEH側的數據可以正確送到DCS系統，但是DCS無法對DEH進行正常操作，而且當通訊程序啟動后，DEH的所有操作塊每秒周期地被操作一次，造成DEH系統出現混亂。

    新華公司的“HBGTW.EXE”程序當初是為實現DEH與DCS共享操作員站而設計開發的，其設計的當初是與DCS的操作員站進行通訊，“HBGTW.EXE”程序用MODBUS功能號2、4完成向DCS傳送開關量和模擬量數據、用MODBUS功能號5、6完成DCS對DEH系統進行的脈沖和置數操作。在通訊過程中，主站（MASTER）DCS周期地向從站（SLAVE）DEH發送MODBUS功能號2、4消息，DEH回應主站的號2、4消息，從而實現DEH側數據傳送到DCS側；當DCS側要對DEH進行脈沖或置數操作時，主站DCS向從站DEH發送MODBUS 2號或4號息消，DEH收到主站的2、4號消息后，向DPU（Distributed Process Unit）發送操作指令信號，就象運行人員在DEH操作員站對DEH進行操作一樣，從而實現DEH與DCS共享操作站。

    在本工程中，DEH是與OVATION系統的控制器通訊，而不是操作員站。OVATION控制器用MODBUS功能號5、6向DEH傳送的不是操作指令，而是開關量和模擬量信號，而且是周期地傳送的。由于DCS與DEH兩系統對MODBUS功能號5、6消息的解釋不同，DEH每收到一條MODBUS功能號5或6消息，DEH系統就對其DPU進行一次操作，造成每個通訊周期DEH都要對其DPU進行一次脈沖和置數操作，引起DEH系統混亂。

    2.2  通訊無法實現冗余

    通訊設計時，DCS側的07號控制器與DEH的工程站通訊，DCS側的57號控制器與DEH的歷史站通訊。DEH側的工程師站和歷史站在通訊上是相互冗余來設計的，任一個站與DCS通訊正常都能保證DEH與DCS兩系統間的通訊正常。

    DCS側的07、57號控制器作為冗余而配置的控制器，采用一用一備的工作方式，當07號控制器為主時，57號控制器備用，反之，當57號控制器為主時，07號控制器備用。處于備用方式的控制器跟蹤主控制器，其本身并不進行IO掃描運算，因此，處于備用方式的控制器并不會與DEH進行通訊，而處于主工作方式的控制器只與DEH的其中一個站進行通訊，當這路通訊線路故障或DEH側正在通訊的站出現故障或關閉時，雖然DCS與DEH的另一路通訊回路正常，但DCS主控制器并不會切換到與DEH側的另一臺站進行通訊，DCS的主/備控制器也不會自動切換，造成DCS與DEH的通訊失去。
可見，雖然設計了兩個通訊回路，但由于通訊是一對一的方式，一路通訊中斷后無法自動切換到另一路通訊上，兩個通訊回路無法真正實現相互冗余的功能。

    3  DEH與DCS通訊問題解決

    3.1 DCS無法正常向DEH發送操作指令的解決

    從上面的分析可以得知，DCS無法向DEH發送操作指令的原因是DCS向DEH傳送的不是操作指令，而是開關量和模擬信號。要解決DCS不能對DEH進行正常操作的問題，理論上分析可有兩種解決方案。

    第一種是對DCS側的通訊設置進行修改，使DCS向DEH發送的不是開關量和模擬信號，而是操作指令，即DCS側只有運行人員對DEH進行開關量或模擬量置數操作時，才向DEH發送MODBUS功能5或6號消息。采用這個方案的好處是通訊實時性較好，通訊負擔也較小，但DCS側的OVATION系統是采用虛擬IO設備與DEH進行通訊，虛擬IO設備是OVATION系統集成的功能，我們可能無法對OVATION系統進行修改。

    第二種是對DEH側進行修改，使DEH收到DCS傳送來的數據時，不是直接對DPU進行操作，而是將數據送到DPU進行邏輯判斷，判斷出DCS需要對DEH進行操作時，再通過邏輯處理的方法對DPU進行操作。這種方案，DCS側對DEH進行操作時，操作指令先送到DCS的控制器，由控制器進行邏輯處理后再以IO輸出方式通訊到DEH側，DEH收到后再經過邏輯處理才進行操作。可見，在DCS側進行操作后，至少要經過DCS和DEH各一個邏輯掃描周期后，DEH才進行操作，操作實時性較第一種方案差。DEH側的通訊程序為新華公司開發，新華公司的研發人員可以很容易對通訊程序進行修改。當第一種方案無法實施時，只能采用這種方案了。

    通過對OVATION系統資料的查閱和廠家的確認，我們無法對OVATION系統進行修改，最后決定采用第二種方案進行實施。修改DEH側的通訊程序，增加接收MODBUS 15和16功能碼消息來實現接收開關量和模擬量數據。當通訊傳送的是開關量或模擬量數據而不是操作指令時，采用MODBUS功能號5和6則效率太低，因為MODBUS功能號5或6號的每一個通訊數據包只能包含一個開關量或一個模擬量，而MODBUS功能號15和16則不同，每一個通訊數據包可以包含多個開關量和多個模擬量。因此，當通訊傳送的是多個開關量或模擬量數據時，采用MODBUS 15或16號功能碼更為合適。

    要使OVATION系統采用MODBUS功能號15和16傳遞數據，只需修改相關的通訊點的“I/O ACCESS PATH”的設置即可，如I/O ACCESS PATH 為“MODBUS 1 OUT 16001 PLC_1”表示OVATION系統的PLC_1虛擬設備采用MODBUS功能號5向1號從站的MODBUS地址6000傳送開關量，改為“MODBUS 1 OUT 6001 PLC_1”則為采用MODBUS功能號15來傳遞；再如“MODBUS 1 OUT 36001 PLC_1”表示OVATION系統的PLC_1虛擬設備采用MODBUS功能號6向1號從站的
MODBUS地址6000傳送模擬量，改為“MODBUS 1 OUT 46001 PLC_1”則為采用MODBUS功能號16來傳遞。

    要實現DCS側能夠操作DEH，DCS側和DEH側的邏輯都要作相應的修改。對于開關量的脈沖操作，DCS側操作時，只需向DEH發送一個脈沖信號，DEH將DCS發送來的脈沖信號與其自身的操作進行“相或”運算即可；對于模擬量置數操作，還要在DCS側為每一個置數操作增加一路開關量信號，這個開關量信號作為“模擬量置數操作的有效”信號，當在DCS側進行模擬量置數時，除了將模擬量數據傳送到DEH外，同時將相應的“置數操作的有效”信號以一個脈沖發送到DEH側，DEH通過判斷“置數操作的有效”信號進行相應的置數操作。DEH相應的邏輯處理如圖2、圖3所示。

圖2 DCS對DEH進行開關量操作的DEH邏輯(虛線部分為增加)

圖3 DCS對DEH進行模擬量置數操作的DEH邏輯(虛線部分為增加)

     3.2  通訊冗余的實現

    DEH的兩臺操作員站和DCS的DROP07、DROP57對其各自系統來說已經是冗余的，若能實現DCS與DEH之間既能一對一通訊，又能交叉通訊，也就能實現DEH與DCS通訊冗余了。DEH側的兩臺交換機采用光纖連接起來，實現了兩個交換機之間相互通訊連接的功能，已實現了DCS側DROP07、DROP57與DEH工程師站、歷史站之間的硬件交叉連接。在DEH與DCS的通訊中，DEH為從站，既可接受DCS側DROP07的連接請求，也可接受DROP57的連接請求；而DCS為主站，處于主動地位，因此，要實現交叉通訊，必須從DCS側的OVATION系統著手進行修改。

    經過對OVATION系統資料的查閱和廠家的確認，OVATION系統這種通過虛擬IO設備與第三方進行通訊是不具備冗余功能的，必須另想辦法才能實現通訊的冗余。最后我們采用增加一路虛擬IO設備的方法，成功實現了通訊冗余功能。

    OVATION系統共有5個設備號（DEVICE）可用，而每個設備號最多又可帶5路虛擬設備，原通訊設計Drop07和Drop57均采用了第三個設備號（DEVICE#3）的第一路虛擬IO設備PLC_1。為此，我們在DEVICE#3上再增加一路虛擬IO設備PLC_2，并設置使其與DEH另一臺通訊站進行通訊，從而實現DCS同時與DEH兩臺通訊站進行通訊。當Drop07為主時，其虛擬IO設備PLC_1與DEH的工程師站通訊、PLC_2與DEH的歷史站通訊；反之，當Drop57為主時，其虛擬IO設備PLC_1與DEH的歷史站通訊、PLC_2與DEH的工程師站通訊。

    DCS采用兩路虛擬IO設備與DEH進行通訊，信號的處理與采用兩塊真實IO卡與DEH進行連接的處理是相似的。DCS發送數據到DEH時，將數據同時送到兩路虛擬IO設備，兩路通訊將數據同時送到DEH的兩臺通訊站，DEH只要保證其中一臺通訊站正確收到數據，DEH就能正確收到DCS發送來的數據；DCS接收DEH數據時，對兩路通訊來的數據進行“2選1”邏輯處理，當兩路通訊均正常時，取其中一路數據，當有一路通訊不正常時，取正常的那一路數據。這樣，就實現了DCS與DEH的冗余通訊功能。

    4  結語

    經過這次改造后，成功實現了DEH與DCS的通訊，并采用雙回路實現了冗余通訊功能。正常運行時，兩個通訊回路同時工作，兩路通訊相互冗余，相互熱備用，只要保證有一路或以上的通訊正常時，就能保證DEH與DCS系統通訊的正常，這就大大提高了機組的安全可靠性。這種采用兩個通訊回路來實現通訊冗余的方法，兩個通訊回路相互熱備用，具有較高的可靠性，對于其它系統的通訊冗余設計也有很大的參考價值。