[FUN] Interlocking in Pulp Mill

[Stephen Mitschke]

Dear friends, Anyway, thanks again for your interest and help on the subject. Ok, I will explain one example of interlocking in Pulp Mill application,this case is in Delignification area, but we have several others if youneed: - A pressure switch related to a Hydraulic Unit actuating in low pressure(or also a temperature switch actuating on HH) generates an interlock; alsothere is a level transmitter that measures the level of the hydraulic unitand interlocks with LL; - The interlock(s) actuate a high pressure pump for turning it off, and atsame time, this interlock needs to close a control valve of the hydraulicunit's press - The safety requirement requires that after the interlock, the controlvalve actuates on a maximum of 0,5 sec. Then we have: - pressure switch (or temperature switch): connected to a conventionaldiscrete input card (or in the DC302 in case of SMAR); - level transmitter: connected to the H1 segment - pump: connected through Profibus interface between the Intelligent MCC andthe host controller (DCS Controller or LC700 from SMAR); - control valve: connected to the H1 segment. Related times: - H1 time for reading the level transmitter and actuating a PID for thecontrol valve also in the H1 segment (380 msec considering the PID runningat the H1 and having no more than 4 devices on the H1 segment); plus timefor checking if interlock actuated or not (logic running in the hostcontroller - normally 200 msec also using high scan); plus processing cyclebetween H1 segment and host controller, plus feeedback of the pump (viaProfibus to the controller) to confirm that the pump turned-off (safetyrequirement before actuating the control valve). Total cycle ??? (probablymuch more than half second). * There is several other interlocks between discrete signals and controlloops and also between control loops and motors. ** There is also another important requirement, that probably will requireinterlock running in the controller: Automatic Start/Stop Sequences: as anexample, the operator gives a command on a display switch, and a sequencebegins, for example a motor is turned on, a control loop changes from Manualto Auto and a control valve is positioned for 50%, interlocks are verifyied,and one on-off valve that feeds some material or fuel is opened (in thiscase there is no critical requirement of scan, but since it is a complexlogic, including also timmers and counters, etc, it seems to me that needsto be done at the controller level - this is my question since allchemical/petrochemical/pharma applications also have sequences or batchesand they, of course, involve discrete and FF devices, and they areimplemented using FF ?? Unless, that seems to be the real fact, that they donot need fast execution cycles or do not have critical interlocks betweendiscrete sensors and FF devices) ?? *** Other problem that seems difficult to solve with FF is the optimizationpackages plus self-tunning (normally Pulp Mills use Optimization Packagesthat are supervisory controls running over the basic controls), this meansthat the supervisory controls can run on a separate PC or also inside thecontroller but since the cycle is not syncronized with the cycle of the H1,also using a moderate and restricted derivation action, it will be difficultto tune the loop (then it is necessary to run the loop in the controller andthen cycle times goes up). Best Regards, PS: Tomorrow morning I am going to a meeting in SMAR-Sertãozinho-Brasil, fordiscussing also these items and verifying other points and references ofsimilar applications. Antonio ToméJAAKKO POYRY TECNOLOGIA LTDA

[Stephen Mitschke]

Here are some thoughts that might help.1. This interlock requires two cycles. The first cycle to verify theconditions to determine that the shutdown must occur (stop signal to thepump) and the second cycle confirming that the pump has actually stopped (sothe valve can be closed). I assume you will shut down the Fieldbus valvethrough the TRK_IN_D input of the PID block? The logic can be executed in aFlexible Function Block. Since the valve sits on the Fieldbus, it will beclosed on the second cycle, it does not matter where the logic is done. Withdiscrete input from pressure and temperature switches in an H1 I/O box, theinterlocks for stopping the pump are done in the same (first) cycle as thelevel is communicated. The second cycle the logic checks the permissive toclose the valve (if the pump has indeed stopped) and communicates the stopsignal. It may not make much difference running the interlocks and doingdiscrete I/O in a central controller, or on the bus. Most systems, includingSmar SYSTEM302, let you chose if discrete I/O shall be of the centralizedI/O-subsystem type or distributed on the Fieldbus, and if control shall bethe shared processor type or decentralized on the Fieldbus. Of course speedis not the only issue. Single loop integrity, and maintaining a "pure"Fieldbus strategy may be other issues.2. Apart from doing it in the central controller like you suggested,I see two additional possibilities. The Flexible Function Block (e.g. asimplemented in the Smar discrete I/O box you mentioned) does include timersand counters in addition to the Boolean logic, and should therefore be ableto solve most of your problems. Since the specific interlock you mentionedconcerns the operator interface, you can most likely solve it through asequence in the process visualization software too.3. Many advanced multivariable control optimization solutions aresince the past few years done in computers accessing process I/O through OPCor equivalent across one or more layers of networking. Many times the closedloop control is handled by PID controllers in the basic control systemcloser to the process, to which the optimization package write cascadesetpoints and tuning parameters etc. Since these updates are not closed loopcontrol (at least not the "inner" fast loop) they are made at a relativelymoderate pace. Thus some "jitter" resulting from aliasing between thecontrol loop cycle and the optimization cycle does not matter. The case isthe same regardless of the underlying architecture being DCS, PLC orFieldbus.If we do look at simple closed loop control it is important thatthe PID is in synch with the I/O scan. Foundation(tm) Fieldbus handles thisexceptionally well because unlike other protocols, Fieldbus consists of bothcommunication and the control strategy programming language. For other busesthe communication is not synchronized with the execution of the PID in thecontroller, resulting in jitter which means varying dead time and the tuningproblems you mentioned. For Fieldbus, there is a schedule that paces allclosed loop execution and communication resulting in perfect synchronism.However, when fast closed loop execution is done outside the Fieldbusenvironment there might be a jitter problem. Therefore, when Fieldbus isused, but closed loop PID is done in a centralized controller, make surethat this controller also uses standard Fieldbus blocks and is part of theFieldbus schedule (as opposed to free running proprietary language).SDS,Jonas Berge, Smar

[Stephen Mitschke]

Dear Ian/Jonas and others that send answers, Thanks for the help. I had a meeting on Nov.08 with SMAR Brazil people (Mr.Libânio, César, Metha, Fábio and others) and it was very helpfull, we madean exercise of times involved in the interlock considering the SMAR system,and including schedulled and non-schedulled messages and considering theinterlock being solved in the DFI Link Device with FFB blocks (we did notused the DC module with I/O capacity and logic in the H1 segment because its100 msec was slower than the DFI), and the conclusion was 365 msec for 1closed loop, 370 mesc for 2, 430 msec for 3 and 490 msec for 4 loops. It was what I was expecting since the Link Device is fast and also otherequivalent solution with PLC (like the one that SMAR has and used in someprojects for faster scan). The problem is just when you go to DCS suppliersthat do not have fast controllers and also none has discrete I/O solution onH1 and also are not using yet the FFB blocks. We are going to have a meeting with Emerson next monday to discuss the samesubject and they will demonstrate a physical configuration and programmingon a demo for a complete evaluation. Our schedulle for wourlwide visits is not defined since we did not find anyreference that used fast scan as 500 msec. I would like to know if someusers used in a similar aplication an hibrid solution (like 4-20mA for thespecial fast loops, or used just one loop in the H1, or what they made). For optimization and self-tunning it seems that it will not be a problem asJonas said and we investigated. Best Regards, Antonio ToméJAAKKO POYRY TECNOLOGIA LTDA