IEC 61850 User Feedback Task Force

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.

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?

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.

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.