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
Solution accepted
27 Oct 23
Solution Accepted
Change to Ballot stage
12 Sep 23
Ballot Period
Changes to be verified
29 Nov 22
Conformance Test Verification
https://redmine.ucaiug.org/issues/5914
Test plan updated.
29 Nov 22
Conformance Test Preparation
Next step: check reg. conformance test changes
07 Nov 22
Conformance Test Preparation
The technical error does not address any of the use cases of Part 7-1, Annex K. The proposed text to be added to Annex A, Part 7-4 clarifies the standard and intended behavior. Implementations with any other behavior are incorrect.
In summary: no compatibility issues.
19 Oct 22
Analysis Of Compatibility
The following statement shall be included in annex A of part 7-4 (before table A.1):
"An LN of class "LPHD" shall not contain an LPHD.Beh data object, and therefore shall not be affected by values of LLN0.Beh.
All data objects within an LN of class "LPHD" shall therefore always expose a q.test set to false, i.e. behave as if the non-existent LPHD.Beh.stVal="on".
Controllable data objects within an LN of class "LPHD" shall therefore refuse Control Requests that use the service parameter Test=true."
19 Oct 22
Verify Draft Implementation
When the time comes for the next Tissue state change, note that this is not "an obvious typographical error in the standard", and does not meet the definition of an Editorial issue.
28 Jul 22
Discussion (red)
This Tissue is still in the Discussion phase, therefore I believe that the creation of an issue in the TPWG to add a conformance test is premature.
28 Jul 22
Discussion (red)
TF 7-500 discussed in our meeting on 2022/07/28:
- The group agrees: Objects within a LN of class "LPHD" shall not be affected by values by Beh, because there is no Beh in LPHD.
- From an application standpoint, there is no relevance on the state of TEST in the command service controlling SIM
- Joel has created an issue in the TPWG to add a conformance test for this
- Check conditions are not part of this TISSUE
28 Jul 22
Discussion (red)
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"