RR压缩机组控制系统冗余切换故障浅析

崔胜涛

（国家管网集团西部管道有限责任公司 新疆输油气分公司，乌鲁木齐 830000）

0 引言

西气东输一线大部分站场使用的压缩机为RR压缩机组，机组PLC控制系统主要由5部分构成：一是机组冗余控制系统（UCP）；二是发动机控制系统（ECS）；三是安全保护控制系统（UPP）；四是振动监控系统；五是可燃气体和火灾检测及二氧化碳灭火系统（EQP火气系统）。UCP、UPP、ECS 3个系统采用的均是Rockwell公司生产的Controllogix PLC，它将顺序控制、过程控制、传动控制及运动控制、通讯、I/O技术集成在一个平台上，Controllogix系统所有模块都是可以热插拔的，这意味着可以在不停机的情况下进行更换和修理[1]。该控制器有冗余功能，两个控制器框架采用完全相同的配置，与ControlNet网络连接的所有模块一般有两个独立的ControlNet通道A和B，可连接两个独立的链路，在通信和控制时冗余的两个链路同时起相同的作用，当A链路出现故障时，B链路仍起通信和控制作用[2]，这样大大提高了控制器运行的可靠性。RR机组UCP控制器即采用了热备冗余模式，在日常运行中机组控制系统UCP程序多次在执行中出现看门狗超时，导致UCP产生Majors报警；在切换备机架过程中，又因备机架SRM冗余模块故障造成冗余切换失败，导致跳机，给天然气输送生产带来严重地影响，故分析上述问题原因，加以解决此类问题。

1 RR压缩机组控制系统的组成

1.1 RR机组PLC控制系统

RR机组PLC控制系统主要由5部分构成：一是UCP，简称机组控制盘，负责机组工艺流程控制；二是ECS，简称发动机控制系统，负责燃气轮机关键控制[3]；三是UPP，安全保护控制系统负责超速等控制；四是振动监控系统；五是可燃气体和火灾检测及二氧化碳灭火系统。

1.2 RR机组监控系统FT210

FT210是RR压缩机机组利用Intouch软件开发的机组监控界面。Wonderware Intouch是一款备受赞誉的HMI可视化软件，可以帮助用户实现远程操作。Intouch主要由两个部分组成：WindowMaker应用开发环境，使用建立图形窗口显示，并设置与控制器、I/O系统地连接；WindowMaker实时运行环境[4]。FT210系统将两台机组的监控界面统一为一个程序文件，设定了两级权限：操作员权限登录和管理员权限登录。在操作员权限下，只能进行界面的切换，查看和部分功能使用；在管理员权限下，可以关闭最小化监控界面，可以使用所有的功能按钮。需要注意的是Intouch软件安装后，必须要安装有效期内的注册文件才能正常使用。

1.3 RR压缩机组编程系统FT310

RR公司为每座压气站的RR机组都配备了一台笔记本电脑，用于联机调试PLC程序，被称为FT310。在FT310系统中，安装的主要应用软件有Controllogix PLC的编程软件Rslogix5000，通讯软件RSLinx、ControlNet网络组态和诊断软件RSNetWork，可燃气体和火灾监控系统S3等。需要注意的是Rslogix5000、RSLinx、RSNetWork软件都配置有各自的软件狗，即KEY。目前软件保护方法大致可分为两类：软加密和硬加密[5]，而S3系统则配置了硬加密，只有将硬狗安装在FT310工程本电脑的接口后，S3系统才可以联机使用。

1.4 RR机组现场控制设备子系统

RR机组现场控制设备子系统主要是GG燃料气控制系统、GG液压启动系统、GG滑油系统、GG进口空气系统、压缩机、PT润滑系统、压缩机干气密封系统、防喘控制系统（防喘阀）、CO2系统（可燃气体和火灾监控）、阀门控制（压缩机加载、进口、出口、放空阀）、温度（TC/RTD）、速度、振动监控、马达控制中心。

2 RR压缩机组控制系统冗余切换故障分析

2.1 故障现象

压缩机组在运行中出现“ALM UCP 3 Fuel Control Loss of Communication ComStatusFC_UCP3 ALM”和“ALM UCP 3 Sequence Loss of Communication ComStatusSeq_UCP3 ALM”报警，造成机组停机。通过检查发现机组控制系统UCP控制系统冗余机架均出现故障报警，上机架（A机架）CPU各状态灯均不正常：OK灯为红色常亮，RUN灯未亮，IO灯未亮，两块CNBR模块A/B通道显示红色闪烁，SRM模块上Com灯熄灭，LED显示DISQ。下机架（B机架）SRM模块上OK为红色长亮，CPU模块上OK灯状态正常，RUN、IO等均未亮。

2.2 故障原因分析

故障发生后，由于UCP与HMI的通信中断，只有HMI与ECS控制器和UCP控制器通信中断报警，无其他任何报警记录。在线UCP程序中存在A机架的主CPU产生看门狗超时major fault。在产品手册上对此故障代码进行查找，看门狗超时原因为用户任务未在制定时间内完成，程序错误产生无限循环或程序过于复杂而无法按指定要求快速完成，或者有一个更高优先级的任务使该任务不能完成。图1为UCP Watchdog Fault报警记录。

图1 UCP Watchdog Fault报警记录Fig.1 UCP Watchdog Fault alarm record

通过检查UCP程序中任务的扫描时间和看门狗时间设置值，发现UCP程序中TASK1和TASK2的看门狗时间设置较短，Task1扫描周期50ms，看门狗时间为60ms；Task2扫描周期为100ms，看门狗时间为120ms。通过查找资料得出看门狗时间≥（2×扫描周期最大值）+100ms。经过观察，UCP的TASK1程序扫描时间在15ms～17.5ms之间跳变，按照最大执行时间17.5ms计划，程序的看门狗应设置为135ms。因此，判断程序设置的看门狗时间不合理。

检查机组UCP的ControlNet网负荷，发现1#节点和2#节点ControlNet网络CPU负荷均为100%。冗余系统配置要求ControlNet模块CPU负荷不能大于75%[6]，所以，UCP ControlNet网负荷过高也会对程序任务的扫描时间造成一定影响。

检查机组控制系统中CNBR模块版本信息，发现机组实际使用的硬件信号为1756-CNBR/E，版本为11.3版，而程序中组态的模板型号为1756-CNBR/D，版本为5.1。所以，硬件实际版本与程序组态版本不匹配也会对C网负荷造成一定影响。

进一步排查冗余模块事件记录，通过RSLinx软件导出A、B机架冗余模块SRM事件记录，分析发现A机架与发生major fault系统进行主备切换。B机架接到主备切换指令后进行尝试，但由于通讯错误未能切换成功，600ms后B机架冗余模块自动重启，1700ms左右B机架冗余模块检测到A机架，此切换时间已远超过各周期任务看门狗设定值。针对SRM模块的Port1故障查找厂家资料，厂家资料中关于此故障的处理方法为检查模块背板的接口插针，把冗余模块移到其他槽位，更换新的机架，更换冗余模块。

3 优化解决措施

造成故障停机的主要原因为机组程序看门狗时间设置不合理和C网负荷过高。同时，B机架SRM模块故障也是此次故障发生的次要原因。为解决以上问题，主要从以下几方面进行优化：

3.1 优化UCP程序看门狗时间设定值

对UCP程序中TASK1和TASK2的执行时间进行观察，经过一段时间观察后，发现TASK1的最大扫描时间为17.57ms。为预留一定的余量将TASK1最大扫描时间取20ms，则通过计算TASK1的看门狗时间=2×20+100=140（ms）。因此，将TASK1的看门狗时间修改为140ms。经过观察后，发现TASK2的最大扫描时间为43.44ms，为预留一定的余量将TASK2最大扫描时间取50ms，则通过计算TASK2的看门狗时间=2×50+100=200（ms），因此将TASK2的看门狗时间修改为200ms。

3.2 降低C网负荷

降低C网负荷主要是减少MSG指令数，和每个冗余机架添加一个CNBR模块。这两条措施不适合在目前机组控制系统程序中实施。因此，降低C网负荷主要从改变ControlNet网络刷新时间，提高用户连接的请求信息包间隔RPI和减少通过CNBR模块的连接数等三方面进行优化。

对UCP、UPP和ECS程序中组态的IO模块的RPI时间进行优化，将所有模块PRI为5ms的时间优化为10ms。将UCP R2_S02远程机架的第2槽1794-OB16/A模块的RPI时间，由5ms修改为10ms。将UCP、UPP和ECS程序中所有RPI时间为5ms的模块组态均修改为10ms后，则对程序编译，并下装到控制器中。由于IO模块组态信息的变化，需重新对C网进行组态。C网组网优化时，将C网的NUT时间修改为10ms后，出现尖峰网络负荷规划为121%报错信息，保存优化配置后，下载C网优化组网信息。下载后，重新上载C网组态信息，显示修改10msNUT时间，仍然为5ms，因报错未实际被下装到C网中，而且经此方法优化后网络负荷仍然为100%。因此，将原程序和原C网备份下载到控制器和C网中，此项措施未能降低C网负荷。

由于原C网组态的规划节点地址为16，非规划节点地址为20，而实际C网中总在用的节点数为15个。因此，为避免C网扫描时因扫描实际并不存在的节点而增加扫描时间和负荷，将规划节点地址为15，非规划节点地址为16，并重新组网，组网文件无报错，顺利下载完成。

3.3 减少对CNBR模块的网络连接数

通过分析，连接到机组控制系统PLC的设备有7个，如图2所示，分别为机组站控HMI、1#机组机柜HMI、2#机组机柜HMI、机组机柜HMI、工程师站、SCADA RCI主和SCADA RCI备。其中，SCADA RCI主和SCADA RCI备只和UCP通信，且通信数据量较小。机组各台HMI和维护工程师，除与UCP通信外，还与UPP和ECS通信，且通信数据较大。为减少连接数，可将与机组通信的1#机组机柜HMI和2#机组机柜HMI连接断开。断开1#和2#机组HMI采集机组的连接前，先将两台HMI上RSLink中组态文件使用RSLink Backup/Restore软件进行备份，然后将RSLink中与机组ECS、UCP和UPP通信的DDE TOPIC组态删除，同时重新启动机组站控HMI和机组HMI，对无效的通信连接进行释放。优化后，C网负荷下降至77%～81.3%之间波动，负荷下降较为明显。

图2 机组控制系统对外数据通信连接示意图Fig.2 External data communication connection diagram of unit control system

3.4 优化HMI与控制器的数据通信连接路径，均衡CNBR模块负荷

RSLink软件是AB公司开发的，它为AB的可编程控制器与各种RockellSoftware及AB应用软件之间建立起通信联系，从而实现操作站和PLC数据库之间的连接[7]。通过检查各HMI RSLink中组态与控制器的通信路径，发现HMI和ESC的通信，全部通过UCP主CPU机架的2#节点CNBR模块进行通信，而且UCP主CPU机架的4#节点CNBR模块未连接任何外部设备，如图5。且HMI从备UCP机架的IP地址为111.111.111.14的以太网模块与UPP通信，此路径存在冗余切换时通信恢复时间过长的问题，以及备机架故障时主机架单独运行时，UPP与HMI数据通信中断的风险。针对该问题，可将HMI与ECS控制器通信的路径改到由UCP主机架的上2槽位的4#节点CNBR模块上，这样可以将负荷过高的2#节点CNBR的一部分外部访问负荷分配给负荷相对较低的4#CNBR模块承担，达到负荷均衡的效果。同时将HMI与UPP通信的路径改到由UCP主机架上的IP地址为111.111.111.43的以太网模块通信，HMI采集各控制器的通信路径优化示意图如图6。对站控室HMI和机组机柜间HMI与各控制器的通信路径优化后，2#节点的连接数由39个减少到32个，且2#CNBR模块的整体波动范围有所减小，负荷波动基本在72.1%～79.2%之间。4#节点连接数由原31个上升至37个，但模块负荷并未出现明显增加，在69%～72%之间波动。

3.5 更换发生故障的SRM冗余模块

机组备机架上SRM模块3次出现PORT1错误，根据厂家手册建议需要检查和更换SRM模块和与其PORT1连接的背板。更换故障SRM模块和7槽位机架，更换后经过测试冗余功能正常。

3.6 将6块1756-CNBR/E模块全部更换为1756-CNBR/D

将6块1756-CNBR/E模块全部更换为1756-CNBR/D，并重新进行C网组网，机组运行正常。

4 结果及验证

通过进行程序分析、报警信息分析、系统运行状态诊断、系统网络优化等方法和手段，判断此次导致故障停机的原因为A机架CPU看门狗时间超时，及B机架冗余模块Port1通讯错误所致。通过优化看门狗时间，优化C网组态，精简通信连接数，优化数据通信连接路径，更换故障SRM模块等多项措施，机组C网负荷有明显下降，更换SRM模块后冗余功能正常，对避免类似故障再次发生具有重要作用。

5 结束语

本文主要介绍了RR压缩机组控制系统冗余切换故障的处理，目前很多站场所使用的1756-L55及所配套的C网模块、冗余模块、以太网模块等大部分备件已停产，各板卡硬件版本低，且存在模块实际硬件版本与程序组态的硬件版本不一致，C网使用率高导致冗余切换存在失败风险。建议对RR压缩机组的控制系统ControlNet网络负荷进行检查，对存在的类似C网负荷超高问题及时处理优化，一方面减少对机组控制系统的外部访问连接数，另一方面定期重启机组HMI释放无效连接。为了更好地提升压缩机控制系统的整体运行性能，建议使用处理性能更强，可靠性更高的L73、CN2R、EN2T、RM2等新版本模块。