IEC 62439 PRP and HSR have been available for some 10 years already.

Unfortunately there are many specifications that are mandating "all IEDs must support PRP/HSR" without understanding the necessity for such networks/IEDs and hence forcing unnecessary costs on the IED supplier as well as for the systems integrator - the result is the asset owner is paying a lot of excessive cost for no benefit.

As I often say :

Be careful what you wish for ... you may just get it and regret it!!

It is therefore necessary to understand why HSR and PRP were created and are so useful for IEC 61850 networks for some of the applications, but not necessarily all of the functions in the network.

In similar words to Shakespeare:

to PRP, or not to PRP? ... that is the question!!

RSTP reliability - self-healing ring

At the release of IEC 61850 in 2002 to 2004, the general solution to LAN reliability was RSTP - Rapid Spanning Tree Protocol.
RSTP had the advantage over simple "star" networks that a problem in the RSTP ring connecting all the switches could "self-heal" so that there was only a short loss of LAN communication traffic reaching its intended destination.
The self-healing is known as "re-convergence".

In an RSTP ring, the re-convergence may be ~5 milliseconds per switch so even moderate size networks could suffer some IEDs having a complete or partial "communications blackout" for easily 50 ms, perhaps even 200 ms or more, during which time the GOOSE and SV messages simply disappear.  
After re-convergence the communications is re-established, so everything is back to normal.

1. But what is the impact of a "communications blackout" for SV, GOOSE or MMS? (Short answer: it is very different for each).
2. Why would PRP or HSR become virtually essential for protection IEDs and functions? (Short Answer: we can't afford delayed tripping of the CB in case of a power system fault).
3. Do all IEDs such as Condition Monitoring, general controllers etc also need to support PRP or HSR dual port communications? (Short Answer: No, so don't over-specify what you don't need .. it will waste a lot of money)

Impact of RSTP re-convergence

1. MMS

The RSTP blackout for MMS is possibly important in a very few cases, but even these can be easily engineered out.

If it is the client (HMI) polling server IEDs (send me this information ...) , or sending operational commands (open/close, turn on/off, enable/disable, raise/lower ...) to the server IED.  It is just like making a telephone call to talk to someone, until the server IED answers the "call", the client cannot send the poll request or command, so it just keeps “redialling” until the server IED starts responding again.  Similarly when the Server IED has to provide the response to the Client. 
Chances are that the technician/operator will not notice the slight delay in response.

MMS also has automatic Reporting initiated by the server IED based on a certain event - there are two forms of Reports – Unbuffered and Buffered.

• Unbuffered is a report that is sent without any confirmation that the client has received it so those messages are lost forever as far as the client is concerned - it is almost similar to a GOOSE message in that respect, but is specifically between the one server and the client(s).
• Buffered is again like making a telephone call that the Client must "answer the call" that it is "ready and waiting" before teh Server will send the report.  So even if there is a communications blackout (of any sort), eventually the report will be received by the Client, noting that each such automatically initiated Report message (if any) during the blackout will all be eventually sent as a “catch up”.

MMS includes SCADA from the Client (open/close, turn on/off, enable/disable, raise/lower ...) as well as messages from the Server (confirmation, values, status ...) and many Condition Monitoring applications.

2. SV - Condition Monitoring

Sampled Values can be applied to a variety of sensors - there are some 22+ sensors of various types defined in the T group Logical Nodes: T Group - analogue samples (22)
These range from "fast" sampling rates such as 4800 samples per second for current and voltage measurements of the primary power system, to much slower sampling perhaps of say 1 per hour for a temperature or pressure analogue measurement.

The RSTP blackout would therefore only slightly impact sensor publishing if the sample(s) happen to fall within the blackout period. 
Depending on the sampling rate, this may be just "unlucky" to be one SV message or several. 
The impact on the S group Logical Nodes as the subscribers to T group SV messages may have some degree of importance, but usually such Condition Monitoring algorithms are operating over at least several seconds so the loss of a several samples for even a 200 ms period is going to be "smoothed over".  Indeed the absence of the SV arriving can be detected and alarmed within the subscribing IED and some "degraded performance" mode implemented depending on the importance of the SV and the monitoring function

Hence  PRP offers very minimal advantage in a very few instances of Condition Monitoring applications. 
It would generally be expected that PRP is not implemented in the T group sensors or the S group monitoring IEDs, i.e. most likely it would not be a specification requirement as PRP would be an unnecessarily difficult and unnecessarily costly requirement to satisfy.
It would be perfectly correct and appropriately inexpensive to connect the Condition Monitoring T group sensor and the S group monitor as "single port" IEDs to just one of the PRP networks - either A or B, as long as consistently either A or B.

3. SV - CT/VT Sensors

As a result of the break in the RSTP ring and the re-convergence time the subscribing IEDs ”beyond” the ring break have permanently lost all the SV messages published in that period of comms blackout – they are never repeated so it is like short circuiting the CT or open circuiting the VT for "200 ms".

As a result, the protection needing those SV message is at least impaired and possibly susceptible to some sort of mal-operation or delayed operation.    

PRP is therefore an essential part of implementing SV for CT/VT applications.

4. GOOSE - Fast Protection Operations

The subscribing IEDs ”beyond” the ring break will lose (some) of their GOOSE for "200 ms", but they will eventually get the repeats in the normal GOOSE repetition process.

However the impact of the "eventual", i.e. delayed success in the subscribing IEDs receiving the GOOSE message with some state changes may have different consequences depending on the functions involved.  

4a) "Status Quo" (no system events) and an RSTP blackout.

If all is "status quo" in the substation with no events there is a possibility that 

1. the 200 ms comms blackout occurs for some publishers nicely between the 1-second heartbeat published GOOSE, so the subscribing IEDs are not affected by the 200 ms blackout.
2. For other publishers the blackout could span the "scheduled" 1-second heartbeat message and hence the subscribers will not get the GOOSE heartbeat message i.e. 2-seconds between successive messages. 
   As there will be a jump of 2 in the SeqNum of the GOOSE, the subscriber will "know" one message went missing which can be correlated to any log of the ring failure and RSTP re-convergence event.

In both cases though, there is no impairment of the system as there was no system event during the comms blackout so no change in the GOOSE dataset.

The following diagram (time running down the page) shows the impact on three IEDs publishing their GOOSE as heartbeats with only one coinciding with the 200 ms RSTP blackout.

4b) RSTP blackout shortly prior to protection operation

However if there is a function change of state in any of the publishing IEDs occurring just after the start of the comms blackout, there may be significant impact for the subscribing IEDs and power system critical protection system operation.

The following diagrams (time running down the page) compare a "normal" operation sequence of a protection initiated trip to the effect of a 100 ms or 200 ms RSTP re-convergence blackout RSTP blackout.xlsx .

In each of the three scenario columns:

• the left orange bar is the protection operation (solid when in the operated state) with the resulting GOOSE message publication events
• the right blue bar is the CB status (solid when closed) with the resulting GOOSE message publication events (assumed operating time of ~ 60 ms).

Successful delivery of the GOOSE message is indicated as a green GOOSE message, unsuccessful GOOSE delivery (it is still being published by the protection IED) represented by a red GOOSE message.

1. Left side scenario: The normal operation sequence should yield a CB opening around 62 ms after the protection operation.   
2. Centre scenario:  With just 100 ms re-convergence delay, the total CB opening time has become ~190 ms after the protection operation - a 130 ms delay!    
3. Right side scenario: With 200 ms re-convergence, CB opening is delayed to ~320 ms after the protection operation - a 260 ms delay!        

The increase in the CB opening being more than the comms blackout time is because the CB IED has to wait till the NEXT GOOSE repetition message to arrive before it knows the protection has operated as indicated by the "Protection Op received" time, requiring the CB to be tripped.

Another example set of problems for GOOSE RSTP blackout problem scenarios is instead of the protection initiate trip, the sequence may be the protection reset initiated auto-reclose, The blackout effectively extends the system dead time to cb reclose beyond normal safety limits!    

4c) RSTP Blackout Missed Status Changes

The third GOOSE problem scenario is if a value in one of the IEDs publishing GOOSE has of one of the bits in the GOOSE has changed twice within the blackout period, e.g. initially 1, changed to 0 then changed back to 1 (or vice-versa. 
This could be the case of a protection operation, CB opening and protection reset. 
The subscribing IEDs won’t know which bit had changed twice, but it will know "something" had changed as the status number field stNum has incremented by 2 for that publishing IED’s GOOSE, but they will not know which of the several bits in the GOOSE had changed.

PRP is really only required for critical high speed signals

PRP sending and receive means that that RSTP communications blackout never occurs for the PRP subscribing IED.  Of course the sending or receiving IED failing is a different matter!

That bumpless "no comms blackout" feature of PRP is ONLY important for fast Protection related GOOSE and some SV.

The RSTP communications blackout does not matter for MMS Buffered reports, but it might matter for some Un-buffered reports … but the truly important reports should then be configured as Buffered reports!

So we can now easily see that PRP is really only critical for protection GOOSE and SV where you cannot afford to have a 200 ms (or permanent) communications blackout.

That super criticality is not solved by “dual homing” of two IED ports with two MAC / IP addresses connected to the one LAN.

Note that you can have some non-critical GOOSE like “substation gate position” (perhaps a 10-second heartbeat and 1 second fast re-transmit where a RSTP blackout at the crucial instant would simply be a delay of an extra 10 seconds in knowing about the change of state.

The generalisation that PRP is not required for "99.99%" of Condition Monitoring devices would be reasonably true, so please do not over-specify "PRP for all IEDs" .. it will add a lot of unnecessary difficulty and a lot of unnecessary cost for no real benefit in trying to get suitable PRP IEDs, or adding "Red Boxes" as an interface for single port IEDs.

Of course there is never any one absolute correct philosophy, but perhaps the first place to start is to consider if you do not have a need for duplicated and independent sensors or monitor/controllers, why would you need them to be connected to duplicated networks?

The answer may be
"I don't need PRP because the IED is always the single mode of failure anyway so it it is not super critical that the sensor and monitor are always in communication with each other".

The answer instead may be:
"It is not a major problem if this sensor/monitor pair are not working (that can be alarmed), but it is better to make sure the LAN is not the reason for them not working so PRP is useful!"
If that is the answer, should these devices individually or combination as shown below :

1. directly support PRP
2. as a Single Attached Node (single port IEDs) have their own Red Box interface
3. as a group of Single Attached Nodes talking to other SANs, can they be grouped via a common Red Box

Once that decision is made about any one IED, it demands that ALL the other IEDs it is in communication with are also PRP "enabled" by one of those methods - the diagram below shows two IEDs that do not need any PRP but still communicates satisfactorily with ALL the other IEDs in the network.

Note Red Boxes and the connection to the SANs is still a common mode of failure that PRP cannot eliminate!

Extra Notes: