廣東韶關(guān)發(fā)電廠8號200MW機組的DCS和DEH改造，DCS采用西屋公司的OVATION分散控制系統(tǒng)，DEH采用新華公司的由XDPS 400分散控制系統(tǒng)組成的DEH―ⅢA。在改造設計中，DEH系統(tǒng)配備工程師站和歷史站各一臺，沒有專用的操作員站。DEH系統(tǒng)采用與DCS系統(tǒng)共享操作員站的方案，通過通訊的方法，實現(xiàn)在DCS的操作員站上對DEH系統(tǒng)進行全部監(jiān)控的功能。 1 DEH與DCS通訊原理 如圖1所示，DEH側(cè)的工程師站和歷史站同時兼作通訊站，其第3塊網(wǎng)卡通過RJ45通訊電纜與DCS側(cè)的1、2號FDDI（光纖分布數(shù)據(jù)接口）交換機連接起來，實現(xiàn)與DCS側(cè)的07、57號控制器（Drop07、Drop57）通訊。通訊協(xié)議采用TCP/IP上的MODBUS，DEH側(cè)為從站（SLAVE），DCS側(cè)為主站（MASTER）。 [align=center] 圖1 DEH與DCS通訊結(jié)構(gòu)圖[/align] DEH側(cè)運行新華公司開發(fā)的“Hbgtw.exe”程序與OVATION系統(tǒng)進行通訊，該程序當初是新華公司為XDPS400系統(tǒng)與H&B公司的CONTRONIC DCS系統(tǒng)通訊而開發(fā)的，后來成為新華公司的XDPS400系統(tǒng)與其它系統(tǒng)進行通訊的一部份，并且與多個DCS系統(tǒng)通訊取得了成功。 DCS側(cè)利用OVATION系統(tǒng)的虛擬IO（Input & Output）設備與DEH系統(tǒng)進行通訊，虛擬IO設備是OVATION系統(tǒng)集成的與第三方系統(tǒng)通訊的功能，利用虛擬IO設備，OVATION可以直接與AB PLC、MODBUS PLC、GE Mark Ⅴ/Ⅵ、RTP I/O等第三方系統(tǒng)進行通訊。在本工程中，將DEH系統(tǒng)虛擬為OVATION系統(tǒng)的MODBUS PLC設備，實現(xiàn)與DEH系統(tǒng)的通訊。 2 DEH與DCS通訊存在的問題 2.1 DCS無法正常向DEH發(fā)送操作指令 新華公司的XDPS400系統(tǒng)采用“HBGTW.EXE”程序與H&B公司的CONTRONIC、ABB BAILEY的SYMPHENY等系統(tǒng)進行通訊都取得了成功，但與OVATION系統(tǒng)通訊還是第一次。 在韶關(guān)電廠8號機組改造中，DEH與DCS通訊一開始調(diào)試時，就發(fā)現(xiàn)雖然DEH側(cè)的數(shù)據(jù)可以正確送到DCS系統(tǒng)，但是DCS無法對DEH進行正常操作，而且當通訊程序啟動后，DEH的所有操作塊每秒周期地被操作一次，造成DEH系統(tǒng)出現(xiàn)混亂。 新華公司的“HBGTW.EXE”程序當初是為實現(xiàn)DEH與DCS共享操作員站而設計開發(fā)的，其設計的當初是與DCS的操作員站進行通訊，“HBGTW.EXE”程序用MODBUS功能號2、4完成向DCS傳送開關(guān)量和模擬量數(shù)據(jù)、用MODBUS功能號5、6完成DCS對DEH系統(tǒng)進行的脈沖和置數(shù)操作。在通訊過程中，主站（MASTER）DCS周期地向從站（SLAVE）DEH發(fā)送MODBUS功能號2、4消息，DEH回應主站的號2、4消息，從而實現(xiàn)DEH側(cè)數(shù)據(jù)傳送到DCS側(cè)；當DCS側(cè)要對DEH進行脈沖或置數(shù)操作時，主站DCS向從站DEH發(fā)送MODBUS 2號或4號息消，DEH收到主站的2、4號消息后，向DPU（Distributed Process Unit）發(fā)送操作指令信號，就象運行人員在DEH操作員站對DEH進行操作一樣，從而實現(xiàn)DEH與DCS共享操作站。 在本工程中，DEH是與OVATION系統(tǒng)的控制器通訊，而不是操作員站。OVATION控制器用MODBUS功能號5、6向DEH傳送的不是操作指令，而是開關(guān)量和模擬量信號，而且是周期地傳送的。由于DCS與DEH兩系統(tǒng)對MODBUS功能號5、6消息的解釋不同，DEH每收到一條MODBUS功能號5或6消息，DEH系統(tǒng)就對其DPU進行一次操作，造成每個通訊周期DEH都要對其DPU進行一次脈沖和置數(shù)操作，引起DEH系統(tǒng)混亂。 2.2 通訊無法實現(xiàn)冗余 通訊設計時，DCS側(cè)的07號控制器與DEH的工程站通訊，DCS側(cè)的57號控制器與DEH的歷史站通訊。DEH側(cè)的工程師站和歷史站在通訊上是相互冗余來設計的，任一個站與DCS通訊正常都能保證DEH與DCS兩系統(tǒng)間的通訊正常。 DCS側(cè)的07、57號控制器作為冗余而配置的控制器，采用一用一備的工作方式，當07號控制器為主時，57號控制器備用，反之，當57號控制器為主時，07號控制器備用。處于備用方式的控制器跟蹤主控制器，其本身并不進行IO掃描運算，因此，處于備用方式的控制器并不會與DEH進行通訊，而處于主工作方式的控制器只與DEH的其中一個站進行通訊，當這路通訊線路故障或DEH側(cè)正在通訊的站出現(xiàn)故障或關(guān)閉時，雖然DCS與DEH的另一路通訊回路正常，但DCS主控制器并不會切換到與DEH側(cè)的另一臺站進行通訊，DCS的主/備控制器也不會自動切換，造成DCS與DEH的通訊失去。 可見，雖然設計了兩個通訊回路，但由于通訊是一對一的方式，一路通訊中斷后無法自動切換到另一路通訊上，兩個通訊回路無法真正實現(xiàn)相互冗余的功能。 3 DEH與DCS通訊問題解決 3.1 DCS無法正常向DEH發(fā)送操作指令的解決 從上面的分析可以得知，DCS無法向DEH發(fā)送操作指令的原因是DCS向DEH傳送的不是操作指令，而是開關(guān)量和模擬信號。要解決DCS不能對DEH進行正常操作的問題，理論上分析可有兩種解決方案。 第一種是對DCS側(cè)的通訊設置進行修改，使DCS向DEH發(fā)送的不是開關(guān)量和模擬信號，而是操作指令，即DCS側(cè)只有運行人員對DEH進行開關(guān)量或模擬量置數(shù)操作時，才向DEH發(fā)送MODBUS功能5或6號消息。采用這個方案的好處是通訊實時性較好，通訊負擔也較小，但DCS側(cè)的OVATION系統(tǒng)是采用虛擬IO設備與DEH進行通訊，虛擬IO設備是OVATION系統(tǒng)集成的功能，我們可能無法對OVATION系統(tǒng)進行修改。 第二種是對DEH側(cè)進行修改，使DEH收到DCS傳送來的數(shù)據(jù)時，不是直接對DPU進行操作，而是將數(shù)據(jù)送到DPU進行邏輯判斷，判斷出DCS需要對DEH進行操作時，再通過邏輯處理的方法對DPU進行操作。這種方案，DCS側(cè)對DEH進行操作時，操作指令先送到DCS的控制器，由控制器進行邏輯處理后再以IO輸出方式通訊到DEH側(cè)，DEH收到后再經(jīng)過邏輯處理才進行操作?？梢?，在DCS側(cè)進行操作后，至少要經(jīng)過DCS和DEH各一個邏輯掃描周期后，DEH才進行操作，操作實時性較第一種方案差。DEH側(cè)的通訊程序為新華公司開發(fā)，新華公司的研發(fā)人員可以很容易對通訊程序進行修改。當?shù)谝环N方案無法實施時，只能采用這種方案了。 通過對OVATION系統(tǒng)資料的查閱和廠家的確認，我們無法對OVATION系統(tǒng)進行修改，最后決定采用第二種方案進行實施。修改DEH側(cè)的通訊程序，增加接收MODBUS 15和16功能碼消息來實現(xiàn)接收開關(guān)量和模擬量數(shù)據(jù)。當通訊傳送的是開關(guān)量或模擬量數(shù)據(jù)而不是操作指令時，采用MODBUS功能號5和6則效率太低，因為MODBUS功能號5或6號的每一個通訊數(shù)據(jù)包只能包含一個開關(guān)量或一個模擬量，而MODBUS功能號15和16則不同，每一個通訊數(shù)據(jù)包可以包含多個開關(guān)量和多個模擬量。因此，當通訊傳送的是多個開關(guān)量或模擬量數(shù)據(jù)時，采用MODBUS 15或16號功能碼更為合適。 要使OVATION系統(tǒng)采用MODBUS功能號15和16傳遞數(shù)據(jù)，只需修改相關(guān)的通訊點的“I/O ACCESS PATH”的設置即可，如I/O ACCESS PATH 為“MODBUS 1 OUT 16001 PLC_1”表示OVATION系統(tǒng)的PLC_1虛擬設備采用MODBUS功能號5向1號從站的MODBUS地址6000傳送開關(guān)量，改為“MODBUS 1 OUT 6001 PLC_1”則為采用MODBUS功能號15來傳遞；再如“MODBUS 1 OUT 36001 PLC_1”表示OVATION系統(tǒng)的PLC_1虛擬設備采用MODBUS功能號6向1號從站的MODBUS地址6000傳送模擬量，改為“MODBUS 1 OUT 46001 PLC_1”則為采用MODBUS功能號16來傳遞。 要實現(xiàn)DCS側(cè)能夠操作DEH，DCS側(cè)和DEH側(cè)的邏輯都要作相應的修改。對于開關(guān)量的脈沖操作，DCS側(cè)操作時，只需向DEH發(fā)送一個脈沖信號，DEH將DCS發(fā)送來的脈沖信號與其自身的操作進行“相或”運算即可；對于模擬量置數(shù)操作，還要在DCS側(cè)為每一個置數(shù)操作增加一路開關(guān)量信號，這個開關(guān)量信號作為“模擬量置數(shù)操作的有效”信號，當在DCS側(cè)進行模擬量置數(shù)時，除了將模擬量數(shù)據(jù)傳送到DEH外，同時將相應的“置數(shù)操作的有效”信號以一個脈沖發(fā)送到DEH側(cè)，DEH通過判斷“置數(shù)操作的有效”信號進行相應的置數(shù)操作。DEH相應的邏輯處理如圖2、圖3所示。 [align=center] 圖2 DCS對DEH進行開關(guān)量操作的DEH邏輯（虛線部分為增加）[/align] [align=center] 圖3 DCS對DEH進行模擬量置數(shù)操作的DEH邏輯（虛線部分為增加）[/align] 3.2 通訊冗余的實現(xiàn) DEH的兩臺操作員站和DCS的DROP07、DROP57對其各自系統(tǒng)來說已經(jīng)是冗余的，若能實現(xiàn)DCS與DEH之間既能一對一通訊，又能交叉通訊，也就能實現(xiàn)DEH與DCS通訊冗余了。DEH側(cè)的兩臺交換機采用光纖連接起來，實現(xiàn)了兩個交換機之間相互通訊連接的功能，已實現(xiàn)了DCS側(cè)DROP07、DROP57與DEH工程師站、歷史站之間的硬件交叉連接。在DEH與DCS的通訊中，DEH為從站，既可接受DCS側(cè)DROP07的連接請求，也可接受DROP57的連接請求；而DCS為主站，處于主動地位，因此，要實現(xiàn)交叉通訊，必須從DCS側(cè)的OVATION系統(tǒng)著手進行修改。 經(jīng)過對OVATION系統(tǒng)資料的查閱和廠家的確認，OVATION系統(tǒng)這種通過虛擬IO設備與第三方進行通訊是不具備冗余功能的，必須另想辦法才能實現(xiàn)通訊的冗余。最后我們采用增加一路虛擬IO設備的方法，成功實現(xiàn)了通訊冗余功能。 OVATION系統(tǒng)共有5個設備號（DEVICE）可用，而每個設備號最多又可帶5路虛擬設備，原通訊設計Drop07和Drop57均采用了第三個設備號（DEVICE#3）的第一路虛擬IO設備PLC_1。為此，我們在DEVICE#3上再增加一路虛擬IO設備PLC_2，并設置使其與DEH另一臺通訊站進行通訊，從而實現(xiàn)DCS同時與DEH兩臺通訊站進行通訊。當Drop07為主時，其虛擬IO設備PLC_1與DEH的工程師站通訊、PLC_2與DEH的歷史站通訊；反之，當Drop57為主時，其虛擬IO設備PLC_1與DEH的歷史站通訊、PLC_2與DEH的工程師站通訊。 DCS采用兩路虛擬IO設備與DEH進行通訊，信號的處理與采用兩塊真實IO卡與DEH進行連接的處理是相似的。DCS發(fā)送數(shù)據(jù)到DEH時，將數(shù)據(jù)同時送到兩路虛擬IO設備，兩路通訊將數(shù)據(jù)同時送到DEH的兩臺通訊站，DEH只要保證其中一臺通訊站正確收到數(shù)據(jù)，DEH就能正確收到DCS發(fā)送來的數(shù)據(jù)；DCS接收DEH數(shù)據(jù)時，對兩路通訊來的數(shù)據(jù)進行“2選1”邏輯處理，當兩路通訊均正常時，取其中一路數(shù)據(jù)，當有一路通訊不正常時，取正常的那一路數(shù)據(jù)。這樣，就實現(xiàn)了DCS與DEH的冗余通訊功能。 4 結(jié)語 經(jīng)過這次改造后，成功實現(xiàn)了DEH與DCS的通訊，并采用雙回路實現(xiàn)了冗余通訊功能。正常運行時，兩個通訊回路同時工作，兩路通訊相互冗余，相互熱備用，只要保證有一路或以上的通訊正常時，就能保證DEH與DCS系統(tǒng)通訊的正常，這就大大提高了機組的安全可靠性。這種采用兩個通訊回路來實現(xiàn)通訊冗余的方法，兩個通訊回路相互熱備用，具有較高的可靠性，對于其它系統(tǒng)的通訊冗余設計也有很大的參考價值。