Project

General

Profile

Improvement #5335

Adding Normative Requirements & Conformance Testing Pertaining to Broadcast Storms

Added by Dustin Tessier 6 months ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Category:
Standard extension required
Start date:
03/30/2022
Due date:
12/30/2022 (Due in about 3 months)
% Done:

0%

Estimated time:
Spent time:
ID:
Source:
Dustin Tessier
TF Unique ID:
WG10 Proposal:
Estimated Completion:
Discuss in Upcoming Meeting:
No
To discuss in WG10:
No
Short Proposal:
Standard(s):

IEC 61850-90-4


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).

#1

Updated by Herbert Falk 6 months 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.

#2

Updated by Dustin Tessier 6 months ago

  • Source set to Dustin Tessier
#3

Updated by Dustin Tessier 6 months 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?

#4

Updated by Joel Greene 6 months 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.

#5

Updated by Dustin Tessier 6 months 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.

#6

Updated by Vladan Cvejic 5 months 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.
#7

Updated by Carlos Rodriguez del Castillo 5 months ago

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

With the information given, the problem is a network and specific-implementation issue, it is out of scope of IEC 61850 standard.

#8

Updated by Vladan Cvejic 4 months ago

  • Description updated (diff)
  • Status changed from Closed to Resolved
  • Priority changed from Urgent to Normal
  • Proposal descriptions updated (diff)
  • Standard(s) set to IEC 61850-90-4
#9

Updated by Vladan Cvejic 4 months ago

  • Description updated (diff)

Also available in: Atom PDF