金华燃机联合循环DCS系统调试中遇到问题的解决方法

1、工程概况 金华燃机扩建工程规模为1x180MW（1 x S109E）燃气-蒸汽联合循环发电机组，燃机控制系统采用GE 公司的MARKV；其余热发电部分控制系统使用北京贝利控制有限公司的Symphony系统，另外还配到MARKV、化水车间和SIS系统的接口。其中燃机MARKV的调试主要由Ge公司承担；浙江调试火电调试所承担了余热发电部分ＤＣＳ系统的调试工作，具体工作有系统硬件检查、通道测试、软件检查、逻辑确认以及自动投用等，涉及ＥＣＳ、ＤＡＳ、ＳＣＳ、ＭＣＳ、ＤＥＨ和ＴＳＩ等系统。 2、系统简介 金华燃机余热发电部分 ABB Symphony系统有14只机柜、5台操作员站、一个工程师站、网络服务器、打印机和相关的网络接口等设备，具体连接见图1（Symphony系统连接图）。 图１、Symphony系统连接图 Symphony系统采用了以下三层独立的环型网络和总线网络结构： 1) 过程数据管理层——控制网络Control Network（Cnet） Cnet是一个无主站、首尾相连的环型通讯网络，最多支持250个节点，两相邻节点间距离可达1000米。数据高速通道由一对冗余同轴电缆构成，单向串行通讯，通讯速率高达10M波特。 2) 过程控制数据层——控制通道Contrl Way（C.W） C.W是一个HCU内通讯用的串行通讯链，最多支持32个多功能处理器（MFP）、模拟主模件（AMM）或网络处理模件（NPM）间的信息交换，通讯速率可达1M波特。 3) 过程I/O数据层——I/O扩展总线I/O Expander Bus（X.B） X.B是一个NPM内通讯用的高速并行通讯链，最多支持64个I/O子模件与多功能处理器模件（MFP）或模拟主模件（AMM）间的数据通讯，总线线宽为8个数据位，通讯速率可达0.5M波特。 3、 调试过程：金华燃机余热发电部分DCS整体调试，从2004年12月16号DCS系统首次授电，到2005年3月30号，72小时动态移交，整个调试时间历时4个半月，期间我们修改了CRT控制画面500多处，发现软件设计缺陷800多个，其中最大的问题是各个专业之间的接口连接，例如ECS与电气设备的接口，DCS与DEH之间的接口，由于厂家在编制控制软件时，为了节约时间与成本，很多软件都不是根据现场工程实际编制的，大部分都是照搬以前做过的类似项目，把软件原封不动的拷贝过来，然后发现问题在现场修改，由于软件很多部分与现场实际情况不一致，所以修改的工作量比较大，现把工程调试中遇到的一些问题按各个系统(DCS、DEH、ECS)分类总结一下，以供参考。 3.1 ECS调试 3.1.1 ECS接点容量问题 在ECS调试过程中，发现很多电气开关经过CRT几次合分之后，ECS控制继电器触点就有烧糊烧熔现象，经过与电气专业沟通了解：一般的高压电气开关都是直流电控制,回路电流一般都在5A,而设计的ECS控制继电器触点容量最多只能通断3A的直流电,因此不能满足现场控制要求,必须增加触点容量大的中间扩展继电器； 3.1.2 脉冲时间长度 原ECS内,软件设置电气高压开关控制接点的脉冲时间长度在2秒左右，实践表明脉冲时间过长，过长的合分闸时间,会使电气控制回路储能线圈长时间得电,引起线圈烧毁，因此合理的脉冲宽度应在250毫秒左右 。 3.1.3 逻辑修改发电机同期问题 由于上汽厂的高压调门动态特性非常差(调门本身漏汽比较严重)，引起汽机在同期并网过程中，转速调节不稳,又有ＤＣＳ配备的同期卡捕捉并网同期点性能较差，导致汽机冲转后并网时间过长；又从可靠性角度考虑，DEH配备了同期卡,没有按照冗余配置,可靠性不高，万一损坏就会导致整个机组无法并网发电。由于整个电气主系统的设计是，在发电机出口及主变高压侧同时设有断路器，因此我们根据实际情况，修改了ECS内部逻辑，在发变组断路器没有合闸的前提下，先手动合发电机出口开关，然后利用发变组同期装置捕捉并网同期点快捷的优势，通过合主变高压侧断路器来实现并网(同期条件满足后,ECS发命令合主变高压侧开关)，，这样就节省了汽机并网时间，同时也给运行人员提供了另一个后备并网的设备。 3.2 DEH:金华燃机汽机部分DEH软硬件由上汽厂提供。由于上汽厂的DEH也参用了与DCS同一厂家的硬件，因此DEH与DCS本身来讲是一个整体，同在一个环网内,不存在网络通讯接口的问题，采用统一的组态软件,减少了维护人员的工作量,这是它的优点,可也存在一些问题,主要问题是: 3.2.1 DEH伺服卡抗静电能力极差 ABB提供的硬件总体来讲可靠性非常高，但是它的汽机DEH伺服卡非常娇贵，由于没有采用卡件表面封装技术,使所有卡件原器件都裸露在空气中,因此一不小心，人体的静电就会把它击穿，所以损坏率极高,我们调试期间先后更换了2块DEH伺服卡。 3.2.2软件组态问题 3.2.2.1 ETS逻辑缺陷 ABB DEH内部软件组态按功能分为ETS、OA、ATC 3大部分。由于设计失误，厂家设计ETS逻辑时采用的是反逻辑（如图2）；即正常情况下3个ETS跳机信号都为1,取反后变成0,经逻辑3取2后输出还是为0，这样跳机信号就不触发.可当组态软件初始化下装时，内部实时数据库内数据初始为零，即三个ETS跳机信号都变成了0，取反后都变成了1，经逻辑3取2后跳机信号触发为1，这样经过一次软件下装，所有的ETS保护信号全部触发，引起跳机.因此这种设计缺陷给用户正常运行时，软件在线下装带来很大风险。 3.2.2.2 同期卡逻辑 由于设计疏忽，DCS与DEH厂家两边都没有考虑做同期卡的控制逻辑，业主在开设计协调会的时候也没有很好的沟通，所以同期卡的逻辑是到现场现做的。经过与电气专业配合，我们完成了同期卡逻辑的设计.具体如下: a) 汽机已挂闸 b) 汽机转速在2985-3015转之间 c) DEH在自动方式,且已进入自动同期 d) 发电机没并网 e) CRT选择同期装置已投入,系统侧电压与发电机侧电压已加到同期卡两端 以上条件都满足后,操作员在CRT上按下自动同期按钮,开始30秒钟的自动同期过程,同期卡根据两端电压的频率幅值与相位差,自动发命令给DEH转速增减脉冲，通过调整汽机转速,来调节频率与相位,发增磁减磁脉冲给励磁机,来调节发电机电压幅值.当两者匹配时,同期卡就自动发命令去合发电机开关,以实现并网. 但在汽机第一次并网时遇到了很大的麻烦，当汽机转速到达并网转速3000转时,DEH根据同期卡发出的升速降速脉冲去控制汽机转速，原本应该是一个脉冲汽机变化一转，但由于DEH程序内阀门特性曲线与高压调门的实际特性差异很大，导致调节过头，转速波动很大，大约有上下30转左右的偏差，导致机组无法并网，后来经过研究，我们通过修改DEH里面转速控制器的PID参数，调整比例系数, 减少高压调门的灵敏度，降低调门振荡幅度，使转速波动降为最低点，终于实现了并网。 3.2.2.3 OPC电超速逻辑修改 由于上汽厂的汽机高压调门严密性不好，按照原有逻辑当发电机甩３０％以上负荷时，只要OPC电超速保护动作，通过关闭高压调门，就能抑制汽机转速的再次上升．但实际试验结果是：由于汽机调门关闭不严，漏气严重，即便调门关闭后转速依旧上升，一直到３３００转引起DEH电超速保护动作，引起汽机跳闸.跟据这个情况。我们把OPC电超速逻辑修改为OPC动作之后关闭主汽门直接跳机。这样也是出于机组安全方面的考虑。 3.2.2.4 ETS动作的可靠性分析 整体来讲由整套系统汽机DEH还是比较成功的，但是我们对它的ETS通讯快捷性以及可靠性还是心有疑虑，主要是感觉整个通讯环网数据传送速率偏低以及环网内所有卡件的逻辑计算时钟步序尚未统一。因为一般来讲,数据通讯速率偏慢直接影响信号的传送，而卡件时钟步序差异，直接导致信号前后触发的次序，更何况对于大型机组来讲满负荷跳闸时，转子的飞升时间都是以毫秒级计算的，从发电机出口开关的分闸到数据传送到DCS内部来运算处理，至少要几个运算周期,再到发指令去卸EH油压,关汽机主汽门都需要一定的时间。如果这些时间段加起来比转子飞升到危机遮断器动作时间还要长，那ETS的电超速保护就失去意义了，而且对机组的安全运行也带来很大隐患。所以一般专业化的成熟的DEH厂家，一般在设计汽机ETS保护时都是直接采用硬逻辑卡或一对冗余的PLC来实现，这样所有采样进来重要的跳机保护值就不用送到DCS内部去运算处理，直接在硬逻辑卡或PLC里处理完成直接出口了，这样也不用考虑通信数据堵塞的问题了，可以保证ETS动作的快捷性。事实也证明这套系统ETS的确存在严重的时间滞后，我们做甩满负荷试验时就发现，一甩负荷，从发电机开关从合到分，再到汽机跳闸信号返回一般都在800毫秒左右，而此时的汽机转速都要冲到3260转以上，离危机遮段器动作的转速3300就一步之遥，这就是ABB DEH的不足之处。 3.3 与其他DCS厂家相比 ABB这套DCS与别的DCS厂家（像西门子、新华、和利时，FOXBORO）相比有它明显的优点： 优点：（1）硬件（除了伺服卡）可靠性精确度抗干扰能力都比较高，整个调试过程中，除了由于电动门就地端子盒进水，220VAC强电串到DI卡烧了端子板上的一个通道外，没有发生其他硬件故障。（2）组态与绘图软件在WINDOWS环境下运行，界面友好，操作便利，而且组态功能块种类齐全，功能强大，并且支持图形化组态，非常直观，给编程与维护人员带来很大便利。 缺点：（1）软件内部没有专门调试强制功能，所有强制功能必须依靠逻辑实现，强制后无明显的标志(例如新华DCS强制后受强制的功能块的颜色会变成紫色),如果调试人员不做记录很容易遗忘,调试起来很不方便；（2）没有特定的专用功能块。BAILY的DCS没有完整的类似于新华和和利时等DCS厂家开发的例如象电动门电动机专用的功能块，对于一个电动门控制必须要用专用的类似宏一样的子程序来完成，并且不是一个宏就能解决所有的各种类型的电动门控制，带中停的电动门与全开全关的电动门必须选用不同的宏程序；其他的象MFT首出记录功能块、子组级顺控功能块、热力学计算块更是没有了，如果