GC0141 – RMS & EMT Model Compliance Process

Introduction

The recent GC 0141 requirement introduced by NESO are creating significant challenges, costs and delays to the approval process, which is negatively affecting many renewable developers within the UK. The GC0141 requirements, have been present for over a year now, but due to project timescales the requirements are still catching many developers and OEMs out.

The requirements for GC0141 are primarily aimed at new developments, but upgrades to  existing sites are also caught within it. Aurora have been involved in several existing thermal power stations that have been upgrading their AVR / PSS, also requiring to meet these requirements. For existing sites, the upcoming requirements for GC 0168 and EMT models will potentially apply.

GC0141 Requirements

NESO introduced the GC0141 requirement for a number of different reasons, but principally they are intended to give NESO a much more detailed overview of developers power systems, and ensure greater network resilience, by identifying problems during the design stage. The NESO requirements are:

• RMS Model: The developer must provide an unencrypted RMS model, in DIgSILENT Powerfactory that represents the site. The model can be based on generic models, and use aggregation techniques, but it must be unencrypted, use no external DLL files and be compatible with a 10ms simulation time step.  
• EMT Model: The developer must provide a detailed EMT model in PSCAD, that fully represents the site. The model, must be in version 5.0.2, and be compatible with Intel Fortran Compiler version 19.2, Visual studio 2019, and be compatible with a 10us simulation time step.

The models must be provided with a validation report and a detailed user guidance manual. This supporting documentation must provide details of the relevant control systems, transfer functions model equivalents and protection systems.

There is unfortunately some ambiguity in the GC0141 requirements and a number of issues that are not clear, leading to delays and inconsistent comments from NESO. At Aurora we are actively engaging with NESO to try and clarify these issues and revise the guidance note to make sure everyone is clear on the process and requirements.

GC0141 RMS model

The RMS scope is not too difficult technically, and is mainly a practical and logistical problem. The key requirement is that NESO require a full unencrypted model that represents the site to be prepared and provided with an additional validation report and detailed user guide. Because of the unencrypted / open model requirements a number of OEMs are having difficulties. Four main approaches are used, and It is essential that the inverter and PPC vendors agree the strategy for this submission at an early stage of the project. At present Method 2 or 3 are the most common approach.

1. Inverter and PPC OEM agree to provide unencrypted models at the start of the project and these are used all the way through. (This approach is very unlikely to be agreed by OEMs). Aurora prepare the validation report and user guide.
2. Inverter and PPC OEM provide encrypted models as normal for the main studies. At model handover stage, Aurora submit the encrypted model to a trusted 3^rd party (such as DIgSILENT) and the OEMs submit their unencrypted models to the 3^rd party. The 3^rd party swaps out the encrypted bits and submits to NESO. Aurora provide a model guide and validation report. The validation report only works if it is a 1-to-1 swap of encrypted elements with unencrypted elements.
3. Either one of the Inverter OEM or PPC OEM provides an equivalent generic model (such as WECC) and the other OEM maintains an encrypted model. Aurora then creates a new model based on the open model, and validates the new model and prepares a user guide. Aurora then provides the model to the OEM who still has an encrypted system, and the OEM removes the encrypted system replaces it with an unencrypted version and submits to NESO. The validation report only works if there is a 1-to-1 swap of encrypted elements with unencrypted elements.
4. Both inverter OEM and PPC OEM provide an equivalent generic model (such as WECC) to Aurora. Aurora then undertakes a validation of the WECC models, prepares the validation report and user guide for submission to NESO. This approach facilitates the use of aggregated modelling techniques.

The unencrypted modelling requirements are technically not too difficult. The delay with the process is
usually more a logistical one and developers and OEMs not being ready for the requirements. Another key decision, is if the model is going to be an aggregated model of the whole system, or a full model, and someone will swap out the encrypted parts with the unencrypted parts. Delays are typically caused by:

• Unclear agreement from the developer with the OEMs on which strategy (above) will be followed.
• OEMs not realizing they have to provide an unencrypted model to NESO, that does not contain any external references or DLL files.
• OEM models not implementing the latest requirements from the Grid Code. A key risk here is PPCs that have not understood or implemented the de-load function for Storage Sites.  
• Models that need a different time step to 10ms.
• Failing to look at the NESO Guidance Note on GC0141

GC0141 EMT (PSCAD) modelling scope:

The EMT scope is much more challenging. PSCAD is a less forgiving package to use, and there are less engineers available with the required modelling skills and expertise. For this scope to work smoothly, the inverter vendor and PPC vendor must supply satisfactory models with good guidance document and be readily available to provide technical support if needed. We have unfortunately had a few bad experiences with PSCAD / EMT models not being developed by the vendor who has then expected us to bug-hunt their models. Furthermore, NESO are becoming increasing difficult on the review process. Unfortunately there are often delays in the GC0141 EMT modelling process, and a key risk for Clients. Delays are typically caused by:

• OEM models (for the inverter or PCC) not having been sufficiently developed or tested before release to the consultant.
• OEM models not implementing the latest requirements from the Grid Code. A key risk here is PPCs that have not understood or implemented the de-load function for Storage Sites.  
• Models not correctly considering what protection needs to be included.
• The use of the wrong version of PSCAD or associated Fortran compiler and Visual Studio. Models that need a different time step to 10us.
• Failing to look at the NESO Guidance Note on GC0141

Summary

The GC0141 process requirements for modelling are one of the main causes for delay in achieving an ION and are a significant risk to a project. Unfortunately the GC0141 requirements are not overly clear, and they are a new requirement for developers and NESO – and NESO are continually bringing out further changes every few months. NESO are currently also planning to increase the review time for UDFS submissions to 20 business days and for EMT models to 6 weeks. So the whole review process will become longer and more difficult. To mitigate your project risks, make sure you give plenty of time to the modelling and simulation process, and that the site developers and OEMs understand the requirements of the process and models.