传动人才网

DCS与DEH通讯存在问题及解决方案

发布于:09-01

DEH系统采用与DCS系统共享操作员站的方案,通过通讯的方法,实现全部监控的功能。 广东韶关发电厂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)。 [align=center]图1?DEH与DCS通讯结构图[/align] 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所示。 [align=center]图2?DCS对DEH进行开关量操作的DEH逻辑(虚线部分为增加)[/align] [align=center]图3?DCS对DEH进行模拟量置数操作的DEH逻辑(虚线部分为增加)[/align] 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系统通讯的正常,这就大大提高了机组的安全可靠性。这种采用两个通讯回路来实现通讯冗余的方法,两个通讯回路相互热备用,具有较高的可靠性,对于其它系统的通讯冗余设计也有很大的参考价值。

阅读 103