For Ed.2 Amd.1 the description to LLN0.Loc was extended with the following clarifying sentence:
<< If this 'Loc' (in the logical device) is in contradiction to the 'Loc' of any other contained logical node, "local" is always dominant (see also Annex B). >>
The wording "any other contained logical node" includes also X Group LN XCBR and XSWI. If 'LLN0.Loc' is "local", for example 'XCBR.Loc' is forced to "local" as well.
Since XCBR will not accept control commands if its 'Loc' is "local" (see Annex B, Table B.1), local controls can never be executed.
The clarifying description of 'LLN0.Loc' must be modified to exclude X Group LN from the rule.
Propose to modify the description text of 'LLN0.Loc' as follows. Note that this proposal also addresses the notion of nested logical devices.
<< If this 'Loc' (in the logical device) is in contradiction to the 'Loc' of other contained logical nodes and possible contained logical devices (and again their contents), "local" is always dominant (see also Annex B). 'XCBR.Loc' and 'XSWI.Loc' are not affected by this dominance. >>
Note: If the same local/remote concept is also applicable to Y Group LN like YEFN, then these LN must be excluded from the rule as well.
Thank you to remind.
For the process bus configuration there should not be this problem, since the LD/LLN0 of the bay controller will be separate from the LD/LLN0 of the CB controller - two physical devices.
This Tissue was created with the non-process bus configuration in mind.
18 Jun 21
Accepted for discussion.
18 Jun 21
I think we should distinguish whether the configuration is: Non-process bus configuration (Bay-IED with LLN0/CSWI/XCBR) or Process bus configuration (Bay-IED (LLN0/CSWI) and CB-Controller (LLN0/XCBR)).
Because Loc is mandatory in XCBR, there is an issue in a non-process configuration (normal Bay-IED), if LLN0.Loc (e.g. by a key switch LocKey for the complete IED) is true, XCBR.Loc goes true and commands with originator Local control (means Bay control) cannot be executed.