Backup LAS - response for VickyWu

[Robin Burnikell]

Hi Vicky,

Your thread had become locked for some reason??

I have completed several batch projects using FF and have the following comments for you.

To answer your question as is, for the circumstances you describe (all control in host and FF devices being used as I/O unit only with no local control or other means of supervision) then backup LAS is not strictly neccessary becuase if you loose the DCS/PLC (or communication with it) you loose all control and supervision anyway.

HOWEVER!!! none of my FF batch projects were designed in this way, hence I have to ask why you wish to design your system to be this way as you are ignoring many of the benefits of FF and reducing the processes fault tollerance.

For instance in the batch projects I have completed for Smar all control was in the field, the host controller (our DFI302) was purely used as the gateway for transfering batch data to the SCADA system for logging and enabled SCADA operators to have an overview of the process and if needed shut down the process remotely.

However the recipe selection, the starting stopping and running of the batch was controlled locally by operators and Smar H1 devices with no need for the host controller.

For instance using a FF remote digital I/O controller (such as the Smar DC302, see www.smar.com/products/dc302.asp (http://www.smar.com/products/dc302.asp)) along side FF instruments with wide function block support (e.g. all smar devices have PID Control, Arithmetic, Integrator, Input Signal Selector, Characterization, Splitter, Analog Alarm, Setpoint Generator, Timer/Logic, Lead Lag, Output Signal Selector and Dynamic Limiter, Constant Block, Diagnostic Transducer Block, Advanced PID, Density Block) you could probably move all control into the field devices, save on installation costs (no discreet wiring back to the DCS/PLC) operators can select the recipe required, start and stop the batch etc. The Smar H1 devices have enough distributed memory and control functionality to run the batch on their own without the host.

Using this stratedgy you can increase fault tolerance level to the highest possible, e.g. the control is then only reliant on the active elements (sensors and actuators, not also reliant on the DCS/PLC).

Even in circumstances where the process has large numbers of batch recipes and therefore the H1 field devices run out of memory to store all the recipe data, you can design the system such that you are only reliant on the Host controller for provision of the recipe data. Once the recipe has been selected, and the process started, if you have all your control at H1 level, if you loose the Host controller this will not affect the completion of the batch.

Hope this helps?

Robin

[Dirk Diggler]

Robin,

I hate to hijack someone elses post and change the topic, but, what if we changed Vicki's question a little bit. If we consider a scenario where we need to execute a number of complicated sequences, interlocks, and batch strategies in a continuous control environment. Since this is continuous control, the process interaction can become complicated and sequences and interlocks need to execute across segments. Interlocks also are required to interact with discrete I/O to control motors, etc. I'm confused as to how this is accomplished without a Host Controller.

From your experience, how does the architecture change (if at all) to account for this situation which is pretty common in refineries, chemical plants etc.

DD

[Robin Burnikell]

Hi Dirk,

I don't see it as hijacking or changing the subject, I think you have a very valid point, my comments were taking a micro-view of an individual part of a process.

In most systems there are some control strategies that require synchronisation of data across either local H1 channels or wider plant synchronisation. This is where FF Linking devices and FF HSE comes in, we use our DFI302 to provide this functionality, e.g. http://www.smar.com/PDFs/Catalogues/SYSTEMARCE.pdf

However, even on plants that make frequent use of control strategies that require interlocking across multiple H1 segments there is normally still many control loops that can be designed to be standalone H1 segments and therefore benefit from the extra fault tolerance.

Thanks for raising the point, it all to easy to answer someone’s question with one thing in mind when others see something completely different.

Regards, Robin

[VickyWu]

Hi All

Our FF projects : some continuous projects and one batch project. This batch process is designing currently. The FDS (function design specification) prepared by DCS vendor mentioned it is not required backup LAS (BLAS) if control is not in field. I was concerned about if some other protective actions would be done by BLAS in addition to keeping control in field. Our case is no transmitters with BLAS near these segments which only have on-off valves and whether we have to assign transmitters with BLAS to these segements.

Basically I like FF concept with control in field. However, up to now (5-year experience) only limited controls (single PID and Cascade) were done in field device. As the control strategies are with interlocks, normally vendor recommeded us to put them into DCS controller because of reducing quantity of read/write between DCS and the field device.

Anyway, thank you for your response. If you have advanced comments on BLAS application or FF special consideration for batch process, please be kind to advise me.

[Robin Burnikell]

Hi Vicky,

I am very interested in your comments about the design your system vendor is proposing. You mention you have segments with only on/off valves (if I understood you correctly). Obviously if you design your segments such that you only Input devices on one segment and output devices on another segment you will always be reliant on something in the middle (Linking Device or DCS/PLC or HSE) to synchronise the loops. Consequently design is the key to reducing across H1 interlocking, however, in many cases there will be a requirement for this, but there are many factors that reduce this requirement.

1) Potential in the devices for control in the field - If you use ff devices that only support limited numbers and types of function blocks you will end up with less control in the field. Devices that do not support logic blocks will be reliant on the Host for providing this functionality. Hence H1 devices should be chosen with this in mind.

2) Does the chosen FF host and FF devices allow for reasonable numbers of FF devices on a single H1 segment - If a control strategy requires 12 devices to implement and you choose a HOST and FF devices that only enable you to have a maximum of 8 devices per H1 segment you will require interlocking over several H1 segments. However, if you use a Host and FF devices that RELIABLY supports 12 or 16 devices per H1 segment you will have fewer loops requiring interlocking across H1 segments. There is a technology in FF called "Multi Variable Container" (MVC) which makes supervision of devices far more efficient and can therefore allow more devices per segment whilst maintaining useable Macro cycle times. To use MVC both the host and FF devices must support it.

3) Is the wiring layout being designed by someone knowledgeable about FF. This is one of my biggest problems here in the UK. I have to constantly remind the EPC design engineers in the UK that they must involve the FF system supplier when designing H1 cable runs. Far to often they design cable runs as they would multi-core cable runs, i.e. design it for minimum cable usage and hook on to any devices located near the cable. In the end it is swings and roundabouts between physical limitations on cable runs and practicality and cost of cable runs. But none the less significant strategy differences arise from just small changes to cable runs.

So Vicky all I can say is in my experience it is a balance between what you have to work with (the end customer often has strong preferences for supplier X's devices because he has used their 4-20mA ones since day dot) and the factors I mention above.

Good luck,

Robin

[jberge]

When you have redundant H1 interface cards is there really a need for Backup LAS? If the primary card fails, the secondary takes over. The chances of both the primary and secondary interface card being down is very small so adding backup LAS on top of that may be overkill. I think these days most medium and large systems go for redundancy.

I think backup LAS only makes sense if you have only a single interface card. This is the rule of thumb we have been using for a number of projects. The Backup LAS then takes over in case the card fails. This may perhaps be particularly helpful to ride through during a short glitch but people may be reluctant to operate blindly for extended periods of time.

Like somebody said or implied, Backup LAS only MAKES SENSE for control in the field - it is NOT A REQUIREMENT. Backup LAS does not make sense for centralized control since the Backup LAS taking over signifies that the centralized controller is down.

In the cases where you want to trip on a fault rather than to run blindly - safety rather than process availability - in this case it is better to NOT use Backup LAS.

For a detail discussion on this, take a look at chapter 10 of the yellow book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" buy online:
http://www.isa.org/fieldbuses

[Hamad_1974]

Hi Jonas,

You mention that if one runs the PID in the DCS or Centralized controller, then it is better not to assign a back-up LAS in the field device. Could you explain why? Could there be any problems as a result of such an action?

We always require a Back-UP LAS in a monitor-only device, and we also require redundant H1 interface cards.

You do bring up a good subject, why would we assign a Back-up LAS in the field device if the PID is runiing in the DCS controller? I am not sure if there's any benefit in doing that? Could you explain?

Thank you

Hamad Balhareth
Saudi Aramco
hamad.balhareth.3@aramco.com

[Hamad_1974]

Dear Jonas,

I guess I am going to answer myself here as I have found the answer to my question:

You mentioned above that: " Backup LAS only MAKES SENSE for control in the field - it is NOT A REQUIREMENT. Backup LAS does not make sense for centralized control since the Backup LAS taking over signifies that the centralized controller is down"

So if the DCS controller fails, then you would want a back-up LAS in the field device to take your process to a safer mode of operation. Remember that if you do not enable a back-up LAS in a field device, then you will not be able to go to a fail-safe mode. The final control element would just freeze at its last position.

I think it is now clear.

Thanks

Hamad Balhareth

[jberge]

No, that is not really what I wanted to say.

Backup-LAS is only used for process availability, it is not related to safety.

If control is done in a central DCS controller and the communication fails (loss of power, short, open circuit, terminator, LAS whatever), the outputs can go to a fail-safe position regardless of backup LAS or not. You don't need backup LAS for safety.

If control is done in the field and the communication fails (loss of power, short, open circuit, terminator, LAS whatever), the outputs can go to a fail-safe position regardless of backup LAS or not. You don't need backup LAS for safety.

If control is done in the field and the LAS fails then a backup LAS will allow control to continue (rather than going to safe state). Backup LAS gives you avilability.

If control is done in a central DCS controller which is also the LAS, and this controller/LAS fails - then backup LAS will do you no good since the controller is not running or is not accessible anyway. Backup LAS is this case does not give you anything.

[Hamad_1974]

Jonas,

You are quite right in the issue above. If there's a power loss to the segment, then the final control element would go to its mechanical fail safe position regardless of whether there's a back up LAS or not. This is a true statement.

Nonethelsss, the following statement is not quite correct: "If control is done in a central DCS controller which is also the LAS, and this controller/LAS fails - then backup LAS will do you no good since the controller is not running or is not accessible anyway. Backup LAS is this case does not give you anything".

Here is the reason why it is not correct:

1- If you run the PID in a DCS centralized controller with no back-up LAS in a field device, then your final control element would simply freeze at its last position upon loss of communication with the DCS controller. Remember this is considered a communication failure and is not similar to a power loss condition.

2- If you run your PID in a DCS centralized controller with a back LAS in a field device, then you could configure your final element to go to a certain fail safe position upon loss of communication with the DCS controller. This is possible with the help of the back up LAS field device.

I guess the miscommunication was about the fact that I meant a communication failure and not a power loss failure. The two situation are quite different.

Regards,

Hamad Balhareth
Saudi Aramco

[jberge]

Dear Hamad,

In the AO and DO blocks there is a "fault state" (fail safe) mechanism. It consists of an option to freeze in last position or go to a predetermined "fault state" position, that you can specify in another parameter, as well as a timeout parameter.

Using this "fault state" parameter you can make your valves go to a fail safe position - even without the use of a backup LAS. What happens is this: when communication is lost for longer than the period set, the output goes to the preset value: typically fully closed or fully opened. This is why I say the backup LAS is not required for safety. Fantastic isn't it?

Take a look at chapters 4 and 10 of the yellow book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" buy online:
http://www.isa.org/fieldbuses

[Hamad_1974]

Hi Jonas,

Thank you for your valuable information and for pointing me in the right direction.

Regards,

Hamad