一起DCS控制系统网络异常的分析与处理

李思平

淮南矿业集团电力公司，安徽淮南 232072

1 案例描述

某电厂DCS 控制系统2011 年4 月18 日下午5 点10 左右，运行人员发现1#机组所有操作站中数据丢失，画面显示为“???”，但现场设备运行正常。维护人员到达后去电子设备间检查，发现部分控制器退出同步，维护人员试图手动同步，发现42 控制器出现X 灯常亮故障。去机柜中检查发现网络中原先设定为master 状态交换机（IP：192.168.11.211）指示灯显示异常，master 灯从常亮变为闪烁。而同机柜的另一台交换机（IP：192.168.11.212）master 灯由不亮变化为闪烁状态。维护人员对服务器做重起，但无效果；对IP：192.168.11.212 的交换机做重新上电处理，网络恢复了一小段时间运行后再次出现上述情况。经电话咨询DCS 厂家技术人员，确定把此台交换机换下，并拨出42 控制器后，网络恢复正常。5 月31 日下午13：37 前后，1#机组所有操作员站中再次出现部分数据变成“???”，但约一分钟后自动恢复。

2 原因分析

2.1 4 月18 日网络异常的分析

网络出现数据采集中断时，设定为master 状态交换机（IP：192.168.11.211）指示灯显示异常，master 灯从常亮变为闪烁，而同机柜的另一台交换机（IP：192.168.11.212）master 灯由不亮变化为闪烁状态。

通常，常态下的环网的状态是：网络中有一台交换机设置为master，在网络构建成环时，此台交换机上的master 灯常亮，并且在web 页面中也可以观察到。环网中的其他交换机master 灯都不亮，web 页面观察到的都是slave 状态。一般，master 灯变为闪烁状态只有在环网处于开环状态时才会出现。而同时出现两台交换机master 灯闪烁，有两种可能性：1）网络中有两台交换机人为设置成了两个master。（这个可以排除）；2）网络中出现异常的数据包，或交换机出现了硬件故障时，网络拓扑发成了改变。从交换机的日志文件中可以看到，在出现问题的时间点，交换机在短时间内记录了多次拓扑更改信息。从部分控制器保存的事件日志文件能提取到如下记录：“! 18/04/11 11：01：54 (0x5C004A16) 81F6 Entering Ethernet rate Protection UDP broadcast storm”，可以看出网络确实产生UDP 数据包广播风暴！

从交换机和控制器的这些记录信息，可以发现在数据采集异常时，环网在频繁的切换状态，网络中在那个时间段很有可能存在着很大的数据流量，即发生了网络风暴，从而使整个网络的通讯不畅，数据无法正常传输，致使操作站画面数据显示为“???”。但究竟什么原因诱发了网络风暴，还有待进一步的试验分析。

2.2 5 月31 日网络异常的分析

通过对控制器日志的分析，发现本次异常时锅炉和汽机网段共有13 对控制器出现中断，最早出现中断的控制器是T2550_16，中断时间是13：37：48，最后恢复的控制器是T2550_30,时间是13：38：28。总体故障时为40 秒。出现数据中断的控制器都出现了同步退出，退出时间大概在数据中断前12 秒左右，这13 对控制器的事件记录中都出现了由数据中断引起的冗余切换过程。

2.3 两次网络异常的比较

5 月31 日的故障与4 月18 日的现象有相似之处，都是在操作站上数据显示为“???”。但5 月31 日出现“???”的范围较小，涉及13 对控制器，时间较短，持续40 秒。5 月31日的故障的直接原因与4 月18 日不同。4 月18 日所有的控制器的记录都显示出网络的中断和堵塞，使得控制器向操作员的数据通讯中断，画面显示都为“???”号。而5 月31 日的故障，没有任何与网络中断和堵塞的记录。仅为个别通讯中断引起控制器的同步退出的记录。同步退出过程，再次强制同步，造成网络负荷短时加重，13 对控制器上传数据故障，造成相关数据在画面上显示为“???”。

3 对策与性能优化

3.1 4 月18 日网络异常后所采取的主要措施

4 月18 日异常发生后，该厂邀请相关电力科学研究院专家、DCS 厂家及交换机厂家技术人员一起立即在现场招开了事故分析会。确定：1）立即将交换机送台湾的生产厂家进行软、硬件检测；2）DCS 厂家抓紧对控制器及交换机的日志事件，招集资深人员对整个事件做更深入的分析，找出事件的真正原因。5 月9 日交换机检测结果出来，认为交换机软硬件均没问题。于是再次招开分析会，确定先采取两条措施：1）对交换机进行流量限制，以抑制广播包风暴的发生；2）将机炉现在的一个大环网结构改为机炉分开的两个小环网结构，以减小事故发生的危害程度。这个两措施实施前后，请电力科学研究院在停运的机组上用网络攻击仪分别进行试验，从试验结果看，措施实施前网络发生了大面积瘫痪，而实施后只出现了小部分控制器死机，说明措施实施有一定效果，但并没有杜绝隐患。

3.2 5 月31 日网络异常后所采取的主要措施

通过进一步的分析及与同类型DCS 系统比较，提出了以下两条主要措施。

3.2.1 去除自动同步，避免出现在同步退出时，出现数据中断

目前每个控制器中设置的自动同步逻辑，每隔2 秒，Red_ctrl 模块检测控制器的状态，如果发现同步退出了，发出一个5 秒的脉冲去同步控制器，此同步指令是90 秒之内只能发出一次。从欧陆控制器的使用要求出发，只有是控制器出现网络、电源或是其本身出现问题时，才会出现同步退出。退出同步后，应由维护人员检查故障，确定没有问题后，才由人为手动同步。因此自动同步一般是不允许设置的。由于T2550V5.0 存在较多的由于通讯中断产生的同步退出，为了从表面上解决此问题，从09 年11 月增加了自动同步功能。在出现少量控制器退出同步时，自动同步功能没有产生数据中断，从表面来看没有出现问题，经过检查，在本次事故之前，也有少量的控制器出现退出同步，又被自动同步，出现短暂的通讯中断，由于数量少，没有在画面数据上表现出来 (例如：20110529，9 点左右，20 号控制器) 。在本次故障过程中，大量控制器出现退出同步，又被自动同步逻辑强制进行同步，大量的通讯冲击造成了数据中断。去除自动同步之后，去除了通讯冲击，可以保证在出现同步退出时，不出现数据中断现象。

3.2.2 升级控制器软件，尽量减少通讯失败，避免同步退出

通讯失败导致同步退出的问题，在T2550V2.2 版本是没有的，即使出现短暂的通讯中断，控制器也不会出现同步退出。为了提高控制器对网络诊断的安全性，欧陆从T2550V4.0 开始增加了控制器对网络数据的诊断功能，在发现网络通讯故障时，会主动切换主从控制器，将主控制器退出运行，从控制器接管工作。此项功能的增加反而造成T2550 网络的稳定性下降，为此欧陆公司后来又推出了V5.0、V6.0、V7.0、V7.2 版本，该厂目前用的是V5.0，比较同为NETWORK-6000 系统的其它电厂使用情况，发现V7.0 版本使用稳定，故确定将该厂控制器软件版本也升级到V7.0。

3.3 进一步的优化措施

由于网络故障的原因很多，为进一步提高DCS 系统的可靠性，尽可能避免再次发生类似事件，在以上主要措施基础上，还采取了一些其它的改进措施。以下为全部措施统计：1）交换机网口带宽设置限定：挂控制器网口限为10%，挂上位机网口限20%，环口不限；2）改造网络结构，将目前机炉大环改为机炉两个小环，减小故障发生时的危害程度；3）去除控制器自动同步功能，并将同步时间由2s 延长到10s；4）控制器系统软件升级为7.0 版本，提高控制器运行的稳定性；5）调整数据通讯的优先级，将数据供给改为高优先级，即SFC 周期改为task4 770ms，确保故障发生时，现场数据优先通行；6） sis 机优化。Sis 功能移至工程师站，原sis 站单做his 站，his 数据由从控制器直接提取改由从服务器提取，以减轻网络负荷，并升级历史曲线软件；7）报警功能做调整，减轻各工控机的负荷，解决服务器和操作员站易死机或卡涩现象；8）升级lintools 软件；9）升级交换机软件；10）所有工控机增加1G 内存，提高工控机性能；11）改善机柜强制通风，确保卡件不超温运行；12）对系统状况进行跟踪，定期安排人员来查看各种日志和记录，判定系统性能。

4 结论

该DCS 控制系统经过上述优化措施后，再次请相关单位进行性能测试，在测试过程中系统运行正常，未出现错误信息，各控制器所属网段的负荷率均在允许范围内。同时经两年多的实际运行验证，DCS 系统再未发生过服务器数据丢失，操作员站画面实时数据显示为“???”号，无法对现场设备进行监控的现象，这充分证明了优化措施取得了预期的效果，为该厂机组的安全稳定运行提供了有力保障，同时也为今后处理类似事件提供了很好的经验借鉴。

[1]高金源，夏洁.计算机控制系统.北京：清华大学出版社，2007.

[2]王常力，罗安.分布式控制系统（DCS）设计与应用实例.北京：电子工来出版社，2004.

[3]姜学军.计算机控制技术.北京：清华大学出版社，2006.