The semantic of the data object "Beh" is decribed in part 7-4, Table 10.
Therein a fixed relationship is defined between "Mod" from LLN0 and the respective LN as result a for "Beh". The data-object "Beh" should represent the actual functionality of the LN.
In case of internal functions or in case of an error it is not possible to report these actual behaviour of the LN via data-object "Beh".
Example 1:
=========
LLN0.Mod / PDIS.Mod and PDIS.Beh are "ON". ---> Due an external digital input the function of PDIS was changed to the "on-Blocked" mode.
===> LLN0.Mod = "on"
===> PDIS.Mod ="on" (because the distance protection is enabled)
Is it allowed to set PDIS.Beh ="on-blocked" or must both PDIS.Mod and the PDIS.Beh be set to "on-blocked"? As a consequence a control-sequence to Mod must be rejected too !
The disadvantage of the method (both objects were set) is, that it can not be seen wether it is was blocked by a setting or by a temporally condition
Example 2:
=========
LLN0.Mod / PDIS.Mod and PDIS.Beh are "ON". ---> Due a "fusefail" of the measurement unit, the functionality of distance protection is not possible (off)
===> LLN0.Mod = "on"
===> PDIS.Mod ="on" because the distance protection is enable
Is it allowed to set PDIS.Beh ="off"(not working) or must both PDIS.Mod and the PDIS.Beh be set to "off"? As a consequence a control-sequence to Mod must be rejected too !
The disadvantage of the method (both objects were set) is, that it can not be seen wether it is was switch-off by a setting or not working due an internal condition
Example 3:
=========
LLN0.Mod / PDIS.Mod and PDIS.Beh are "ON". ---> Due an external digital input the function of PDIS was changed to the "test" mode.
===> LLN0.Mod = "on"
===> PDIS.Mod ="on" (because the distance protection is enabled)
Is it allowed to set PDIS.Beh ="test" or must both PDIS.Mod and the PDIS.Beh be set to "test"? As a consequence a control-sequence to Mod must be rejected in case of non-test-command too !
The disadvantage of the method (both objects were set) is, that it can not be seen wether the LN is in test-mode by a setting or due an internal condition
Proposal
Please make clear that the data-object can have other states due internal functions too
Discussion
Created
Status
Decision accepted. Change annex A accordingly.
29 Jul 14
In Force (green)
The proposed sentence will be accepted. It should be clear that internal automatic functions (like fuse failure) should not change Mod, but they has an impact on other DO/DA (e.g. dynamic blocking - Blk).
30 Jun 14
Ballot Period
From the basic concept Mod should only be influenced by an operator action. This could however be a local action (binary input, local HMI) instead of a command. Therefore my proposal:
"Switching between the modes (Mod.stVal) should happen as a result of an operator action to the data object Mod. This can be a remote command as well as an IED local action."
This includes especially, that a locally set mode can be modified from remote (and vice versa) if the appropriate access right is granted.
26 Jun 14
Discussion (red)
The first sentence in annex A states: "Switching between the modes (Mod.stVal) should only happen as a result of an operator
command to the data object Mod." That should be improved in such a way, that Mod can also be set by internal functions. The xxxx.Beh depends then on a combination xxxx.Mod and LLN0.Mod as it is stated in part 7-4 , sematic description of Beh.
I propose to change the first sentence of annex A: "Switching between the modes (Mod.stVal) should happen as a result of an operator
command to the data object Mod. Internal functions could also have an impact on Mod."
11 Jun 14
Discussion (red)
DataObject Mod can be set by an internal function, interaction with a binary input.
DataObject Beh should not have ohter states except the one specified in the table.
Therewith, Beh would remain a consequence of the own Mod.