539   Dynamic Protection Blocking

Created: 14 May 2007

Status: In Force (green)

Part: Part 7-4 (2003)

Links:

Page: 21ff (all Protection LN)

Clause:

Paragraph:

Category: Issue for edition 2 of this part

Issue

Statement against present Mod/Beh use to do dynamic blocking for protection LNs
1. The semantics of 'Blocking' need to be defined better. For protection logical nodes, Blocking has a specific meaning, for example the blocking of the second stage of overcurrent protection by an opto input may prevent the element from tripping. However, even here, the blocking may have several purposes: e.g. to block all start & trip outputs, block any timer stage, or just block the trip output. This is a dynamic form of blocking that is normally done by hardwiring and is independent of any other control on the Logical Node (e.g. local/remote , test mode or enable/disable). The use of the Mod control for this functionality was therefore questioned as it is difficult to control only the Blocking operation of Mod without knowledge of the test or disabled controls. It was therefore considered that the Blocking state of Mod be renamed to OperatorBlocking as this seemed more appropriate to the nature of the control. (likewise test/blocked be renamed to test/OperatorBlocking). Mod would therefore control the whole of the logical node and none of the 'partly active' or 'active parts' of the Logical Node are relevant as suggested by Siemens. Perhaps they are also thinking that Mod refers to the protection blocking?
2. There is a quality bit called OperatorBlocked. It was not known if this is used to indicate data from a logical node which has been blocked by the Mod object. If so, it adds weight to the choice of renaming Blocked to OperatorBlocked.
3. It was not known if the Beh object should be set to Blocked if the Logical Node is Blocked via an opto input, rather than the Mod value. It was thought not, but this needs to be raised as an issue.
4. It is stated that when blocked, No outputs (to the process) are generated. The meaning of Process needs to be defined. Is it everything outside of the LN, or everything outside of the logical or physical device?
5. More description of the 5 enumerations of Mod are required to support or differentiate better from the dynamic blocking on protection applications.

Proposal

Proposal to create in Ed.2 new data objects for all protection LNs

The idea is shown in the attached powerpoint slide. To allow each vendor to use the todays protection functionality and to allow full inter operable understanding we suggest to add different blocking commands to differentiate between the different internal interaction of the blocking:

BlkOpn – Blocking of the whole LN function (possibly same function as blocking by Mod.ctlVal)
BlkTimRs – Blocking of the time stage with reset of the time
BlkTimFr - Blocking of the time stage with freezing of the time
BlkStr – Blocking of Starting only
BlkOp – Blocking of Tripping only
BlkStrOp - Blocking of Starting and Tripping

Further DO would be required for the signalling of the blocking status, if not only Beh is used as general blocking information.

How should the quality of the Str and Op need to be managed?

Discussion Created Status
Time for voting is over. Solution see CDV ed2 24 Jun 08 In Force (green)
As a generall solution in edition 2 will be introduced in common logical node data Blk and BlkRef for dynamic blocking aaplication. 14 Feb 08 Ballot Period
We agree to reduce the blocking objects to only one, independant from the IED internal functionality, but the description in the standard should include a related remark. We propose then to name this data object "BlkOp", because the main requirement for a dynamic protection blocking is clearly the blocking of the CB trip (typical application e.g. reverse interlocking). The rquirement is to block the Op, but how the str or time stage will be managed is then free definable. Maybe an adequate status indication should be added as well, or is it enough to read the stVal of BlkOp?
Best regards
Christoph Bennauer, 09/07/2007
09 Jul 07 Discussion (red)
To avoid an implementation specific solution only one general data object for blocking should be introduced for all protection LN. The final conclusion of this isssue is intented to be included in CDV ed.2 24 May 07 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1