DCS系统画面数据通讯中止故障缘故原由剖析
DCS系统画面数据通讯中止故障缘故原由剖析
一、装备概况及简介
装置接纳FOXBORODCS控制系统，，，2011年投入使用。。。。。。
二、故障经由
2013年，，，柴油加氢控制器PF1/PF2大部分数据泛起蓝色底色，，，数据变为星号，，，显示为通讯故障。。。。。。
三、缘故原由剖析
（一）历程检查及剖析
1.时代重新启动过FCR02的交流机、交流机/CP的 host 工程师站、替换 过CP、CP 的通讯�？？？？？� split，，，但情形依旧。。。。。。
2.将此控制器替换交流机的通讯口，，，情形依旧，，，因此判断网络上是否保存 对此控制器的大宗数据通讯量。。。。。。
3.通过交流机监控软件审查得知 PF1/PF2 交流机端口的通讯量为正常情形下的 6~8 倍。。。。。。然后重新启动过部分操作员站，，，失效数据的量略有所 镌汰。。。。。。
（二）故障基础缘故原由
1.直接缘故原由：过多的overlay翻开，，，某些overlay虽然关闭，，，可是事情站和CP的通讯链接没有正常释放，，，尚在CP内保存，，，日积月累后造成无用链接量的一直的累计，，，最终使得CP内通讯负荷增添，，，造成CP的通讯梗塞，，，新增毗连无法正常�；；；；袢∈�。。。。。。
2.间接缘故原由：由于是重启历史站造成，，，可是现实上那台历史站只有不到20个CRCS单位的历史数据点，，，更多的是作为OPC的数据源使用，，，因此判断是由于OPC的负荷过多有关系，，，然后重新在OPCServer中审查了所有点，，，删除了一些坏点（即在OPCServer的alias中有，，，可是在现实的CP内没有的点，，，由于当坏点保存时，，，OPCServer会一直在CP内去获取坏点的数据，，，可是由于CP内没有此点，，，最终会造成死循环，，，增添网络的负荷）
3.治理缘故原由：控制系统组态没有实时整理多余的数据请求节点。。。。。。
四、整改步伐
1.按期重启事情站。。。。。。在事情站重启时，，，会在网络上举行广播，，，见告CP释放此事情站关于CP的链接资源，，，通过此种要领可以镌汰由于事情站造成的占用过多CP链接资源。。。。。。
2.ICC组态中删除点的同时删除OPCServer中alias的组态，，，镌汰坏点的保存。。。。。�？？？？Ｋ剂縊PCClient中无用点，，，镌汰OPCServer的获取量。。。。。。
3.期审查交流机监控软件，，，审查哪些CP网络端口的数据通讯负荷量过大或者大于正常的通讯量，，，重启网络上直接获取哪些CP数据的事情站来审查端口的负荷是否转变。。。。。。
五、总结与启示
装置在运行后期应检查数据会见源，，，实时整理无用数据会见源。。。。。。
