There is ambiguity whether blocking electrical outputs due to modes "blocked" and "test/blocked" is depending on the purpose of these outputs.
There seemed to be confusion around the “… will be issued to the process.” piece. Some vendors interpreted that literally, such that they gave the user an option of selecting if the output was connected to the process. Other vendors interpreted it such that this applied to every output.
Proposal
Clarify whether when it comes to blocking of electrical outputs due to modes "blocked" or "test/blocked", all kinds of electrical outputs (relays, analogue outputs e.g.) are treated the same.
Clarify whether a difference is made if an electrical output is wired to external equipment of the primary process (to switchgears e.g.) or if an electrical output is wired to external equipment of the secondary process (to a claxon, to other automation components e.g.).
In particular, the message defined by "Output to the process (Switchgear) ..." and the listed LN classes in Table A.2 upper left cell are to made clear.
Clarity could be achieved by an improved statement in Table A.1 and in Table A.2 .
Discussion
Created
Status
Referring to the comment about resetting an active block signal to another IED.
This applicational use case is to be dealt with when TF 7-5/7-500 is going to work on RedMine #6555.
Not sure whether this can be solved in a general statement in the standards or whether this must remain configurable.
02 Jul 25
Discussion (red)
Regarding the test switch, my understanding is that not all binary outputs are connected through the test switch. It is mainly the outputs that could affect the process e.g. trip outputs. Other signals will still be active as without the test switch.
Another question is if all outputs will be reset (deactivated). That means e.g. that there is an active block signal from one device it will disappear if the device is set in blocked. Is that wanted functionality?
23 Jun 25
Discussion (red)
The introdcution of Beh = blocked, was to have a software solution to the test plug / test switch. Meaning, there is no need anymore to disconnect the electrical outputs from an IED from the real wiring: "no output to process".
What signals were routed to the electrical output is irrelevant, the un-plugging blocked all outputs to electrical process, and the Beh = blocked intention is still to block all output to electrical process.
This has nothing to do with the introduction of LPDO.
Henry's comment was to acknowledge that the process can not be limited to switchgear as there are many type of process like generators, water turbines, DER equipment, etc, and therefore can not be limited to X, Y, and GGIO, but to any object that can be routed to a binary output as an interface to the electrical process.
20 Jun 25
Discussion (red)
I agree with Henry's comment (02 May 25), since it clarifies the intention of the standard and we should avoid to modify it to much.
There exist cases where the IED operate together with other IEDs/equipment via binary hardwired signals. This would then be prohibited by blocking all output signals.
The process outputs are not modelled today, since the X, Y and GGIO represent the process. When the LPDO is added the outputs from the X, Y and GGIO need to be modelled to enable connection to the LPDO.
These outputs do not fit into the existing DO categories, so a new category is needed for these process outputs. These process outputs can either be connected via LPDOs or as of today, indirect connection to the outputs.
This new DO category should then be affected by Beh = Blocked and Test/Blocked, regardless of how the signal reaches the process.
As the LPDO has no semantics it could not know if it is a process outputs or used for something else, so hence there should not be affected by Beh = Blocked.
By this the original intention with the blocking concept will be preserved and it will be clear what DOs will be blocked.
19 Jun 25
Discussion (red)
I cannot see us finding a useful definition of which output goes to the process or maybe to something else.
The only clearly and unambiguously executable rule is to block all outputs.
06 Jun 25
Discussion (red)
No output to any electrical interface (b/) is meant, because the signal that is routed to the binary output can not be discriminated it is goes to the "process" or not. It is being routed to a binary output because the user selects for the interface an electrical wired-communication and not a data telegram communication.
Beh blocked and test/blocked are intended to model a test/socket functionality, and there is therefore no discrimination about the purpose of the signal.
05 Jun 25
Discussion (red)
The question is whether the intention of modes "blocked" and "test/blocked" is
a/ to block outputs to the primary process exclusively or
b/ to block outputs in general.
If modes "blocked" or "test/blocked" are intended to model a test plug/socket functionality, then there would be no distinction between the purpose of the output.
In the case of "a/" each LN instance needed to know whether its output controls the primary process or just a claxon. Before creating a never
ending list of objects which belong to category "primary process", we should consider to create a new configuration parameter for defining the LN behaviour (not blocking / blocking) when in modes "blocked" or "test/blocked".
02 May 25
Discussion (red)
Change to "discussion"
02 May 25
Discussion (red)
I see no ambiguity because table A.2 (in annex A of part 7-4) clearly states "Output to the process (switchgear)...". Maybe we should add "(switchgear)" also to the statements of table A.1 (than it would be "no (wired) output will be issues to the process (switchgear)."
The intention of states "blocked" and "test/blocked" is to model a widely used equipment like test plug/test switch.
But I would support to describe explicitely how Beh=blocked and Beh=test/blocked influence other "primary" equipment like generators, water turbines, wind turbines, DER equipement etc. in cases they need to use funtions of test plugs.