1819   Dependancy of LPHD.Sim to LLN0.Beh

Created: 26 Mar 2022

Status: Discussion (red)

Part: Part 7-4 (2020; Edition 2.1)

Links:

Page: 454

Clause: Annex A

Paragraph: 1

Issue

From SCL IOP 2021:
Some IEDs don’t care about the value LLN0.Beh when changing the value of LPHD.Sim; other IEDs require that the control command be in Test (Test=true) when the LLN0.Beh=Test and the control command be Normal (Test=false) when the LLN0.Beh is not Test. The latter is in line with testing conventional protection relay where one would plug in a test switch first before injecting analog/binary simulated signals, and then to put it back in normal service, removing the injected signals first before removing the test plug in order.

While the IED AA1D1Q01BPU1 logical device Application/LPHD0 does not have a data object Beh, the LLN0.Beh affects control of LPHD0.Sim as described below.

Initially, with LD Application/LLN0.Beh=On (Mod=On) and LPHD0.Sim=false, changing the LPHD0.Sim to True with Client “Normal” control command (parameter Test=false) returns a negative response with an addCause of Blocked by mode. Changing the control parameter to Test=true and re-issuing the control command returns Succcess and it is verified that LPHD0.Sim indeed changed to True.
The same thing happens also when changing Sim back from True to False.

Conversely, with precondition Application LLN0.Beh=Test (Mod=Test or Test-Blocked), changing the LPHD0.Sim to True with a Client “Test” control command (parameter Test=True) returns a negative response and an addCause of Blocked by mode. Changing the control parameter to Test=false and reissuing the control command returns Succcess and it is verified that LPHD0.Sim indeed changed to True.

Proposal

IEC 61850-7-4:2010/AMD1:2020 Table A.2 excerpt describes what the responses should be.

Discussion Created Status
Regarding the clarification required for LPHD, I am not sure that we have to specify a specific rule for check conditions (interlock and synchrocheck). This is not a specific behavior for controllable object of LPHD and it will create confusion to end user. In addition, definition of check conditions already states that it applied to type DPC (refer to IEC 61850-7-2:2010+AMD1:2020 section 6.2.3.16).
So, I would suggest that we limit the clarification of Beh only which is a special case of LPHD.
17 Jun 22 Discussion (red)
Suggest to change to "For controllable objects within LPHD, they shall behave as if the value of Beh were appropriate for operating the control, all possible test/check information (testBit, synchrocheck, interlockCheck) shall be ignored." 17 Jun 22 Discussion (red)
Commenter on 6-May requested that we add no special conditions if possible.
I suggest something similar to:
"For controllable objects within LPHD, the object shall behave as if the value of Beh was appropriate for operating the control and all possible test/check information (testBit, synchrocheck, interlockCheck) shall be ignored."
20 May 22 Discussion (red)
I think we should add: In control requests to change LPHD.Sim, all possible test/check information (testBit, synchrocheck, interlockCheck) shall be ignored.
20 May 22 Discussion (red)
The solution should include the exact text to add.
A simple note might not be enough. Please consider:
- Is there a general rule for every SPC DO within LPHD that controls are accepted regardless of the value of control.Test?
- Is there a general rule for every DO within LPHD that have attribute q.test always report false?
- Is there a general rule for every DO within LPHD that substitution is not permitted?
- Are other general rules also needed?

This information is needed to ensure the ability to write clear test procedures.
04 May 22 Discussion (red)
Editorial change:
Add a statement in annex A: Data objects in LPHD are not affected by Mod/Beh. They shall behave as if the Beh.stVal controlling them is "on".
03 May 22 Approval (Editoral)
Change to Editorial 20 Apr 22 Approval (Editoral)
I believe it is a clarification, and the standard is clear.

Lxxx.Yyy is affected by Lxxx.Beh. Lxxx.Beh inherits from LLN0.Beh, but Lxxx.Yyy is not directly influenced by LLN0.Beh. Because there is no LPHD.Beh there can be no influence here.

But not having Beh is unusual, so adding a note seems reasonable. Could be processed as editorial to add a note.
11 Apr 22 Triage
I support the idea to clarify in part 7-4, that LPHD DO are not affected by Mod/Beh, and the LPHD objects shall behave as if the Beh.stVal controlling them is "on".

My question to WG10 experts: do you see it as an interop tissue or is it more a clarification and therefore a future improvement? Or is is still a Approvel (N/A)?
My opinion: Future improvment and an input for the ongoing 7-5/7-500 work.
11 Apr 22 Triage
I disagree on silence. Can we agree upon words to be added to Annex A:
Objects within a LN of class "LPHD" shall not be affected by values within Mod and Beh. The LPHD objects shall behave as if the Beh.stVal controlling them is "on"
08 Apr 22 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 22.6.30.1