1929   LCCH - ChLiv/RedChLiv

Created: 31 May 2024

Status: Discussion (red)

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

Links:

Page: 129

Clause: 6.3.4

Paragraph: Table 46

Issue

The explanation for LCCH.ChLiv/RedChLiv state the following

"If true, channel is receiving telegrams within a
specified time interval..."

Due to the used protocol and location of the IED within the network a channel could only send telegrams but never receive telegrams hence ChLiv/RedChLiv = false. This results in an unnecessary and doubtful status information which can only be found by detailed traffic analysing and results as well in an unnecessary complex supervision concept. It should not differ if a channel is receiving or sending telegrams to indicate a status of true within its supervision concept.

Example for such an "only sending IED" can be a Switch. Depending on the configuration it can be the case that data would "flow" only in one direction through the switch hence for the outgoing port ChLiv = false eventhough an UpLink is established.

Proposal

Editorial change to

"If true, channel is receiving or sending telegrams within a
specified time interval.."

Discussion Created Status
Does it matter (from the publisher's perspective) if the upstream network is broken? Is that not the role of the subscription supervision? If the local switch port is active and passing some traffic, the ChLiv indication should be true. In the case mentioned by BM, this ought to be detected by variations in RxCnt and RedRxCnt rather than ChLiv/RedChLiv. 27 Aug 24 Discussion (red)
How to know if a message is successfully published in the case mentioned by Bruce bellow ? 14 Aug 24 Discussion (red)
The channel's active status can be ascertained through both the receipt and the dispatch of messages. It is suggested that this method is reasonable for detection. For certain types of devices, such as a Merging Unit, they may only be responsible for publishing messages to the network. If the message is successfully published, it indicates that the channel is indeed active. 14 Aug 24 Discussion (red)
In response to proposal today from FL, the presence of link energy does not mean that the link is delivering telegrams. I have seen cases where an Ethernet switch is disconnected from the upstream trunk yet still convinces each other port that an active link remains. We should use a definition similar to "device is receiving telegrams". 06 Aug 24 Discussion (red)
In response to Thierry, I agree that receiving messages is not the only way to detect a valid physical network connection.
We could change to "If true channel is receiving telegrams within a .... or the device is able to detect that the physical network connection is good by another mean."
(link detection validated by the network adapter...)
06 Aug 24 Discussion (red)
Propose to "Change to Approval (Editorial)"

Proposed editorial change: "If true, channel is receiving or sending telegrams within a specified time interval to represent a working communication connection.."
31 Jul 24 Discussion (red)
In response to:

When an IED sends telegrams on a port, it has no evidence that the telegrams will actually reach the connected devices.

A Merging Unit sending stream as the notion of sending telegrams and from its perspective is the ChLiv true, and the TxCnt incrementing. It is not necessarily receiving messages, but it does not mean that ChLiv has to be false.

In scope of 90-14, a channel may send telegram without receiving any - would a PTP Gm Clock receive telegram if it is as single Clock in the network?

I could understand why the proposed change would be usefull and not creating interoperability - so could even be done with an editorial change.
25 Jul 24 Discussion (red)
If you receive telegrams on a communication port, you could be confident that the connection actually works. If you never receive anything on a communication port, you are most probably having a connection issue.
When an IED sends telegrams on a port, it has no evidence that the telegrams will actually reach the connected devices.
To me this is the idea behind the original statement and it's OK for the majority of cases.
03 Jul 24 Discussion (red)
Open for discussion.
My proposal is to handle this manner as an editorial change.
03 Jul 24 Accepted
I don't know if this tissue should be characterized as just "editorial". Maybe it can be understood as an functional extension (not only receiving, but also sending).
Should be "future improvement" or "editorial" or real tissue?
03 Jun 24 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 24.4.30.1