SCADA系统信息安全常见故障处理方法.doc

《SCADA系统信息安全常见故障处理方法.doc》由会员分享，可在线阅读，更多相关《SCADA系统信息安全常见故障处理方法.doc（85页珍藏版）》请在沃文网上搜索。

1、附件5 SCADA系统信息安全常见故障处理方法附件5 SCADA系统信息安全常见故障处理方法1、 PLC通讯中断- 1 -2、 站控机中毒导致工程运行不正常或不能启动- 3 -3、 站控数据不更新- 6 -4、 第三方设备通讯故障- 8 -5、 RCI自动停机- 9 -6、 由于RCI需要轮询点数过多导致的故障- 12 -7、 阀室数据上传故障- 14 -8、 甪直站调压橇压变PT5802传输数据错误的故障处理- 17 -9、 压气站HIMA ERROR故障分析和处理报告- 19 -10、 控制网组网不正常- 43 -11、 ANYBUS COMMUNICATOR与ESD系统通讯中断- 46

2、-12、 I/O模块通讯故障- 48 -13、 AB PLC系统ETHERNET冗余网络通讯A网失败后B网不能工作- 49 -14、 北调无法看到ESD系统中的模拟量- 54 -15、 通讯服务器冗余配置失败- 55 -16、 配置路由器时在配置界面上出现乱码- 60 -17、 DDN通讯中断- 61 -18、 站场与北调的通讯频繁闪断- 62 -19、 路由器用户名、密码失败，无法登录及配置- 62 -20、 第三方设备与上位机通讯无法建立或通讯不正常- 64 -21、 机柜间到站控室的1#光纤不通- 70 -22、 HIRSCHMANN交换机IP地址设置- 72 -23、 交换机及路由器对

3、应端口通讯方式配置- 78 -24、 洛阳分输站与北京调控中心通讯中断- 84 -1、 PLC通讯中断1、故障现象站控机中有“PLC通讯中断”报警，且相应的NOE模块会显示“Fault”红灯亮。2、故障原因NOE以太网模块网络地址配置错误，造成PLC通信不能实现冗余，主备切换后无法实现PLC与RCI间的通讯。比如说济南站的主备两个NOE模块的IP按照IP点表上应该是172.17.62.65（主）和172.17.62.67（备），另有172.17.62.68这个IP是预留未使用的，如果错吧172.17.62.67配制成172.17.62.68，由于RCI识别的NOE模块IP是172.17.62.

4、67而非172.17.62.68，就会造成主备切换时，PLC与RCI通讯不上而出现通讯故障报警,该报警将显示在站控机界面上。3、解决方法（1）首先确认PLC、交换机、RCI间各网线接口没有虚接或掉落的。（2）对照IP表，试着ping PLC两个NOE以太网模块的IP地址，哪个地址ping不同，就说明哪个模块有问题。可以通过上次备份的PLC工程查找到NOE的网络设置，如图8.1.3和图8.1.4的操作步骤即可看到。可以对各NOE模块的网络进行设置，即“Internet Address”、“Subnet Mask”和“Gateway”。（3）在笔记本上打开Concept软件，打开原先备份好的工程，

5、可以通过网线或串口线连接PLC（如果两个NOE模块的地址实在找不到的话），按照（2）中的方法重新设置好网络后，重新下载程序到PLC的控制器中。（4）断开笔记本电脑与PLC的链接，对PLC的备机进行热备设置。将备机CHS热备模块的钥匙开关拨到“Xfer”挡，按下程序更新按钮，然后松开按钮，会看到备机架的CHS模块显示“Standby”橙色灯亮，当该灯常亮以后则表示热备完成，这时备机架CPU模块的“Run”绿灯将变亮，主机架CHS模块的“Primary”绿灯常亮。（5）PLC与RCI的通讯恢复以后，站控机电脑屏幕上“PLC通讯中断”报警可以确认掉。2、 站控机中毒导致工程运行不正常或不能启动1、故

6、障现象站控机工程运行不正常或不能启动。2、故障原因站控机外接移动存储设备而中毒，病毒影响Viewstar软件的正常使用。3、解决办法采用瑞星杀毒软件、病毒专杀工具（如Worm.LovGate爱情后门专杀）对站控机进行杀毒。（1）图8.2.1为靖边站在用瑞星对站控机进行查杀后的情况，图中可见病毒名称都为Backdoor.SdBot.wgb，一种集后门、蠕虫功能于一体的，通过网络共享和操作系统漏洞进行传播的病毒。病毒会尝试通过弱密码登陆目标系统，还会在感染的电脑上打开后门接收攻击者发出的指令，然后连接特定的IRC服务器通知攻击者病毒的存在。病毒会扫描网段内的机器并猜测共享密码，占用大量网络带宽资源

7、，容易造成局域网阻塞。它通过IRC服务器接受攻击者发出的指令，例如安装/卸载后门、下载并运行文件、结束进程、运行代理服务器、盗取流行游戏的账号、对指定的IP进行DOS（拒绝服务）攻击等。（2）2009年12月16日，红柳站站控机工程无法启动，每次启动后提示“LSASS.EXE出错,系统将在60秒内自动关闭！”，然后在指定的时间内自动重启。然后维护人员在安全模式下用瑞星对站控机进行病毒查杀，杀出了大量的“packer.main007”木马。查杀结束后重启站控机和工程，Viewstar运行恢复正常。由SYSTEM执行的lsass.exe是“无害”的系统进程，用于微软Windows系统的安全机制，本

8、地安全和登陆策略。但是假如在站控机的任务管理器中同时看到lsass.exe和LSASS.EXE这两个进程，则表明站控机已经中了Windang.worm、irc.ratsou.b、Webus.B、MyDoom.L、Randex.AR、Nimos.worm病毒，或者是该病毒的变种。LSASS.EXE在任务管理器中显示为当前用户在执行，而非SYSTEM在执行，该病毒通过软盘、群发邮件和P2P文件共享进行传播。解决办法如下：（a）使用prockiller进程杀手终止LSASS.EXE进程；（b）删除病毒文件（有的文件可能没有）：l C:/Program Files/Common Files/INTEX

9、PLORE.pifl C:/Program Files/Internet Explorer/INTEXPLORE.coml C:/WINDOWS/EXERT.exel C:/WINDOWS/IO.SYS.BAKl C:/WINDOWS/LSASS.exel C:/WINDOWS/Debug/DebugProgram.exel C:/WINDOWS/system32/l C:/WINDOWS/system32/MSCONFIG.COMl C:/WINDOWS/system32/（c）使用Free Window Registry Repair注册表清理工具清理注册表中的垃圾信息。也可手动清除，下面

10、是手动清除的需要删除的项目：l HKEY_CLASSES_ROOT/WindowFilesl HKEY_CURRENT_USER/Software/VB and VBA Program Settingsl HKEY_CURRENT_USER/Software/Microsoft/Internet Explorer/Main下面的 Check_Associations项l KEY_LOCAL_MACHINE/SOFTWARE/Clients/StartMenuInternet/INTEXPLORE.pifl HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Window

11、s/CurrentVersion/Run 下面的ToP项（d）使用RegC瑞星注册表修复工具修复注册表；（e）重启站控机后可再进行一次全盘杀毒。3、 站控数据不更新1、故障现象站场SCADA系统的站控电脑上显示的数据部分或大部分不能及时更新，数据处以橙色状态显示，如图8.2.5所示。以进出站压力或温度为例，如果这些数据不能及时更新，那么Viewstar日报表中每小时进出站压力或温度所记录的值同样也是不更新的，即固定不变。这样值班人员将不能正确判断站场的实际生产情况，形成较大的安全隐患。一个简单的例子：比如某分输站的电动调压阀采用压力PID控制出站压力时，门站用气量突然减小了（如气罐车停止加气）

12、，但门站没有事先通知我分输站值班人员，而PID控制具有一定的滞后性，使得出站天然气因憋压而迅速上升。但是这时由于站控数据不能及时更新，造成值班人员未能及时发现，使得出站压力在有限的时间内能超过安全泄放阀设定压力，使得安全泄放阀放空。这本来是一个完全可以避免的情况。2、故障原因（1）站控机与RCI间的日期时间不一致；（2）RCI长时间不间断工作，硬件老化，工作性能下降；（3）RCI内部配置不高；（4）第三方设备（如流量计算机、UPS）又不断地增加，数据采集量增大，工作负担加重；（5）网络中有网线虚接或断开的地方。这些使得RCI不能及时采集各种第三方设备的数据，即发生数据丢失现象，从而影响数据库中

13、数据的准确性。3、解决办法RCI与很多第三方设备进行通讯，包括PLC、UPS、低压配电盘、流量计算机和燃气发电机等等，因为它与PLC的通信量最大，所以在此以它与PLC的通讯为例进行说明。解决数据不更新的步骤如下：（1）在站控机上打开校时软件，对站控机进行校时，将其时钟与RCI同步。（2）在站控机操作的系统配图界面，从中找到图标，点击弹出一个对话框。在该对话框中将“轮询”勾选上，点击应用。通常情况下，站控数据都会进行一次刷新，原先不变的数据都会发生变化，橙色变成白色即恢复正常。如果变化不大，可再轮询几次。（3）如果以上都不起作用，可以对两台RCI进行切换，将原先为备用的切换到主用，并可重复（1）

14、、（2）步，看看数据显示是否恢复正常。（4）如果以上都不起作用，可以将站控机工程停掉，然后再重启工程，再观察数据显示是否恢复正常。（5）如果以上都不起作用，可以先将站控机工程停掉，然后把两台RCI分别重启，之后再重启工程，再观察数据显示是否恢复正常。（6）如果以上都不起作用，可以将站控机工程停掉以后对站控机进行重启，主要还是为了刷新站控电脑的网络连接，然后重启工程，再观察数据显示是否恢复正常。（7）如果以上都不起作用，可以用站控机的备份工程替换现有工程，再观察数据显示是否恢复正常。（8）通常经过以上工作都可以恢复站控机数据的更新，如果上工作都不起作用，则需查看网络连接上有没有虚接的或断线的，交

15、换机是否工作正常等。确认网络连接无问题后，可对RCI进行更换或硬件升级，提高其工作性能。4、 第三方设备通讯故障1、故障现象在站控机上出现第三方设备通讯故障报警，如UPS通讯故障、流量计算机通讯故障、低压配电盘通讯故障、燃气发电机通讯故障等。2、故障原因（1）第三方设备停机或断电。（2）通讯回路断路或有源1转2接口插头接触不良。3、解决办法（1）对于由设备停机或断电造成的通讯故障，无非是去查找设备本身停机的原因，以重新起机恢复通讯。（2）而由通讯线路引起的通讯故障通常都集中在LSU 232_2防雷有源1转2接口上。LSU 232_2是用来将第三方设备的数据分别同时传到两台冗余的RCI通讯服务器

16、用的：接到2#RCI（对应B line）接到1#RCI（对应A line）来自第三方设备（对应C line）LSU 232_2的“A on”灯对应A line，“B on”对应B line，这两个灯亮则表明第三方设备到对应的1#RCI和2#RCI是接通的，“TxD”或“RxD”灯闪烁则表示目前第三方设备正在与RCI进行数据的发送或接收。通过观察这些指示灯的情况即可判断当前的第三方设备通讯情况。通常第三方设备通讯故障都是由于“C line”处的串口插得不稳所至，因为该口串口的固定螺丝不容易固定住插头（硬件设计造成），开关机柜门时容易碰到该插头串口线，导致插头松动，从而引起通讯故障。这时只需要紧固

17、一下该插头既可。（3）如若发现LSU 232_2的指示灯都不亮了，可以用万用表检测其电源输入端电压，看看供电是否正常。如果电压为0，则需检查电源线路情况，以恢复供电。如果电压正常（24VDC），且无串口虚接情况，则需判断LSU 232_2是否故障。可用调试笔记本接到来至第三设备的串口，通过在电脑上运行串口调试工具，来检测是否能够接收到第三方设备的数据。（a）可以接收到第三方设备的数据，则将来至第三方设备的串口接至C line口，分别用笔记本电脑接A line和B line口，检测到是否可以接收到第三方设备的数据。如果接收不到，则表明LSU 232_2故障，需维修或更换。（b）不可以接收到第三方

18、设备的数据，则需查看来至第三方设备的数据线路是否有断路或设备本身存在故障。5、 RCI自动停机1、故障现象：RCI自动停机，蓝色运行指示灯熄灭，绿色电源指示灯闪烁（正常运行下蓝灯、绿灯都常亮），断电并重新上电启动后设备能运行，但只维持一段时间后会再次停机，有的RCI甚至不能重新启动。2、故障原因：RCI长期不间断运行，致使其电源（型号HP-U280EF3）内部芯片老化损坏，或电源风扇损坏，无法给RCI正常供电，致使设备自动停机。3、解决办法：更换RCI电源。但如能检查出电源的损坏部件，则可对该部件进行更换，以减少成本，如淮安站就曾经有一个电源是K419 TNY2684 28021B芯片损坏（过

19、电流或过热导致损坏）。电源更换步骤如下：（1）对故障的RCI下电，将后板插槽上的串口线、网线断开，取出RCI，打开设备上盖板。（2）找到RCI的电源，将与电源相连的各插头拔下，然后松开固定螺母，将故障电源取出。（3）换上新的电源，重新固定好，并将各插头插上，整理好内部电线后盖上盖板。将串口线、网口重新接上，重新上电，观察电源灯绿灯、运行灯蓝灯是否常亮，常亮为正常。在上位机中使用指令对RCI进行切换，将更换好的RCI切换为主（为了减少对设备的损害，最好是采用软切换，但也可用硬切换，即关掉原先无故障的那台RCI，观察当前已维修的RCI是否能自动切换为主），测试设备运行是否正常。如果在上位机中的各种

20、操作均无问题，则说明当前RCI工作正常，故障已排除。6、 由于RCI需要轮询点数过多导致的故障1、故障现象郑州站改造过程中在升级HIMA程序后，发现站控系统ESD休眠命令下发后，站控机不断有新的休眠报警提示，确认复位后，仍不断弹出，逻辑上站控机休眠状态灯正常时应该是变红，不闪烁的，但现场情况为郑州站的休眠状态灯不断闪烁。2、故障原因开始以为是添加地址冲突造成，对所有新添加的数据点地址进行核查，未发现地址冲突问题。用调试笔记本与PLC联机发现上位机中的ESD休眠命令已经下发，确认故障只存在于站控机系统中。经过一段时间的检查后发现，由于郑州站的HIMA模块有9个之多，添加的报警点有50多个，在加上

21、原来系统需要扫描的地址，改造后郑州站每次站控机轮询需要检测的地址有近200个，根据经验，一般轮询地址点超过100后，就会造成数据采集不准。这么多的地址如果同时扫描的话，很容易造成信号不稳和紊乱。故此，考虑将轮询地址分两批扫描。3、解决办法（1）用Total Commander软件登陆RCI，在修改文件之前首先将配置文件拷贝到当地硬盘进行备份。（2）将RCI中的MBPOLL_XXX_YYY.POL文件拷贝到当地硬盘下，其中XXX为RCI NUMBER，例如南京为175；YYY为通讯端口号，例如PLC为17。打开MBPOLL_XXX_YYY.POL:（3）可以看到配置文件中第四行MbAnz为160

22、，大于100，所以将其修改为两次轮训：（4）保存后，将修改后的配置文件DOWN回到RCI中：（5）最后使用INIT 6命令重启RCI使配置生效，对另一台RCI进行同样操作即可。修改后，故障现象排除，系统恢复正常。7、 阀室数据上传故障1、故障现象RTU阀室数据不能上传到北京调度，数据不能更新，调度也无法对阀室设备进行操作。2、故障原因（1）机柜供电系统掉电；（2）DI或AI模块数据没采集上；（3）RTU控制器工作不正常；（4）RCI与路由器间通信故障。3、解决办法（1）检查机柜是否掉电，机柜掉电了的话，自然所有设备都无法工作，数据也无法上传。进入阀室大门，先看TEG发电机是否还在工作，如果已经

23、不工作了，则很有可能RTU机柜和通信机柜内设备已经掉电。如果没掉电则表示蓄电池仍有电，但是请尽快重启TEG发电机。（2）打开RTU机柜门，查看各DI或AI模块（16点开关量输入模块AS-BDEP-256、4通道模拟量输入模块AS-BADU-256等）的输入端指示灯是否红色常亮，亮则表示接通，正常情况下DI和AI模块的输入通道指示灯亮均会有亮的，因为都涉及到通道的使用。因为有发生过DI或AI模块的供电回路保险丝烧断的情况，致使输入模块无法采集现场数据，这种情况下更换保险即可。如果保险没有烧断，确认模块供电正常后，所有输入端的灯仍不亮。也可通过模块识别来判断哪个模块连接不上。使用计算机登陆到RTU

24、上，进入RTU的硬件配置，进入I/O Map，弹出以下窗口：上图中，在Detected下是红色背景的，证明这几块模块不被系统识别，它们的数据将无法通过背板传送到RTU的CPU中，是灰色背景的表示这部分硬件配置和实际完全一致。（3）如果DI和AI模块工作指示灯正常，则检查RTU处理器模块PC-E984-258。首先查看它有没有掉电，因为它也有自己的保险，如果没有掉电则通过观察控制器的各LED灯即可判断它工作是否正常。各LED灯的含义如下：CPU的LED灯含义LED名称颜色含义Ready黄色已供电，CPU正在运行Run黄色用户程序正在运行Bat low红色电池电量低或已没电Modbus 1黄色传输

25、活跃Modbus 2黄色连接笔记本用如果其中的Ready灯或Run灯不亮黄色，则说明控制器有问题，对控制器进行重启，并连接笔记本电脑，打开Concept软件，在线查看程序工作情况是否正常，各现场设备的数据是否能正常传输被采集到RTU。如果程序出问题，可采用备份程序重新下装到控制器中，再运行查看数据采集情况是否恢复。如果Modubus灯不亮黄色，则说明通信有问题，看看网线有没有虚接的地方，对其进行紧固，或更换一根完好的网线。然后观察RJ-45网口处LED灯的状态，黄色表示连接上，绿色表示通信活跃，如图8.5.3所示。并连接电脑查看数据采集情况是否恢复。假如这些工作都做了以后仍然连接不上控制器，无

26、法恢复程序，或采集到的数据仍然传不出去，则表明是控制器硬件问题，前提是确认网线没问题，则需更换控制器，并将更换下来的控制器进行维修。（4）如果现场数据能够被正常采集上来，则问题将出在通信上，这时需对RCI和路由器进行检查。检查网线或其他数据接头是否有虚接的，将它们紧固，查看网口处指示灯的闪烁是否正常。确认网络线路连接没有问题以后，如若数据的上传仍然没有恢复，可以对RCI和路由器进行重启，如果硬件没有问题的话，通常情况下数据通信链路都能恢复，因为软件配置都不会有什么改变。（5）如果还是有问题的话，可能是RCI的串口损坏或者RCI其它硬件出现问题，可以更换RCI测试一下，具体方法是，将RCI断电后

27、取下，将RCI内的一块内存卡SDCFB-64-101-80取下，插入新的RCI内部，在恢复连线上电，检查通讯是否正常，如果通讯仍然不正常，就需要将旧的RCI及卡和一套新的RCI及卡寄到中油龙慧自动化公司，由工程人员对旧的RCI进行检测，对新的RCI进行配置，得出结论及配置好新RCI后一并返回管理处。 8、 甪直站调压橇压变PT5802传输数据错误的故障处理1、故障现象甪直站更换了一个调压撬压力变送器以后，该压力取样点传输上来的数据跟实际现场压力表数据严重不符。2、故障原因由于更换了压力变送器，将原先量程压力范围为0-6Mpa的压力变送器换为量程为0-10MPa的压力变送器，而原先的上位机中数据

28、库和PLC程序都还是按照原来0-6MPa的量程进行运算和执行的，因此造成传输后数据换算结果发生错误。3、解决办法将上位机viewstar的数据库跟PLC程序中的对应的压力量程0-6Mpa改为0-10Mpa，数据就对应上了真实值。具体修改办法如下：（1）在concept中打开PLC程序。找到相应的SCALWTOR功能块，它用来将所采集到的模拟量电信号换算压力值：其中，PI12020，4095，rPI12020.0，10.0，两者间的换算关系如下式：VALOUT=+SCALBMINrPI1202=修改压力上限，即对SCALBMAX进行修改既可，将6改成10。然后将更改后的程序进行下装，在“Onli

29、ne”选项中选择“Download changes”。（2）Viewstar数据库中的数据点的更改：数据点的更改在组态环境Graphical Editor点击Para 图标，进入数据库。数据库中，温变跟压变是在MIA下面，找到要修改PT所对应的阀号。文件夹如下图所示：在value下的数据里面更改具体的参数。其中address为6位的IEC地址，Alert_hdl为报警设置，archive为归档设置，common为描述，单位及数据点位数设置，msg_conv为量程转换设置，pv_range为量程范围设置。在此只需在pv_range中更改量程，将原来的0-6MPa更改为0-10MPa即可。9、 压

30、气站HIMA ERROR故障分析和处理报告1、适用对象SCADA ESD系统2、故障现象从2009年11月22日,红柳站第一次发生4块HIMA F3DIO 20/8系列模块(F3A、F3B、F3C和F3D)同时Error故障报警，至2010年1月29日期间，四道班、轮南、红柳、玉门、靖边和中卫站6座场站发生HIMA ERROR共34次，涉及模块39块。其中红柳、靖边、中卫站为与西二线联络站，共发生27次，占总故障数的79.4%，轮南、玉门站各发生1次，四道班站发生5次。当发生ERROR时，相应的Remote I/O模块将停止运行，看门狗信号会被切断，所有的输出将置off，ERROR灯变红，ER

31、ROR code0。最终造成ESD系统无法正常运行，严重影响场站的安全平稳运行。下表为绝大部分的HIMA ERROR情况统计：HIMA ERROR情况统计序号站 名日 期HIMA模块ERROR信息1轮南站12月19日F3B因为HIMA的日期和时钟未调整，所以诊断日志上缺少记录。2四道班站11月27日F3DIOT UNEXPECTED COMPARATOR INTERRUPT3四道班站11月29日F3DIOT UNEXPECTED COMPARATOR INTERRUPT4四道班站12月22日F3DIOT UNEXPECTED COMPARATOR INTERRUPT5四道班站12月26日F3D

32、IOT UNEXPECTED COMPARATOR INTERRUPT6四道班站1月8日F3DIOT UNEXPECTED COMPARATOR INTERRUPT7红柳站11月22日F3A、F3B、F3C、F3DIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP8红柳站11月24日F3A、F3B、F3C、F3DCPU State FAILURE STOP9红柳站11月26日F3A、F3B、F3C、F3D、F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAI

33、LURE STOP10红柳站12月19日F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURRED11红柳站12月26日F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURRED12红柳站1月6日F3A、F3B、F3D、F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP13红柳站1月20日F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURRED14玉门站12月17日F3EIOT UNEXPECTED COMPARATOR

34、INTERRUPT15靖边站12月4日F3E、F3GIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP16靖边站12月5日F3E、F3GIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP17靖边站1月3日F3A、F3B、F3C、F3D、E3E、F3F、F3GIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP18中卫站12月26日F3A、F3B、F3C、F3D、F3EIO

35、T TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP19中卫站12月30日F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURRED20中卫站1月1日F3A、F3B、F3D、F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP21中卫站1月2日F3B、F3D、F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP22中卫站1月3日F3B、F

36、3C、F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP23中卫站1月10日3：11F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURRED24中卫站1月10日17：33F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURRED25中卫站1月11日12：54F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURRED26中卫站1月11日16：30F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCU

37、RRED27中卫站1月12日16：53F3B、F3C、F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP28中卫站1月12日23：20F3B、F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP29中卫站1月13日1：29F3B、F3EIOT TIMEOUT OF CPU WATCHDOG TIME OCCURREDCPU State FAILURE STOP30中卫站1月25日F3B、F3C、F3EIOT TIMEOUT OF CP

38、U WATCHDOG TIME OCCURREDCPU State FAILURE STOP31中卫站1月29日F3EIOT UNEXPECTED COMPARATOR INTERRUPT注：红色标记为F3 DIO 20/8 02型IO模块，未标记的为F3 DIO 20/8 01型模块。3、总体故障分析以下3种原因之一均会导致HIMA模块ERROR：l CPU检测到自身有一个硬件故障；l CPU检测到操作系统有一个软件错误；l Watchdog触发ERROR STOP，因为CPU的运行周期Cycle time超过了Watchdog time。HIMA模块发生ERROR后，其CPU将停止应用程序

39、的执行，所有硬件和软件的测试都会结束，所有的输出将被重置，只能在PADT（Programming and debugging Tool）中通过“Reboot Resource”命令将CPU重启。然而，具体情况还需要结合各站HIMA Remote I/O Diagnostics log（诊断日志）进行分析。模块的ERROR信息大体为以下三条：l IOTUNEXPECTED COMPARATOR INTERRUPT，其中IOT表示CPU self tests，即CPU在自检时发现未知的比较器中断；l IOTTIMEOUT OF CPU WATCHDOG TIME OCCURRED，即CPU Wat

40、chdog time（看门狗时间）超时；l CPU StateFAILURE STOP，即CPU为故障停运状态。下边分别对这三个ERROR信息进行说明。（1）UNEXPECTED COMPARATOR INTERRUPT第一种情况中关于Comparator，由于HIMA模块有与安全相关的central module（中央模块），它基于SIL（Safety Integrity Level，according to IEC 61508）标准，由2个处理器系统组成，因此能够在运行时自检和比较运算结果。即所谓的比较器中断指的就是HIMA中央模块里的两个处理器在进行运算结果的比较时被中断了，具体原因是u

41、nexpected（未知的）。Central module结构图：（2）TIMEOUT OF CPU WATCHDOG TIME OCCURRED第二种情况中HIMA模块的watchdog time（WT）超时，即CPU的运行周期cycle timeWT。WT是CPU运行周期的最大允许值，一旦运行周期大于这个值，CPU将会ERROR STOP。下边为WT取值的2个约束条件：（1） 10msWT（safety time/2）（2） +execution time of the applicationWT5000ms其中safety time（ST）是控制器的安全时间，但不是整个程序的安全时间。C

42、TS（communication time slice，通信时间段）是cycle time的一部分，该值大一些不会有负作用，只是当网络负担重时，CTS会增大，从而会使cycle time增大。相反，CTS小一些的话，可以减小cycle time受到网络的影响，在一定程度上限制cycle time的大小。但如果CTS太小的话，将存在并非所有通信任务都能在一个CPU cycle内执行完毕的风险，因而降低了数据传输的质量，一旦时间参数间发生冲突的话会引起通信路径的关闭。即CTS的最大值，2，5000ms，为完成通信任务需要时间段的最大设定值。尽管不可以直接被计算出来，但是CTS的最小值却可以计算出来

43、，可以根据来估取。的计算方法如下：（3）FAILURE STOP观察红柳站和中卫站ERROR信息会发现“FAILURE STOP”单独发生的情况极少，通常发生在“IOTTIMEOUT OF CPU WATCHDOG TIME OCCURRED”之后，也就是说WT溢出有可能接着引发CPU故障停运。由于硬件故障或软件错误都能引起ERROR STOP，仅仅靠“CPU StateFAILURE STOP”信息是不能明确故障原因的。如果通过“Reboot Resource”命令能够重启CPU，则说明故障是暂时性的，即目前故障已经消除；如果不能则说明HIMA模块可能已经损坏。通过以上对ERROR信息的介绍

44、，对故障情况有了大致了解，下边将做进一步深入分析。4、具体原因分析（1）网络中存在的计算机病毒目前压气站站控网络中的控制系统较多，包括SCADA系统、ESD系统、压缩机控制系统、本特利振动控制系统等，涉及到的控制计算机也相应地很多。许多场站都或多或少的有过将不安全的移动存储设备直接到控制计算机上使用的情况，致使计算机有不同程度的中毒情况，病毒又会在网络中传播蔓延，损耗大量的网络带宽，引起网络堵塞，引起广播风暴。曾经在SCADA系统上位机杀出的病毒中就有很多的后门和蠕虫病毒，如Backdoor.SdBot.wgb、Worm.Lovgate等，这些病毒在站控网络中很有可能影响HIMA Remote

45、 I/O模块的正常运行。（2）网络环路形成的网络风暴HIMA公司认为场站之前的站控网络里HIMA F30模块的两个网口分别接到两台交换机，这两台交换机之间又用一根网线连接的方式，形成了一个物理上的环路，有可能造成网络风暴，进而影响HIMA模块的正常工作。结合表2.1进一步观察会发现，ERROR机率较高的HIMA Remote I/O模块为F3 DIO 20/8 02型，而F3 DIO 20/8 01型ERROR的情况相对要少，F30控制器模块则没有ERROR过。下表为各站HIMA Remote IO型号：各站HIMA Remote IO原先的型号统计站名HIMatrix F3 DIO 20/8F3AF3BF3CF3DF3EF3FF3GF3H轮南站0102010102020202四道班站0101010201/红柳站0101010102/玉门站0101010202/中卫站0101010102/靖边站01010102020202/结合HIMA公司的意见，原因分析如下：首先需要对HIMA Remote I/O模块硬件结构进行了解，F3 DIO 20/8 01型和F3 DIO 20/8 02型的硬件结构：