Why it is important for us to do review? 

Recommendations as per IEEE 1584.1 should be included in Arc Flash Risk Assessment. It requires evaluating project, implement recommendations, re-do calculation. Physically, it should be a separate part or chapter in our report, so end customer can see influence or our proposed improvements. Sometimes our improvements in one area may affect negatively other parts of the electrical network. This often happens when an electrical system has a lot of non-selective protection devices. 

Step #9 is not a real step. Results review is constant activity during project. It is needed to : 

• Review any data quality issues and abnormal results or errors
• Identify high incident energy locations
• Identify equipment short circuit withstand rating failed equipment (panels, breakers, etc.)
• Identify protective devices non-selective operation (very important) 
• Identify worst case scenarios or combination of it

What’s next?

Once we have it done, we need to review arc flash results and protective device coordination and assess possibilities for improvements. This is where things are starting to get more complicated. There are multiple ways to do it and it partly depends on: 

• What we would like to achieve (zero risk, reasonable approach, or budget approach) 
• What was scope of work (contract details) 
• How far we can go with recommendations (budget, technical possibilities, equipment in use)

This is a good time to have a technical meeting with customer to discuss initial findings and identify technical possibilities if it was not done earlier during scope of work discussion. To improve the situation, we can use different mitigation and elimination arc flash techniques. It usually depends on initial incident energy results and combination of solutions mentioned below. All of this should be closely discussed with customer. 

What possible solutions do we have? 

Most common solutions to reduce or eliminate arc flash incident energy are: 

• Improving protective device settings – this is usually a big step as it is compromise with selectivity study, so two (usually opposite)  requirements at the same time. 
• Exchange protective device to new type e.g. retrofit old LV breaker with new type with digital trip unit, change fuse size/type, exchange MV protection relay with digital type.
• Exchange/ retrofit LV switchgears with new type –  it may be higher separation form, arc resistant, and it will allow for further modifications.  
• Install Fibre Optic Arc Detection system – add-on to switchgear, requires some re-wiring, but most of the time is possible even for old equipment (depends on system).
• Install Arc Quenching device –  add-on to switchgear (extra panel) or comes with new switchgears if system is replaced. 
• Use ZSI (Zone Selective Interlock)  in LV breakers – requires communication wires between breakers and requires new trip unit  (sometimes trip unite change is enough in LV breaker, depends on type).
• Use ARMS (Arc Flash Maintenance Switch) function – extra functionality of some LV breaker trip units, simple solution with right trip unit. 
• CLR (Current Limiting Reactors) – specific topics, as it can make it better and worse when reducing short circuit current.  
• Programmable Maintenance Switch for MV relays –  MV version of ARMS programmed into relay with some minor wiring needed for activation by SCADA, LOTO switch etc. 

How long it takes and how to handle it on site? 

Preparing recommendations takes time, but it is well spent time. As IEEE 1584.1 recommends, it should be part of every arc flash study. 
Once we have report with information what to do, we need to implement it on the site. Improvement process can take weeks, months, or even more than a year as it depends on the size of facility.  Since this process can take a while, it is good to already use our ”existing” results and install labels and match PPE based on it.  
Upgrades or protective device settings changes should be done exactly as proposed in report. Otherwise, we can end up having different calculated results than in real situation.  Every change should be noted and evaluated as part of “as built” documentation and any changes should be implemented in the model and results updated.