Re: [foxboro] Restricting the operators access to PID blocks

Hi Andriny and Sivaram,

Yes, this can get pretty complicated. What I would normally do is (considering 
that you have the time and the process allows some DCS changes on the run):

- Use a SWITCH to toggle between any Master controllers and the APC. Then 
connect the output of the SWITCH to the RSP. Then you only need to make sure 
you have all TRACKING options correctly setup and you will have the bumpless 
toggle of the RSP of the PIDE/A/X.

- Also this will allow the operators sets the L\R to L state and change the SP 
when they need. 

- You also need to make sure that you APC is reading the L\R state of the 
controller and automatically disable the MV (on the APC) if LOCAL mode is 
detected (this is one advantage in using this method, since if leaving always 
the PID in LOCAL MODE you will never know if the MV is online or offline in the 
APC controller).

- You probably also want a SEQUENCE block to monitor the MVs and toggle the 
SWITCH block back to the Master Controller when the APC turns the MV off (you 
do not want to rely in the APC for that). You can use the same sequence block 
that servers as a Watchdog and puts all back to NORMAL state if the 
communication is lost between the APC and the DCS.

Again, this can get complicated, but if well implemented will work well and you 
will not need to worry about anybody bypassing the SPT of the APC (ex: by using 
the detail block display).

Best regards,

Ricardo P. Abech
Chief Software Architect
 
LimeWare Company, Inc.
[USA phone]: (408) 786 5140 
[USA mobile]: (907) 687 8113
[Brazil phone]: +55 51 3372 0104 NEW!
[Brazil mobile]:  +55 51 8192 9723
[email]: abech@xxxxxxxxxxxxxxxxxxx
[http://]: www.limewarecompany.com

**The contents of this email are intended for the named addressee only.   This 
transmission may contain information that is privileged, confidential, legally 
privileged, and/or exempt from disclosure under applicable law. If you are not 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or use of the information contained herein (including any 
reliance thereon) is STRICTLY PROHIBITED.   If you received this transmission 
in error, please immediately contact the sender and destroy the material in its 
entirety, whether in electronic or hard copy format.**
Please consider the environment before printing this email.




-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On 
Behalf Of Andriny Bt Rusman (R&T/PETH)
Sent: Thursday, July 30, 2009 4:07 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Restricting the operators access to PID blocks

Ricardo,

That idea of using a customised faceplate is cool.  I think it is a very simple 
way if you really don't want the operators to write to the setpoint without all 
the logics required. I do have an issue using this way when an external 
controller is writing into the PIDE.

To build on Sivaram's case, say we want to restrict it because another external 
controller, e.g. an APC controller will write the setpoint to a Manipulated 
Variable (MV), i.e. typically a PIDE/A.  I know PIDE/A SPT para is con/no-set, 
so this means APC can write to the SPT para.  Is this an accepted practice?  

Additionally, if we use the customised faceplate & if operator wants to take 
back control of the MV during an upset, won't the operator have to go to an APC 
MV list page to enable the SPT change?  This means he has an extra step to 
think about during an upset instead of just going to the controller faceplate & 
take back control (by putting it to Manual or Local).

Best regards,
Andriny Rusman
Staff Engineer,
Advanced Process Control,
Group Technology Solutions,
Level 8, Menara Dayabumi
Phone: 03-2783 6317
Petronet: 8-333-6317
Fax: 03-2783 6499
email: andriny@xxxxxxxxxxxxxxx

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On 
Behalf Of Kevin Fitzgerrell
Sent: Thursday, July 30, 2009 9:57 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Restricting the operators access to PID blocks

Hi Sivaram,
Alternatively, you can connect the RSP and the LR parameters to other blocks
and use those as your master - CALC block works nice for locking down a
group of controls.  When your master block sets the LR of the PID to 0, the
operator can change the setpoint as desired.  When LR is set through it's
connection to 1, the RSP comes from the master and can't be changed in the
faceplate.

This can then be documented in your control logic.

This method gets a bit more complicated for inner loops in a cascade
control.

Similar to Ricardo's point, most of the plants I've worked for don't give
the full faceplate and select control to operators - we normally have loop
specific overlays that give only the desired level of control to operations.

Cheers,

Kevin

On Thu, Jul 30, 2009 at 10:45 AM, Ricardo Abech <abech@xxxxxxxxxxxx> wrote:

> Hi Sivaram,
>
> You can do what you want by using a customized faceplate, where the you
> have 2 SPT fields that toggle visibility depending on the condition trigger.
>
> When the condition is true, the SPT field has the PICK configured and then
> SPT changes are allowed. If The condition is False, then is READ ONLY and no
> SPT changes can be performed.
>
> I hope that helps.
>
> Best regards,
>
> Ricardo P. Abech
> Chief Software Architect
>
> LimeWare Company, Inc.
> [USA phone]: (408) 786 5140
> [USA mobile]: (907) 687 8113
> [Brazil phone]: +55 51 3372 0104 NEW!
> [Brazil mobile]:  +55 51 8192 9723
> [email]: abech@xxxxxxxxxxxxxxxxxxx
> [http://]: www.limewarecompany.com
>
> **The contents of this email are intended for the named addressee only.
> This transmission may contain information that is privileged, confidential,
> legally privileged, and/or exempt from disclosure under applicable law. If
> you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is STRICTLY PROHIBITED.   If you
> received this transmission in error, please immediately contact the sender
> and destroy the material in its entirety, whether in electronic or hard copy
> format.**
> Please consider the environment before printing this email.
>
>
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Sivaram Murugan
> Sent: Wednesday, July 29, 2009 10:14 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] Restricting the operators access to PID blocks
>
> Hello ,
> We would like to restrict the operators from changing the set points of
> some
> PID blocks , based on some condition.
> Say , if the condition is true , No change in setpoint allowed - but still
> the operators should be able to open and see the face plate.
> If the condition is false , the operators should be able to change the set
> point.
>
> Any idea ,how it can be done ?
> Thank you in advance.
>
>
> -Sivaram
>
>
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>

 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.28/2259 - Release Date: 07/24/09 
18:24:00


DISCLAIMER : This e-mail and any files transmitted with it ("Message") is 
intended only for the use of the recipient(s) named above and may contain 
confidential information.  You are hereby notified that the taking of any 
action in reliance upon, or any review, retransmission, dissemination, 
distribution, printing or copying of this Message or any part thereof by anyone 
other than the intended recipient(s) is strictly prohibited.  If you have 
received this Message in error, you should delete this Message immediately and 
advise the sender by return e-mail. Opinions, conclusions and other information 
in this Message that do not relate to the official business of PETRONAS or its 
Group of Companies shall be understood as neither given nor endorsed by 
PETRONAS or any of the companies within the Group.
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 

 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: