Re: [foxboro] Secured Linkages

An observation:=20

No more than one operator should be responsible for changing parameters =
on a given block at the same time. Division of responsibility and =
control room communication are paramount. Remote stations should have =
communication paths to the main control room.

Likewise,  whether sequence block, AP program or third party programs =
such as optimizers, there should be one and only one supervisory program =
changing a given block. An operator should never be changing a parameter =
while a block is in supervisory control. In fact, the operator should =
never be presented with the opportunity to change the parameter unless =
the supervisory state is bypassed or disengaged.

So, that's the ideal world ... that's how the old Videospec used to work =
with computer control (not to say that Videospec was perfect by any =
means) ... worth taking the extra time to build the protections into I/A =
Series displays and applications ... but of course in the real world, =
who has the time?

Peace.

-K

-----Original Message-----
From: Sieling, Marcel [mailto:Marcel.Sieling@xxxxxxxxxxxx]
Sent: Wednesday, September 17, 2003 7:50 AM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: [foxboro] Secured Linkages


Hi,

Doug wrote:
> Also, a related interesting tidbit ... if two stations try to=3D20
> write to the same unsecured parameter in a third station at=3D20
> the same instant, it is possible to see a similar Op Error. =3D20
> Apparently, writes to unsecured parameters temporarily secure=3D20
> the parameter, write the value, then un-secure it.  Just FYI=3D20
> in case anyone has experienced intermittent, tough to=3D20
> reproduce Op Error 3s.

That's the reason, why in the BLOCK_EXCEPTION TO_SYS_ERROR a precise
differentiation should take place what to do on which OP_ERR. A clever
routine increments an error counter on OP_ERR 3's and retries =3D
afterwards.
Only after three tries you should quit and generate an error message. =
=3D
Of
course you have to take care to properly reset that counter after the =
=3D
error
and make it accessible to all routines in the Sequence block (e.g. make =
=3D
it a
global variable) and initialise it properly on sequence starts.

Block Exceptioning can save lives, if you do it properly. ;-)

Best regards -

Marcel Sieling
Systems Technologies

Invensys Systems GmbH
Heerdter Lohweg 53 - 55
40549 Duesseldorf
Germany
Tel.:  +49 (0)211 5966-171
Fax:  +49-(0)172-50-2673077
Mobile:  +49-(0)172-2673077
Email: msieling@xxxxxxxxxxx=3D20
Homepage: http://www.invensys-process-systems.de=3D20
Visit my private (german) homepage: http://www.powerslider.de=3D20

Wir m=3DF6chten auf unsere Veranstaltung hinweisen:=3D20
Invensys PLS 80E Anwender Symposium 14. und 15. Oktober 2003
in Stuttgart, Kurhaus Bad Cannstatt
http://www.foxboro-deutschland.de/pls80e-as2003/index.htm


> -----Urspr=3DFCngliche Nachricht-----
> Von: Douglas G. Lloyd [mailto:DGLControls@xxxxxxxxxxx]=3D20
> Gesendet: Samstag, 13. September 2003 20:35
> An: foxboro@xxxxxxxxxxxxx
> Betreff: Re: [foxboro] Secured Linkages
>=3D20
>=3D20
> Chuck,
>=3D20
> Not to nitpick, but the SPT parameter isn't always unsecured=3D20
> even if nothing is connected to it.  If the block is in=3D20
> remote setpoint mode, the SPT parameter becomes a secured=3D20
> output.  HLBL writing to the SPT of a block in remote will=3D20
> generate Op Errors (3, I think).
>=3D20
> Also, a related interesting tidbit ... if two stations try to=3D20
> write to the same unsecured parameter in a third station at=3D20
> the same instant, it is possible to see a similar Op Error. =3D20
> Apparently, writes to unsecured parameters temporarily secure=3D20
> the parameter, write the value, then un-secure it.  Just FYI=3D20
> in case anyone has experienced intermittent, tough to=3D20
> reproduce Op Error 3s.
>=3D20
> Regards,
>=3D20
> Doug Lloyd
> DGL Controls
>=3D20
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx=3D20
> [mailto:foxboro-bounce@xxxxxxxxxxxxx]On
> Behalf Of Jones, Charles R. (Chuck)
> Sent: Saturday, September 13, 2003 11:55 AM
> To: 'foxboro@xxxxxxxxxxxxx'
> Subject: Re: [foxboro] Secured Linkages
>=3D20
> To quote from B0193AW - Rev.F (Integrated Control Software=3D20
> Concepts) page
> 35:
> "If the parameter has an established linkage, it is=3D20
> automatically secured. If there is no linkage (connection),=3D20
> it is available to all users until someone secures it."
>=3D20
> In the ICC, when a  block input parameter has nothing written=3D20
> in it (no linkage), the parameter may have values written to=3D20
> it while it is running (from Display Manager, FoxView, or=3D20
> from custom-made programs). This condition is "unsecured". =3D20
> If, in the ICC, there is a linkage (connection) written into=3D20
> a block input parameter, then the only values that may be=3D20
> written to that parameter come in via the link (usually to an=3D20
> output parameter of another block)  This condition is=3D20
> "secured".  HLBL code written to change a secured parameter=3D20
> will surely fail.  (Trust me, I know. ;) Typical examples=3D20
> taken from a PID block:
>  - A PID.MEAS parameter is linked to an AIN.PNT parameter. =3D20
> Nothing else may write a value to PID.MEAS except the AIN=3D20
> block.  This PID.MEAS parameter is secured.
>  - A PID.SPT parameter is left unlinked.  Since there is no=3D20
> linkage, the operators my change the setpoint via a display=3D20
> that is designed for them to do so.  (Or, I could write HLBL=3D20
> code in an DEP block that would change this
> value.)  This PID.SPT parameter is unsecured.
>=3D20
> When you have dbvu report the blocks with secured linkages=3D20
> (Is that the '-l'
> option?) I suppose it prints out a list of blocks that are=3D20
> linked to other blocks.  Does it also show the linkages? =3D20
> I've never tried it.  I usually use dbvu to resolve CP=3D20
> overruns using '-s' option (to find heavily used
> phases) and '-u' option (to find unresolved linkages that=3D20
> cause linkages to timeout).
>=3D20
>=3D20
> Chuck Jones
> Refinery Automation Technologist
> Tate & Lyle North America -- Lafayette South Plant
> 765.477.5324 - Office  | 877.536.9219 - Pager
>=3D20
>=3D20
>=3D20
> -----Original Message-----
> From: Ajay.Tathgir@xxxxxxx [mailto:Ajay.Tathgir@xxxxxxx]
> Sent: Saturday, September 13, 2003 1:34 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] Secured Linkages
>=3D20
>=3D20
> Hi! All
>=3D20
> When we run a dbvu on a checkpoint file, it gives a list of=3D20
> blocks with secured linkages.
>=3D20
> My query - what is secured linkage & what does it mean ?
>=3D20
>=3D20
> Thanks & Regards
>=3D20
> Ajay Tathgir
>=3D20
> Reliance Industries Limited
> Mumbai - India
>=3D20
=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
 
 
_______________________________________________________________________
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: