当前位置: 首页 » 技术文献 » 炼钢文献 » 炼钢工艺 » 正文

转炉二级系统的优化

放大字体  缩小字体 发布日期:2021-05-24  作者:吴长河  浏览次数:471
 
核心提示:【摘要】转炉二级系统为转炉炼钢的重要过程控制系统,负责模型计算、与一级和与三级的通信控制。该文论述了转炉二级系统存在的主要问题及对这些问题的优化过程。 【关键词】转炉二级;系统优化;系统资源
 转炉二级系统的优化

吴长河

(鞍钢股份皱鱼圈钢铁分公司设备炼钢部 营口 115007)

【摘要】转炉二级系统为转炉炼钢的重要过程控制系统,负责模型计算、与一级和与三级的通信控制。该文论述了转炉二级系统存在的主要问题及对这些问题的优化过程。

【关键词】转炉二级;系统优化;系统资源

1  转炉二级系统简介

转炉二级系统软件部分为德国kuttner公司开发的OTCBM应用程序,硬件部分服务器主机采用的是美国容错双机热备。主要分为三部分,第一部分采用IBM公司的MQ中间件与三级通信,接收三级的生产计划、钢水铁水成分等重要生产数据。同时将生产实际数据以电文的方式传递给三级。第二部分是二级系统的OTCBM应用程序,通过在二级画面进行操作,给一级发送指令进行过程自动化控制。第三部分是与一级通信,采用的是si-mens 的simatic net软件配置与一级PLC的通信,实现自动化控制与一级生产实际数据的采集工作。

2存在的主要问题

(1)系统资源不释放,资源占用率居高不下问题。转炉二级服务器运行7天就会发生无法自动上传数据或者丢失部分数据的现象,多次联系外方专家调试都无法查明原因,只能在运行第6天进行重启以保证生产的正常进行。在转炉服务器重启的过程中,3个转炉都需要进行手动生产,操作工手动补录数据,影响生产节奏和生产数据统计的准确性。同时由于手动生产,二级系统会认为转炉处于停机状态,会将停机信号上传给三级,三级收到停机信号后宜接上传给四级ERP系统 而操作工又将当前炉次的生产数据手动通过三级界面录入上传ERP,因而在分公司总调度室的ERP生产实际统计图中会岀现当前炉次即为生产状态又为停机状态的矛盾现象,影响分公司对生产实际的统计。

(2)转炉二级系统终端机原设计为远程连接操作服务器模式,导致服务器资源使用率过高,服务器卡顿现象,数据传输延时,终端机操作反应慢等现象时有发生。

转炉二级终端机原设计为HP瘦客户机,该机器无硬盘、无风扇、自带XP超级精简版系统,仅仅可以进行远程连接操作。原二级系统设计为10台终端机同时对服务器进行远程连接,10个不同的账户同时对服务器进行操作,后因为实际生产需要,海边废钢和铁水倒罐不使用二级系统,且机房二级终端机和自动化炼钢二级终端机不是经常在线,造成6台终端机经常在线操作服务器,2台终端机偶尔在线操作服务器,峰值会有8个账户同时操作二级服务器,随着远程连接用户在线时间的增长,资源的占用率越来越大,最后导致只能将二级服务器重启释放资源。

(3)与三级系统通信存在设计缺陷,导致一定时间后二三级通信故障。

缺陷一:二级系统无法正常接收三级系统下发的作业计划,生产无法继续进行。外方在设计之初是想将二、三级通信电文产生的报告信息放在WR.QM管理器的WR.R队列中,但是经过MQ命令查询,外方根本就没有建立WR.QM管理器,所以导致此报告信息(report message)被放到了 MQ自带的死信队列(dead-letter queue)里。当达到一定时间后,死信队列中的信息会以10 000条为一次被加载到与三级通信的MQ管理器(BYQKT. QM)的队列中。具体缺陷如图1所示。

图片1 

缺陷二:二、三级通信彻底中断,计划无法下达,数据无法采集。

MQ自带的死信队列(dead-letter queue)里面的信息是不断的往里面存储,却从来不删除,当死信队列(dead-letter queue)中的数据量过大(超过几十万条),会导致MQ管理器(BYQKT.QM)的接收通道一直处于读取死信队列中报告信息(report message)的状态,系统资源使用率居高不下,最后资源耗尽,与三级通信的MQ管理器(BYQKT.QM) 会自动停止,导致与三级通信彻底中断。

缺陷三:无法查询2天前的MQ运行情况。通常MQ的日志不需要设置备份,但是转炉二级系统二、三级通信因为前面两个缺陷导致MQ日志中包含了大量的无用重复信息,最多保存2天的 信息。

3优化过程

3.1 对服务器进行优化

(1) 服务器原有硬盘分区不合理,系统盘所占空间非常小,使用率过高。在保证原有分区数据不受影响的情况下,对硬盘的分区大小进行修改, 增加系统盘所占用的空间,增加数据读写操作所需空间,减少页面访问错误的发生,保证系统运行稳定。

(2)对服务器数据库内存占用上限属性重新设置,原服务器数据库内存占用上限为512MB,无法满足数据库对内存运行空间的需求,现将其调整为1GB,运行中观察正常的峰值大概需要820MB左右的空间。

(3) 对服务器的数据库超时连接属性进行重新设置,服务器运行一段时间后总会报一个数据库连接超时的错误,影响二级正常运行,将数据库连接超时属性设置为连接超时无限制后此问题再没有出现。如图2所示,将600改为0即为无限制。

图片2 

经过上述设置的调整,转炉二级服务器运行时间可以延长到42天左右。在这42天内,找到一个特定的时间段“其中一个转炉定修,一个转炉补炉”,等待正在生产的转炉出钢结束后将二级服务器重启,只有这个特定的时间段(8分钟左右 内进行重启操作,才能保证生产数据不丢失,保证分公司总调度室的ERP生产实际统计图中不会出现当前炉次即为生产状态又为停机状态的矛盾现象。

3.2用普通计算机代替二次终端机

经过长时间对外方应用程序的研究,发现此应用程序是可以改装在普通计算机上运行的。只需要以下两个步骤:

(1) 将转炉二级终端更换为一台普通计算机,在计算机上安装一个微软的.net2.0运行环境。

(2) 将数据库配置文件修改为网络数据库。具体操作如图3所7K,将value的值由localhost改为服务器的IP地址192.2.12.2,客户端的HMI画面就可以通过网络访问服务器的数据库通过以上设置就实现了所有对应用程序的操作都在本地终端机上操作,占用客户机资源,而数据通过网络传输到服务器的数据库中,间接的实现了 C/S(客户端/服务器)模式,大大减轻了服务器 的资源使用率。

图片3 

3.3删除原有死信队列信息

(1)编写批处理程序定期(一周)自动将死信队列(dead-letter queue)里面的信息通过MQ命令全部删除。

(2 )将原有的死信队列(dead-letter queue )里面的信息通过MQ命令全部删除。

通过cmd命令启动命令行一>输入runmqsc命 令启动队列管理器-输入diS(*)查看所有的队列-»输入CLRAR QLOCAL(SYSTEM.DEAD.LETTER. QUEUE命令清除所有死信队列里面的信息。

(3)编写批处理程序自动将MQ的日志文件按日期备份到机房终端机中,如图4所示。

图片4 

4实施效果与验证

(1)系统运行更加稳定,运行时间得到延长(从每6天重启一次延长到42天重启一次),减少转炉手动操作的次数,使数据统计更加准确,分公司ERP系统对生产实际统计矛盾等问题不再出现。

修改前:服务器每6天重启一次,重启次数为61次,每次重启影响3个转炉,需要手动操作炉次总计为61 x 3=183炉次。

修改后:服务器每42天重启一次,42天内只要保证在特定的时间进行重启操作,就会使对生产的影响降到最低。

(2) 服务器使用率下降明显,正常使用不再岀现卡顿现象,不会岀现数据传输延时、终端机操作反应慢等现象。

修改前:CPU使用率平均75%左右,内存使用率峰值为85%左右。

修改后:CPU使用率下降到平均50%左右,内存使用率下降到峰值为70%左右。

(3) 修改后,现场生产至今未出现因为此问题导致的二、三级通信问题。 

 
 
[ 技术文献搜索 ]  [ 加入收藏 ]  [ 告诉好友 ]  [ 打印本文 ]  [ 关闭窗口 ]

 

 

 
关于我们 联系方式 付款方式 电子期刊 会员服务 版权声明 冀ICP备13016017号