Improvement #5335: Adding Normative Requirements & Conformance Testing Pertaining to Broadcast Storms - IEC 61850 User Feedback Task Force - UCAIug Issue Tracking System

Improvement #5335

Adding Normative Requirements & Conformance Testing Pertaining to Broadcast Storms

Added by Dustin Tessier about 2 years ago. Updated 11 months ago.

Status:

Resolved

Priority:

Normal

Category:

Standard extension required

Start date:

03/30/2022

Due date:

12/30/2022 (about 16 months late)

% Done:

Estimated time:

ID:

Source:

Dustin Tessier

TF Unique ID:

WG10 Proposal:

Estimated Completion:

Discuss in Upcoming Meeting:

To discuss in WG10:

Short Proposal:

Standard(s):

IEC 61850-90-4

Needs More Information:

Assigned TF:

Description

Problem is presented during WG10 plenary meeting (link on IEC Collaboration tool: https://collaborate.iec.ch/#/pages/workspaces/137211/documents/174744/details/686077?onlyWithPreview=false&fileId=686077)

There is a need to improve IEDs ability to detect, alarm, and recover/ride-through from layer 2 broadcast storms, which is a standing risk for any redundant networks using GOOSE/SV and PRP/HSR/RSTP.

Proposal descriptions

1. Proposal is that TF responsible for 90-4 should evaluate the problem in RSTP/PRP network configuration and to recommend solution.
2. There is a need to define broadcast storm in our Domain.
3. If necessary to require IED to recover specifically from broadcast storm situation (in other parts of the Standard). There are Requirements on recovery delay mentioned in Part 5 (11.5.4).

Updated by Herbert Falk about 2 years ago

Please note IEC 62439 (PRP/HSR), nor IEEE 802, specifies any behavior requirements for multicast storms regarding ride through nor monitoring of such. These standards, although reference by IEC 61850-8-1 are not within the scope of conformance testing (in the same manner that we don't conformance test TCP/IP implementations). Since there are no such requirements in the base standards and IEC 61850 conformance has never covered these layers (and it has been discussed multiple time and agreed upon to not explicitly test these layers), the best is to test this issue at IOPs, which if the participants decide to test the test is performed.

Suggest that this issue be rejected/closed as it is not appropriate for a IEC 61850 conformance or requirement.

Updated by Dustin Tessier about 2 years ago

Source set to Dustin Tessier

Updated by Dustin Tessier about 2 years ago

Herb: That is incorrect. IEEE standards do mention loop prevention and broadcast prevention requirements. Even if they had not, it is still acceptable for IEC 61850 to add these requirements. It is common for 61850 to extend/augment base standards such as these. For example, 9-3 extends IEEE 1588 and this would be no different. Rather than jumping to conclusions on why not to do it, we implore you to have an open mind when addressing this real-world risk. We will discuss in TFUF similar to other issues.

Why is UCA IOP testing these scenarios if Herb claims they are not associated with 61850? Shouldn't the scope of the IOP be limited to validating 61850 requirements?

Updated by Joel Greene about 2 years ago

In my opinion, the issues described here are well-known and obviously out of scope of 61850, but if any information about the perceived need can be expressed we could explore it. Not much this TF can do without that info, as our task is to analyze user feedback and determine whether there is a need to improve the standard.

Updated by Dustin Tessier about 2 years ago

Joel Greene wrote in #note-4:

In my opinion, the issues described here are well-known and obviously out of scope of 61850, but if any information about the perceived need can be expressed we could explore it. Not much this TF can do without that info, as our task is to analyze user feedback and determine whether there is a need to improve the standard.

Agreed, this is a well known issue among users, so I'm confused on why you believe it should not be discussed? Obviously if users are experiencing this "well-known" and real-world issue, the standard should be improved. Therefore it meets the requirements of the TFUF and believe it is the ideal time to discuss and resolve it.

Updated by Vladan Cvejic almost 2 years ago

Status changed from New to Triage
Discuss in Upcoming Meeting changed from No to Yes
To discuss in WG10 changed from No to Yes

After the discussion within the group there are several points:

We would like to hear the experience from Darren De Ronde (when possible)
Opinion of the UFTF group is that it is beyond scope of work of WG10
Suggestion: to start a discussion on the next WG10 meeting and to decide about possible work
In general - Standard should recognize this type of problems (to be detected) and that the IED (MMS server, GOOSE/SV publisher, subscriber...) should recover upon disappearance of faulty conditions.