D9.5 Hardware-in-the-loop test environment and guidelines ...

94
PROMOTioN – Progress on Meshed HVDC Offshore Transmission Networks Mail [email protected] Web www.promotion-offshore.net This result is part of a project that has received funding form the European Union’s Horizon 2020 research and innovation programme under grant agreement No 691714. Publicity reflects the author’s view and the EU is not liable of any use made of the information in this report. CONTACT D9.5 – Hardware-in-the-loop test environment and guidelines for demonstrating non-selective protection systems for meshed HVDC grids

Transcript of D9.5 Hardware-in-the-loop test environment and guidelines ...

Page 1: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROMOTioN – Progress on Meshed HVDC Offshore Transmission Networks Mail [email protected] Web www.promotion-offshore.net This result is part of a project that has received funding form the European Union’s Horizon 2020 research and innovation programme under grant agreement No 691714. Publicity reflects the author’s view and the EU is not liable of any use made of the information in this report.

CONTACT

D9.5 – Hardware-in-the-loop test environment and guidelines for demonstrating non-selective protection systems for meshed HVDC grids

Page 2: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

1

DOCUMENT INFO SHEET

Document Name: Hardware-in-the-loop test environment and guidelines for demonstrating

non-selective protection systems for meshed HVDC grids

Responsible partner: SuperGrid Institute

Work Package: WP 9

Work Package leader: Ian Cowan, SHE Transmission

Task: 9.7

Task lead: SuperGrid Institute

DISTRIBUTION LIST

APPROVALS

Name Company

Validated by: University of Aberdeen

ABB

Task leader: William LEON GARCIA SuperGrid Institute

WP Leader: Ian COWAN SHE Transmission

WP

Number WP Title

Person

months Start month End month

WP 9 Demonstration of DC grid protection 122 30 54

Deliverable

Number Deliverable Title Type

Dissemination

level

Due

month

D9.5 Hardware-in-the-loop test environment and guidelines for demonstrating non-selective protection systems for meshed HVDC grids

Report Public 48

Page 3: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

2

LIST OF CONTRIBUTORS

Work Package and deliverable involve a large number of partners and contributors. The names of the partners,

who contributed to the present deliverable, are presented in the following table.

PARTNER NAME

SuperGrid Institute William LEON GARCIA

SuperGrid Institute Antoine GHYSELINCK

SuperGrid Institute Miguel ROMERO RODRIGUEZ

SuperGrid Institute Ahmed ZAMA

RWTH Aachen Patrick DÜLLMANN

Page 4: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

3

LIST OF DEFINITIONS / ABBREVIATIONS

TERM MEANING

ACCB AC Circuit Breaker

BF Breaker Failure

BM Breaking Module

CBM Converter Breaking Module

CBS Converter Breaker Protection Strategy

DBS Dynamic Braking System

DCCB DC Circuit Breaker

DUT Device Under Test DX.Y PROMOTioN Deliverable, where ‘X’ is the WP number and ‘Y’ is the

deliverable number of that WP e.g. D9.1

EMT Electromagnetic Transient

FBC Fault Blocking Converter

FBS Full-Bridge Protection Strategy

FB-MMC Full Bridge MMC

FCL Fault Current Limiter

FD Fault Detection

FI Fault Identification

FMA Failure Mode Analysis

GOOSE Generic Object-Oriented Substation Event

HB-MMC Half Bridge MMC

HDCCB Hybrid Dc Circuit Breaker

HIL Hardware-In-The-Loop

HSS High Speed Switch

HVDC High Voltage Direct Current

ICD IED Capability Description file

IED Intelligent Electronic Device

IGBT Insulated-Gate Bipolar Transistor

I/O Inputs / Outputs

KPI Key Performance Indicator

LBM Line Breaking Module

LCS Load Commutating Switch

LCZ Line Current Zero Control (Faulty Line)

MB Main Breaker

MDCCB Mechanical DC Circuit Breaker

MMC Modular Multilevel Converter

MTDC Multi-Terminal DC

MTTR Mean Time to Repair

OSI Open Systems Interconnection

PIR Pre-Insertion Resistor

Page 5: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

4

PRR Pole Rebalancing Reactor

PtG Pole to Ground

PtP Pole to Pole

RCB Residual Current Breaker

SCL Substation Configuration Language

SM Sub-module

SV Sampled Value

TCZ Terminal Current Zero Control

TIV Transient Interruption Voltage

TVZ Terminal Voltage Zero Control

TW Travelling Wave

UFD Ultra-Fast Disconnector

VSC Voltage Source Converter WPx PROMOTioN Work Package, where ‘x’ is the WP number e.g. WP9

Page 6: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

5

CONTENTS

DOCUMENT INFO SHEET ..................................................................................................................................................... 1

DISTRIBUTION LIST........................................................................................................................................................... 1

APPROVALS ....................................................................................................................................................................... 1

LIST OF CONTRIBUTORS ..................................................................................................................................................... 2

LIST OF DEFINITIONS / ABBREVIATIONS .......................................................................................................................... 3

1 INTRODUCTION TO DEMONSTRATION OF HVDC PROTECTION SYSTEMS ........................................................ 13

1.1 Introduction ............................................................................................................................................................ 13

1.2 Work plan .............................................................................................................................................................. 14

1.3 List of milestones and deliverables ........................................................................................................................ 15

1.4 Review of existing work on HVDC protection strategies ....................................................................................... 15

1.5 Gaps and opportunities ......................................................................................................................................... 17

1.6 Methodology .......................................................................................................................................................... 18

2 HIL TEST BENCH ......................................................................................................................................................... 20

2.1 Plant ...................................................................................................................................................................... 20

2.2 Devices under test ................................................................................................................................................. 21

2.3 Interface ................................................................................................................................................................. 24

2.4 Test bench ............................................................................................................................................................. 26

3 HVDC GRID MODELS FOR DEMONSTRATION OF NON-SELECTIVE PROTECTION STRATEGIES .................... 29

3.1 Four-terminal HVDC systems ................................................................................................................................ 29

3.2 DC cable ................................................................................................................................................................ 32

3.3 Converter and line breaking modules .................................................................................................................... 34

3.4 Ac network representation ..................................................................................................................................... 38

3.5 HB-MMC converter implementation ...................................................................................................................... 38

3.5.1 Introduction to HB-MMC converters .............................................................................................................. 38

3.5.2 Modelling ....................................................................................................................................................... 39

3.5.3 HB-MMC control ............................................................................................................................................ 40

3.6 FB-MMC converter implementation ....................................................................................................................... 41

3.6.1 Introduction to FB-MMC converters ............................................................................................................... 41

3.6.2 Modelling ....................................................................................................................................................... 42

3.6.3 FB-MMC control ............................................................................................................................................. 43

3.7 Functional tests ..................................................................................................................................................... 44

3.7.1 Benchmark network model 1 ......................................................................................................................... 45

3.7.2 Benchmark network model 2 ......................................................................................................................... 48

Page 7: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

6

4 PROTECTION SEQUENCES FOR NON-SELECTIVE STRATEGIES ......................................................................... 52

4.1 Protection sequences for converter breaker strategy ............................................................................................ 52

4.1.1 Primary sequence .......................................................................................................................................... 53

4.1.2 Converter breaker failure backup .................................................................................................................. 54

4.1.3 Line breaker failure backup sequence ........................................................................................................... 55

4.1.4 Protection algorithms ..................................................................................................................................... 55

4.2 Protection sequences for FB-MMC based fault clearing strategy ......................................................................... 57

4.2.1 Primary sequence .......................................................................................................................................... 57

4.2.2 HSS failure backup sequence ....................................................................................................................... 59

4.2.3 Protection algorithms ..................................................................................................................................... 59

5 FUNCTIONAL SPECIFICATIONS FOR SUPERVISION SYSTEM .............................................................................. 61

5.1 Introduction to supervision system ........................................................................................................................ 61

5.2 I/O specifications ................................................................................................................................................... 61

5.3 Algorithms to be included in the IED ..................................................................................................................... 67

5.3.1 Workflow ........................................................................................................................................................ 67

5.3.2 Supervisor synthesis...................................................................................................................................... 68

5.3.3 Code implementation ..................................................................................................................................... 72

6 DC GRID PROTECTION TESTING PROCEDURES .................................................................................................... 75

6.1 Efficiency indicators ............................................................................................................................................... 75

6.1.1 Active power restoration time ........................................................................................................................ 76

6.1.2 DC voltage restoration time ........................................................................................................................... 78

6.1.3 Fault interruption time .................................................................................................................................... 78

6.1.4 Reactive power restoration time .................................................................................................................... 79

6.1.5 Transient energy imbalance .......................................................................................................................... 80

6.2 IED performances .................................................................................................................................................. 81

6.2.1 Dependability and security............................................................................................................................. 81

6.2.2 Speed ............................................................................................................................................................ 82

6.3 Influence of real communication interface ............................................................................................................. 82

6.4 Calculating efficiency indicators ............................................................................................................................ 83

REFERENCES ...................................................................................................................................................................... 87

7 APPENDIX – PRELIMINARY TESTS: FEASIBILITY OF IEC61850 FOR CBS .......................................................... 89

Page 8: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

7

LIST OF FIGURES

FIGURE 1-1. PROMOTION WP9 SCOPE. ................................................................................................................................. 13

FIGURE 1-2. PROMOTION WP9 COMMON FRAMEWORK. .......................................................................................................... 14

FIGURE 1-3. WORK BREAKDOWN STRUCTURE INTERPRETATION AT SUPERGRID INSTITUTE FOR T9.7 AND T9.8 OF WP9. ............. 14

FIGURE 1-4. WORK PLAN PROPOSED BY SUPERGRID INSTITUTE FOR T9.7 AND T9.8 OF WP9. .................................................... 15

FIGURE 1-5. MAIN ELEMENTS IN THE HVDC GRID PROTECTION STRATEGY DESIGN. ..................................................................... 16

FIGURE 1-6. HVDC PROTECTION STRATEGY STEPS. .................................................................................................................. 16

FIGURE 1-7. GENERIC PROTECTION STRATEGIES DESCRIPTIONS. ............................................................................................... 17

FIGURE 1-8. GENERAL SCHEME OF AN HIL SET-UP. ................................................................................................................... 18

FIGURE 1-9. HIL TESTS PREPARATION WORKFLOW. .................................................................................................................. 19

FIGURE 1-10. HIL TESTING WORKFLOW. ................................................................................................................................... 19

FIGURE 2-1. SGI WORKSTATION WITH OPAL-RT® 5700 TARGET. ............................................................................................ 20

FIGURE 2-2. RASPBERRY PI 4B. ............................................................................................................................................... 21

FIGURE 2-3. WORKFLOW FOR PROTOTYPING THE IED IN AN RPI. ............................................................................................... 22

FIGURE 2-4. AXES OF DEVELOPMENT OF THE RPI-BASED IED PROTOTYPE FOR HVDC PROTECTION AND SUPERVISION. ............... 22

FIGURE 2-5. REQUIRED FILES TO GENERATE IED EXECUTABLE PROGRAM ON RPI. ..................................................................... 23

FIGURE 2-6. DATA STRUCTURE DEFINED IN IEC61850.. LOGICAL COMPONENTS OF AN IED [6]. .................................................. 25

FIGURE 2-7. COMMUNICATION ARCHITECTURE OF ELECTRICAL SUBSTATION BASED ON IEC61850 [7]. ........................................ 25

FIGURE 2-8. IED SIGNAL ROUTING IN PROTECTION AND SUPERVISION ARCHITECTURE. ................................................................ 27

FIGURE 2-9. BIPOLAR CONFIGURATION ARCHITECTURE (4 TERMINALS). GREEN: PROTECTION IEDS. ORANGE: STATION

SUPERVISOR IEDS. ......................................................................................................................................................... 27

FIGURE 2-10. RACK SYSTEM FOR RPI-4B. ............................................................................................................................... 28

FIGURE 2-11. DEMONSTRATION SET-UP ARCHITECTURE. .......................................................................................................... 28

FIGURE 3-1. ONE-LINE DIAGRAM OF THE FOUR-TERMINAL MESHED HVDC SYSTEM STUDIED IN WP9, PROPOSED IN [8]. ............... 30

FIGURE 3-2. LAYOUT UNDERGROUND TRANSMISSION CABLES. ................................................................................................... 32

FIGURE 3-3. CABLE GROUNDING CONCENTRATED ON EACH END. ............................................................................................... 33

FIGURE 3-4. CABLE GROUNDING REGULARLY DISTRIBUTED EACH 10 KM. ................................................................................... 33

Page 9: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

8

FIGURE 3-5. OFFLINE SIMULATION RESULTS FOR COMPARISON BETWEEN THE TWO GROUNDING MODELING APPROACHES. ............ 34

FIGURE 3-6. SCHEMATIC OF DC BREAKING MODULES MODELS USED IN WP4. ............................................................................ 35

FIGURE 3-7. DC BREAKER MODULE TEST CIRCUIT FOR CROSS-VALIDATION BETWEEN OFFLINE (EMTP®) AND REAL-TIME

(HYPERSIM®) MODELS. ................................................................................................................................................ 36

FIGURE 3-8. BREAKER CURRENT; UPPER SIDE: CURRENT DURING OPENING; LOWER SIDE: CURRENT DURING CLOSING. ................. 36

FIGURE 3-9. TOPOLOGY OF A HSS LOCATED AT LINE ENDS IN FBS, TAKEN FROM [1]. ................................................................ 37

FIGURE 3-10. (A) THREE-PHASE HALF-BRIDGE. (B) HALF-BRIDGE SUB-MODULE. ......................................................................... 38

FIGURE 3-11. SEMI-ANALYTICAL MODEL, ILLUSTRATION TAKEN FROM [14]. ................................................................................ 39

FIGURE 3-12. SUB-MODULE MODEL FOR HB-MMC IN HYPERSIM®. ........................................................................................ 39

FIGURE 3-13. INPUTS/OUTPUTS INTERFACES OF THE MMC CONTROL MODULE. ........................................................................... 40

FIGURE 3-14. FULL-BRIDGE MMC TOPOLOGY [15]. .................................................................................................................. 41

FIGURE 3-15. SEMI-ANALYTICAL MODEL SCHEME TAKEN FROM [14]. .......................................................................................... 42

FIGURE 3-16. OVERVIEW OF THE FB-MMC SUB-MODULE BLOCK IN HYPERSIM®. ................................................................... 43

FIGURE 3-17. FB-MMC CONTROL BLOCK IN HYPERSIM®. ...................................................................................................... 43

FIGURE 3-18. WORKFLOW TO IMPLEMENT A TEST PLANT FOR HIL TESTS. ................................................................................... 44

FIGURE 3-19. PLANT TESTING WORKFLOW, COMMUNICATION INTERFACE IS THE SAME FOR BOTH PROTOTYPES (IEC61850). ........ 45

FIGURE 3-20. SEQUENCED SUPERVISORY SYSTEM FOR THE HB-MMC STARTUP AND TEST FAULT SCENARIO. .............................. 46

FIGURE 3-21. START-UP SEQUENCE OF A FOUR-TERMINAL BASE IN HB-MMC CONVERTERS. ...................................................... 46

FIGURE 3-22. EMT WAVEFORMS FOR THE BENCHMARK NETWORK 1 SIMULATION DURING START-UP. ........................................... 47

FIGURE 3-23. VOLTAGES, ACTIVE AND REACTIVE POWER DURING A CBS FAULT SEQUENCE FOR THE BENCHMARK NETWORK 1..... 48

FIGURE 3-24. EMT WAVEFORMS FOR THE BENCHMARK NETWORK 1 SIMULATION DURING START-UP (PTOG)................................ 49

FIGURE 3-25. VOLTAGES, CURRENTS, ACTIVE AND REACTIVE POWER DURING A FBS FAULT SEQUENCE FOR THE BENCHMARK

NETWORK 1 (PTOP). ....................................................................................................................................................... 50

FIGURE 3-26. VOLTAGES, CURRENTS, ACTIVE AND REACTIVE POWER DURING A FBS FAULT SEQUENCE FOR THE BENCHMARK

NETWORK 1 (PTOG). ....................................................................................................................................................... 51

FIGURE 4-1. SWITCHGEAR LOCATION FOR CBS IN A SMALL-IMPACT HVDC MESHED NETWORK FROM [8]. ................................... 52

FIGURE 4-2. CONVERTER BREAKER FAULT CLEARING STRATEGY (CBS). PRIMARY, CONVERTER BREAKER AND LINE BREAKER

FAILURE SEQUENCES. ..................................................................................................................................................... 53

FIGURE 4-3. TIMELINE DESCRIBING THE CONVERTER BREAKER FAULT CLEARING STRATEGY (CBS). ............................................ 54

Page 10: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

9

FIGURE 4-4. CONVERTER BREAKER FAILURE SEQUENCE. .......................................................................................................... 55

FIGURE 4-5. FAULT DETECTION ALGORITHM. ............................................................................................................................. 56

FIGURE 4-6. FAULTY LINE IDENTIFICATION ALGORITHM. ............................................................................................................. 56

FIGURE 4-7. SWITCHGEAR LOCATION FOR FBS IN A SMALL-IMPACT HVDC MESHED NETWORK FROM [8]. .................................... 57

FIGURE 4-8. FB-MMC BASED FAULT CLEARING STRATEGY (FBS). PRIMARY FAILURE SEQUENCE. .............................................. 58

FIGURE 4-9. TIMELINE DESCRIBING THE FB-MMC BASED FAULT CLEARING STRATEGY (FBS). POSSIBLE CONTROL LOOPS OF THE

FB-MMC THAT CAN BE ENABLED THROUGH A FAULT. ....................................................................................................... 59

FIGURE 5-1: SUPERVISORY CONTROL DEVELOPMENT WORKFLOW. ............................................................................................. 67

FIGURE 5-2: CBM MODELS OF CONVERTER STATION 1, 2, 4 (LEFT) AND CONVERTER STATION 3 (RIGHT) ...................................... 69

FIGURE 5-3: SPECIFICATION AUTOMATON DESCRIBING THE ACTIVATION OF THE AC GRID SUPPORT DURING A SHORT-CIRCUIT FAULT.

...................................................................................................................................................................................... 69

FIGURE 5-4: SUPERVISOR OF STATIONS 2 AND 4 FOR THE NON-SELECTIVE PROTECTION MODE. ................................................... 70

FIGURE 5-5: SIMPLIFIED STATION SUPERVISOR AUTOMATON ...................................................................................................... 71

FIGURE 5-6: GRID SUPERVISOR FOR THE NON-SELECTIVE PROTECTION MODE. ONLY TO SHOW THE COMPLEXITY OF THE SUPERVISOR

FOR A NETWORK OF FOUR-TERMINALS. ............................................................................................................................ 71

FIGURE 5-7: MODES AUTOMATON. ........................................................................................................................................... 72

FIGURE 5-8: WORKFLOW TO GENERATE THE FOUR CONFIGURATION YAML FILES ....................................................................... 73

FIGURE 6-1. KPI CATEGORIES IN WP9. .................................................................................................................................... 75

FIGURE 6-2 EFFICIENCY KPIS FOR FAULT CLEARING STRATEGIES. ............................................................................................. 75

FIGURE 6-3. ILLUSTRATION OF THE ACTIVE POWER RESTORATION TIME FOR AN AC ZONE (AC1). ................................................ 76

FIGURE 6-4: HVDC GRID CONNECTING TWO DIFFERENT AC ZONES. ........................................................................................... 77

FIGURE 6-5: ACTIVE POWER RESTORATION TIME FOR DIFFERENT ZONES. ................................................................................... 77

FIGURE 6-6. ILLUSTRATION OF THE VOLTAGE RESTORATION TIME FOR A DC GRID BUS. ............................................................... 78

FIGURE 6-7. FAULT CURRENT INTERRUPTION PROCESS OF A DC MECHANICAL BREAKER............................................................. 79

FIGURE 6-8: ILLUSTRATION OF THE READY TO RESTORE REACTIVE POWER TIME FOR ONE AC ZONE (AC1). ................................. 80

FIGURE 6-9: ILLUSTRATION OF ELEMENTS USED IN THE CALCULATION OF ENERGY IMBALANCE FOR ONE AC ZONE (AC1). ............ 80

FIGURE 6-10. IED PERFORMANCE INDICATORS. ........................................................................................................................ 81

FIGURE 6-11 DEPENDABILITY CURVES FOR UNDERREACHING AND OVERREACHING ELEMENTS [1]. ............................................... 81

Page 11: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

10

FIGURE 6-12. CHARACTERISTICS OF THE COMMUNICATION LINK USING IEC61850. ..................................................................... 82

FIGURE 6-13: PROCEDURE FOR THE CALCULATION OF THE EFFICIENCY INDICATORS. .................................................................. 83

FIGURE 6-14. PROPOSED TEST CASES TO COMPUTE KPIS FOR CBS AND FBS. NOTE: HALF THE CASES WILL BE TESTED IN CBS

DUE TOPOLOGY ASSUMPTIONS......................................................................................................................................... 84

FIGURE 6-15. FAULT LOCATIONS AND CABLE DISTANCES FOR HIL TESTS OF THE 4T MESHED HVDC NETWORK. .......................... 84

FIGURE 6-16. PROPOSED TEST CASES TO STUDY COMMUNICATION IMPLEMENTATION IMPACT ON CBS AND FBS. ........................ 85

FIGURE 7-1: THREE-TERMINAL HDVC TEST NETWORK WITH COMMUNICATION LINKS ILLUSTRATED. ............................................. 89

FIGURE 7-2. DCCB TRIPPING SIGNALS. 0: OPENED, 1: CLOSED. ................................................................................................ 89

FIGURE 7-3. SUCCESSFUL FAULT SEQUENCE AND CLEARING USING PROTOTYPED IEDS IN A 3T GRID. ......................................... 90

FIGURE 7-4. PRINTED MESSAGES WHEN LAUNCHING IED PROGRAM IN RPI. ............................................................................... 91

FIGURE 7-5. LATENCY MEASURED FOR 10 DIFFERENT LOOP BACKED SV AND GOOSE MESSAGES. ............................................. 92

FIGURE 7-6. DATA GENERATED BY SIMULATION AT SAMPLING RATE OF 40 KHZ. ......................................................................... 92

FIGURE 7-7. DATA STORED FROM THE SV LISTENER THREAD (FUNCTION IN CHARGE OF HEARING SV MESSAGES) ........................ 93

FIGURE 7-8. DATA STORED FROM WHILE (1), THE PROGRAM EXECUTING PROTECTION FUNCTIONS IN PROTECTION IED. ................ 93

Page 12: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

11

LIST OF TABLES

TABLE 2-1. FEATURES EXTRACTED FROM THE OPAL-RT® DOCUMENTATION ............................................................................. 20

TABLE 2-2. RASPBERRY PI 4 MODEL B SYSTEM SPECIFICATIONS. .............................................................................................. 21

TABLE 2-3. IED PROGRAM, SECTIONS DESCRIPTION. ................................................................................................................. 24

TABLE 2-4. DATA COMMUNICATION ACCORDING TO OSI MODEL. ................................................................................................ 24

TABLE 3-1. BENCHMARK GRID CHARACTERISTICS STUDIED IN WP9: TASKS T9.7/T9.8. .............................................................. 29

TABLE 3-2. BENCHMARK NETWORK 1 PARAMETERS. ................................................................................................................. 31

TABLE 3-3. BENCHMARK NETWORK 2 PARAMETERS. ................................................................................................................. 31

TABLE 3-4. CABLE GEOMETRICAL DATA USED FOR BENCHMARK NETWORK 1.............................................................................. 32

TABLE 3-5. CABLE MATERIAL DATA USED FOR BENCHMARK NETWORK 1. ................................................................................... 32

TABLE 3-6. CABLE GROUND PARAMETERS. ............................................................................................................................... 32

TABLE 3-7. ELECTRICAL SPECIFICATIONS OF CBM AND LBM MODELS. ..................................................................................... 35

TABLE 3-8. ADDITIONAL SPECIFICATIONS ON THE DC BREAKING MODULE. ................................................................................. 35

TABLE 3-9. ELECTRICAL SPECIFICATIONS OF UFD MODEL. ........................................................................................................ 37

TABLE 3-10. ELECTRICAL SPECIFICATIONS OF RCB MODEL. ..................................................................................................... 37

TABLE 3-11. HB-MMC SUB-MODULE PARAMETERS. ................................................................................................................. 40

TABLE 3-12. TUNABLE PARAMETERS OF MMC CONTROL MODULE. ............................................................................................ 41

TABLE 3-13. FB-MMC SUB-MODULE PARAMETERS. .................................................................................................................. 42

TABLE 3-14. MMC STATES AND PARAMETERS DURING A TEST SEQUENCE. ................................................................................. 47

TABLE 4-1: PARAMETERS OF PROTECTION ALGORITHMS. .......................................................................................................... 56

TABLE 4-2. PARAMETERS OF PROTECTION ALGORITHMS. .......................................................................................................... 60

TABLE 5-1. STATION SUPERVISORS IED, INPUT SIGNALS ........................................................................................................... 62

TABLE 5-2. STATION SUPERVISORS, OUTPUT SIGNALS. .............................................................................................................. 64

TABLE 5-3. GRID SUPERVISOR IED, INPUT SIGNALS. ................................................................................................................. 65

TABLE 5-4. GRID SUPERVISOR IED, OUTPUT SIGNALS. .............................................................................................................. 66

TABLE 6-1: MEASUREMENTS REQUIRED FOR EACH EFFICIENCY KPI. .......................................................................................... 85

TABLE 6-2. MEASUREMENTS REQUIRED FOR IED KPIS. ............................................................................................................ 85

Page 13: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

12

TABLE 6-3. PROTECTION STRATEGY EFFICIENCY KPIS FOR ALL FAULT CASES WITH BEST COMMUNICATION PERFORMANCES SET. . 86

TABLE 6-4. IED KPIS FOR ALL FAULT CASES WITH BEST COMMUNICATION PERFORMANCES SET.................................................. 86

TABLE 6-5. PROTECTION STRATEGY EFFICIENCY KPIS CALCULATED FOR THE WORST CASE SCENARIO AND DEGRADED

COMMUNICATION SETTINGS. ............................................................................................................................................ 86

TABLE 6-6. IED KPIS CALCULATED FOR THE WORST CASE SCENARIO AND DEGRADED COMMUNICATION SETTINGS. ..................... 86

Page 14: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

13

1 INTRODUCTION TO DEMONSTRATION OF HVDC PROTECTION SYSTEMS

1.1 Introduction

The objective of WP9 is to demonstrate operation of the DC grid protection systems developed in the project using

hardware in the loop real-time methods. This WP will integrate results from DC CB modelling (WP6 and WP10)

and DC protection development (WP4) including hardware prototype of relay to be tested at The National HVDC

Centre facility (Scotland) and demonstration of DC Grid protection system interoperability. A plurality of protection

methods (or strategies) will be tested, to reflect main results of WP4. Selective fault clearing strategies

demonstration tests will be carried out at the National HVDC Centre facility (Scotland). Non-selective fault clearing

strategies demonstration tests will be carried out at the SuperGrid Institute (France). In each case, DC Grid

protection system interoperability will be addressed in the scope of the demonstration at the two facilities:

Figure 1-1. PROMOTioN WP9 scope.

The specific objectives of WP9 are:

• To integrate IEDs and protection strategies from WP4 and DCCB models from WP6 in real-time

simulation environments.

• To develop DC grid benchmark models and test procedures for protection system testing.

• To demonstrate protection system performance using hardware in the loop real-time testing

• To demonstrate primary and back-up DC Grid protection and system level consequences of

protection failure.

• Demonstrate equipment interoperability (possibly by testing DC protection components from

different manufacturers, or through the implementation of industrial communication protocol for

protection relays, like IEC 61850 standard.

• To demonstrate DC grid restoration performance after protection process.

Page 15: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

14

Figure 1-2 illustrates the framework for WP9 in the PROMOTioN project. and relate to the other WPs and main

participants per task. Non-selective fault clearing strategies are demonstrated through tasks 9.7 and 9.8, similarly

to selective but condensing tasks in two phases: preparation and test phases. It also takes as input models from

WP4, WP9 but also WP16. A coordination is specially required for defining a benchmark grid and test guidelines.

Figure 1-2. PROMOTioN WP9 common framework.

1.2 Work plan

Tasks T9.7 and T9.8 are structured in subtasks as shown in the following work breakdown structure scheme:

Figure 1-3. Work breakdown structure interpretation at SuperGrid Institute for T9.7 and T9.8 of WP9.

The updated planning at the end of 2019 is the following:

Page 16: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

15

Figure 1-4. Work plan proposed by SuperGrid Institute for T9.7 and T9.8 of WP9.

1.3 List of milestones and deliverables

• MS81: Full-bridge converter models are delivered

• MS82: Relays and grid models successfully integrated in real-time simulation environment and

project moves to testing

• MS83: Supervisor prototype for HVDC system restoration ready

• MS84: Non-selective Protection systems successfully demonstrated (open-loop system restoration)

• MS85: Non-selective Protection systems successfully demonstrated (closed-loop system

restoration)

• D9.5: Hardware-in-the-loop test environment and guidelines preparation for non-Selective

protection systems demonstration

• D9.6: Demonstration of Non-Selective protection systems interoperability, primary and back-up

protection

1.4 Review of existing work on HVDC protection strategies

According to [1] an HVDC grid fault clearing strategy can be considered as a collection of choices about how the

fault occurrence will be managed in the system. As illustrated in the scheme hereunder, three main aspects

influence these choices: the system architecture, technologies and protection sequences and algorithms (see

Figure 1-5).

Page 17: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

16

Figure 1-5. Main elements in the HVDC grid protection strategy design.

By system architecture in Figure 1-5 it must be understood the arrangement of the system and aspects regarding

its structure such as: topology (e.g. cables or overhead lines, bipolar or monopolar configuration, meshed or radial

grid, or a mix of the previous options), the size of the grid (depending on the number of terminals and length of

the lines), and AC grid connected (e.g. onshore AC systems or windfarms, a strong or weak AC grid, etc.).

The technology to be used is also an important element of the HVDC protection strategy design. It is related to

aspects such as budget of the project, feasibility and what is available in the market. The technology choices

consist in decisions about the protection equipment that will be used to perform the different stages of the

protection strategies.

A protection strategy can have several protection sequences (one primary sequence and numerous backup

sequences) and use different kind of algorithms (overcurrent, undervoltage, directional current, differential current,

transient wave...). It can be mainly divided into two stages, the fault clearing and DC grid restoration as shown in

the next timeline Figure 1-6.

Figure 1-6. HVDC protection strategy steps.

The fault clearing starts with the fault occurrence and finishes with the faulty component isolation. The DC grid

restoration is also part of the protection strategy since it is intrinsically related to the actions of the protection

components. The way how to perform these steps depends on the adopted protection strategy. For instance, in

a non-selective strategy the identification of the faulty component and the suppression of the fault current are

parallel steps, while in a fully selective strategy they are sequential, as shown in the illustration below:

Page 18: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

17

Figure 1-7. Generic protection strategies descriptions.

In this project two non-selective protection strategies have been selected for validation through HIL tests: the fault

clearing strategy using mechanical DC breakers at station outputs (HB-MMC) and the fault clearing strategy based

on fault-blocking converters (FB-MMC). They are briefly described in the next sections.

1.5 Gaps and opportunities

In WP4, several fault clearing strategies were developed, namely, non-selective, partially and full-selective. These

strategies were tested in WP4 using offline simulation tools such as PSCAD and EMTP®. In terms of technology

readiness level, offline simulations allow reaching TRL-3 [2]. To move forward in the TRL scale, fault clearing

strategies need to be implemented in a close-to-reality environment. This is a challenging task because these

fault clearing strategies are not a tangible product; they are sequences of events executed through algorithms.

Their effectiveness in a real environment will depend on their implementation using available technology. These

algorithms can be programmed in devices known as Intelligent Electronic Devices (IEDs): electronic equipment

capable of executing control and protection algorithms with communication capabilities to exchange data within a

power substation.

To increase the TRL level of fault clearing strategies, IEDs must be prototyped in a first place because there are

no industrial IEDs for HVDC network in the market. Two implementation approaches are tested within WP9:

• KTH IED [3]:

o This IED will be tested in The HVDC Centre through tasks T9.1-T9.6. This implementation

is focused in ultra-fast algorithm implementation capabilities, it is based on a ZedBoard

(mixed FPGA with ARM processor technology). It uses analog communication interface.

Ultra-fast capabilities are specially required for selective protection strategies.

• SuperGrid IED:

o Will be tested in the SuperGrid Institute through tasks T9.7-T9.8. The implementation is

focused on the communication rather than the speed of the IED. It is based on Raspberry

PI 4B (ARM processor-based microcomputer). It uses digital communication through

Page 19: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

18

Ethernet with IEC61850 protocol. Lower speeds are suitable for non-selective protection

strategies.

Testing IEDs in an HIL setup is preferred over testing in field, especially when no HVDC meshed networks have

been built yet. In power network applications, HIL is meant to reduce time-to-market and lower the risk of new

equipment affecting the network by studying their impact beforehand using EMT real-time models [4]. An HVDC

meshed system simulated in real-time will generate the proper data to feed the IED and test the algorithms that

execute the fault clearing strategies in a closed-loop configuration. These tests are the main scope of WP9,

increasing the maturity of fault clearing strategies to TRL-5.

Filling this gap between TRL-3 (from WP4 tests) and TRL-5 (through WP9) is what the SuperGrid Institute aims

to contribute through tasks T9.7 and T9.8. These tasks will be focused on non-selective fault clearing strategies

only. For this purpose, models developed for offline simulations are evolved into real-time models with the

collaboration of other WPs. Namely, RTS models for DC circuit breakers (WP6), protection algorithms and

converter models (WP4).

1.6 Methodology

In general, a hardware-in-the-loop test set-up can be divided into three main parts. The first part is the simulated

plant, in this case a simulation of the power transmission network. The second part is the device under test (DUT),

a piece of hardware that interacts with the plant simulation and perform functions such as protection, control or

supervision of the plant. The third part of the HIL set-up is the physical interface between the plant and the DUT.

The following illustration shows these three main parts and examples of plants and DUT for this application field.

Figure 1-8. General scheme of an HIL set-up.

The system under study in WP9 is an HVDC transmission network. The system configuration and parameters

have been a matter of discussion since the beginning of the project. A list of meaningful network configurations

was published in deliverable D4.1 [1]. The plant simulated in our test bench follows the specifications given in

D4.1. The system is described latter in section 3.1. Preparing the plant simulation is one of the main time-

Page 20: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

19

consuming tasks when performing HIL tests. The process of preparing a simulation goes from testing available

real-time models individually until testing the different operation modes of the whole system. The objective of this

deliverable is to present a summary of this preparation phase.

Figure 1-9. HIL tests preparation workflow.

Once the plant is ready and the DUT and interfaces are defined, the system is put altogether and configured to

run tests. Four steps are identified to achieve this:

Figure 1-10. HIL testing workflow.

The testing phase is part of the deliverable D9.6 that marks the end of the demonstration of non-selective fault

clearing strategies in WP9.

Develop models

•Choose the level of model refinement.

•Provide correct interfaces: I/O pins and tunable parameters.

Test models

•Provide a simplified test environment.

•Run off-line tests to compare with other models.

•Run real-time tests to check computation time.

Build plant

•Build the HVDC network interconnecting models.

•Anticipate tests with a neat arrangement of the plqnt and providing a clear system description.

Test plant

•Off-line: verify the plant behavior under same operating conditions expected for tests.

•Real-time: check stability of real-time simulation.

Configure IEDs

•Import algorithms.

•Configure parameters (thresholds, initial values).

•Configure communication.

Configure system

•Find and prepare I/Os.

•Configure communication

Configure tests

•Automatize tests

•Choose meaningful data to monitor

•Prepare data to log for post-processing

Run tests

•Analyze test results

•Decide on results weather to repeat a test or keep results

Page 21: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

20

2 HIL TEST BENCH

2.1 Plant

The simulation of the plant is done with OPAL-RT® simulation engines. The plant is designed using HYPERSIM®.

The following table describes the system from the manufacturer point of view:

Table 2-1. Features extracted from the OPAL-RT® documentation

Items Quantity Description

Operating system 1 Redhat v2.6.29.6-opalrt-6.1

Chassis type 1 OP5700

Motherboard 1 X10DRL-I Supermicro

CPU

2 Intel Xeon E5,

8 Cores (16 in total)

3.2 GHz

20M Cache

Figure 2-1. SGI Workstation with OPAL-RT® 5700 target.

Page 22: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

21

2.2 Devices under test

As mentioned previously, one of the main objectives of WP9 is to increase the TRL level. For this purpose, it is

important to choose the technology that cope with the requirements of the protection sequences. The approach

at the SuperGrid Institute is to use Raspberry Pi single-board computers as target hardware for the development

of the required IEDs. Processing and communication times required for non-selective fault clearing strategies are

in the range of 0.1 – 5 ms, depending on the algorithms that are used (algorithms are discussed in section 4 ).

In addition, ARM processors are commonly found in embedded electronics used in industrial equipment. Among

other reasons for choosing this hardware are:

• Low cost (~60€ p/u)

• High processing power in a compact board

• Many interfaces (Gigabit Ethernet, onboard Wi-Fi, many GPIOs)

• Linux environment, easy for custom applications (communication, protection and supervision programs)

using C programming language.

• The possibility to use a complete and well documented IEC61850 library based in C (IEC61850 is

explained later in this section). The implementation of an industrial communication standard ensures

significance of this IED prototype approach.

Figure 2-2. Raspberry pi 4b.

The model that is going to be used during the HIL tests is the Raspberry Pi 4B, its main characteristics are shown

in the table below:

Table 2-2. Raspberry Pi 4 model B system specifications.

Items Quantity Description

System on Chip 1 Cortex-A72 processor

64 Bit

4 Cores

Clock speed 1.5 GHz

RAM 4 GB LPDDR4 SDRAM

Communication 1 Gbit ethernet port

Page 23: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

22

The process of prototyping the IED is shown in the next figure:

Figure 2-3. Workflow for prototyping the IED in an RPI.

Algorithms for supervision and protection have been tested beforehand using offline simulation tools such as

Simulink, EMTP® and PSCAD. To run these algorithms in a target hardware (or DUT) they must be provided in

C code. The C code can be written from scratch if there is a rich description of the algorithms to be performed

(specifications, documentation...). It can be also generated from third party software such as Supremica® or

Simulink, that should allow faster implementation avoiding the need of expert programming skills. For the CBS,

protection algorithms were written in C++ to be included in EMTP® offline simulations, this code was translated

to C for the RPI prototype. The supervision model was using Supremica®, a software used for designing automata

based on discrete events, from which C code can be generated. In the case of the FB-MMC based protection

strategy, algorithms were implemented using Simulink models, which can also generate C code for real-time

simulation using HYPERSIM®.

The IED prototypes as mentioned before are RPI-4B devices programmed with the necessary functionalities for

protection, supervision and communication. As observed in Figure 2-4, the main axes for the development of

RPI-based IEDs have been identified as follows:

Figure 2-4. Axes of development of the RPI-based IED prototype for HVDC protection and supervision.

Page 24: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

23

• Inputs (left)

o Algorithms, in C code, to generate a source of functional source codes.

o Specifications: how to relate functions, sequences (in UML language for instance), values for

constants and data types.

o ICD files, which provide information on how to configure the communication.

• Development (up)

o How to implement the IED program. For this mean, an object-oriented programming approach

was used, to ensure modularity and the possibility to update functions easily.

o Define structures, general function blocks, that can be used in different IED configurations (i.e.

communication configuration, initialization functions, algorithms and mathematical functions).

• Performances (down)

o The use of RPI for the implementation of IEDs under the framework of non-selective protection

strategies will allow us to measure the impact of such implementation to the performances of

the system, generating recommendations for future IED prototyping and find ways of

improvement.

• Outputs (right)

o Once the IED prototype is ready, it is connected to the simulation using the I/O interface, in this

case, an RJ45 cable.

An insight on how these IEDs are programmed and configured is given in this chapter. The main structure of the

C program that runs in the RPI4 environment is described in the next scheme:

Figure 2-5. Required files to generate IED executable program on RPI.

The IED main code is divided in two parts, a first section comprises initialization and configuration lines, the

second part is a While (1) loop that executes the algorithm functions for supervision and protection but also a

parallel thread that manages the IEC61850 communication standard (see Table 2-3).

Page 25: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

24

Table 2-3. IED program, sections description.

Section Description

1

Relay initialization and parametrization

Constants and variables used in the algorithms are initialized (thresholds, delays, temporary values…)

Memory pre-allocation to store SV and GOOSE

Voltages, currents, tripping signals are all initialized and assigned into memory slots.

SV and GOOSE configuration Each SV and GOOSE is given a unique ID and given the addresses in

memory corresponding to the voltage, current or tripping signal.

Clock initialization A clock used to use delays and limit the execution period of the

algorithms.

2

IED reset function A function to reinitialize the IED, putting back variables and parameters to

their initial value.

IED algorithms call Pass updated values of SV and GOOSE and call protection algorithm

functions

Update GOOSE

Save old values Some values that require historical data are saved to be used in the next

round of the while loop.

1: Main, 2: While (1) loop

The IEC61850 communication standard is managed by the IED using an open source code library available in [5].

Only the source codes to configure and generate SV and GOOSE packets are used for this IED prototype.

Makefiles and linkers are provided also in this source code and the program is then generated using GCC compiler

in Linux environment.

2.3 Interface

IEC 61850 is a standard for the design of electrical substation automation. IEC 61850 is a part of the International

Electrotechnical Commission's (IEC) Technical Committee 57 reference architecture for electric power systems.

The abstract data models defined in IEC 61850 can be mapped to several protocols. Current supported mappings

in the standard are to GOOSE (Generic Object-Oriented Substation Event) and SV (Sampled Values). These

protocols can run over substation LANs using high-speed Ethernet switches to obtain the necessary response

times for AC protective relaying.

Table 2-4. Data communication according to OSI model.

Application layer MMS SV GOOSE SNTP

Presentation layer

Oriented Connection

Session layer

Transport layer TCP UDP TCP

Network layer IP IP

Data link layer Ethernet

Physical layer Optical Fiber

Page 26: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

25

The impact of such communication performances to non-selective fault clearing strategies in HVDC networks is

expected to be one of the main conclusions of these studies. All the communication is in an Ethernet Local Area

Network. Messages via Ethernet are high priority in the network and are delivered quickly.

To define an IED, we use the SCL language based on XML. Functionalities, relationships and communications

within a network are defined in what is called an IED capability description file (ICD). The ICD file describes the

physical device and the logics of protection and controls are defined via the Logical Node (LN, see Figure 2-6).

Figure 2-6. Data structure defined in IEC61850.. Logical components of an IED [6].

Substations using IEC61850 use two kind of communication buses, the process and the station bus (Figure 2-7),

that transport different kinds of traffic.

Figure 2-7. Communication architecture of electrical substation based on IEC61850 [7].

Page 27: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

26

Client/Server traffic (also known as MMS under this protocol) is only present on the station bus, while the process

bus is exclusively for Sampled Values (SV). GOOSE may be on both. When no SV are used and only a station

bus exists, the GOOSE messages are of course also sent over the station bus. Typically, this is not a problem,

because the bandwidth required for GOOSE is low in most cases. When a process bus is deployed, the GOOSE

messages will more likely be on the process bus, because of their process-close real-time nature. This process

bus corresponds to the physical ethernet switch. Only the process bus events are concerned in the WP9 scope,

which is through which the information about the protection strategy will be most likely flowing. These are the SV

and GOOSE messages carrying necessary measurement values (currents, voltages…) and logic signals (tripping,

states…) respectively.

Using the substation configuration language defined in the IEC61850 standard helps structuring the

communication architecture using a functional approach. With this approach, the devices that we call IEDs

become logical devices and their functions are known as logical nodes. Each logical node is associated to a signal

that can be either a GOOSE or SV. These signals are known as data objects. Data objects are packets of data

pre-defined in IEC61850 for power substation automation and protection, but new propositions can be made

specially in new technologies such as HVDC networks. The type of data is defined by the data attribute, a property

of the data object. Many kinds of data types are managed by IEC61850 (Boolean, int8, int16, float, double...). The

direction of the signal (input or output) is defined in the standard as a publish (send) or subscribe (receive) action.

To use the IEC 61850 protocol the OP5700 engine has a built-in IEC61850 card and driver that manages the

protocol functions to generate SV and GOOSE messages. ICD files are directly imported through the

HYPERSIM® interface and signals from the simulation can be associated to either type of message. Preliminary

tests in three-terminal HVDC networks shows the feasibility of using IEC 61850 for the CBS strategy (see

APPENDIX 7 ).

2.4 Test bench

In order to put together plant, DUT using the chosen interface, an architecture of the communication system must

be defined. To define this architecture, a functional analysis of the studied HVDC system is performed, to identify

the interactions between the power components and the IEDs. For instance, the IED must process measured

currents and voltages sent by Merging Units (MU) through SV messages. The network supervisors will mostly

read the state of the network through signals sent from the different power component IEDs. States will flow

though GOOSE messages. Protection IEDs will also send GOOSE messages to order the tripping of circuit

breakers. An overview of the communication architecture proposed for WP9 is shown in Figure 2-8 for a single

HVDC station.

IEDs are needed to implement:

• LBM Relays (RLBM)

• CBM Relays (RLBMs)

• Station Supervisors

• Central supervisor

Page 28: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

27

Figure 2-8. IED signal routing in protection and supervision architecture.

A wider view of the HVDC system is shown in Figure 2-9 with the aim of estimating the required amount of IEDs

for a single pole.

Figure 2-9. Bipolar configuration architecture (4 terminals). Green: Protection IEDs. Orange: Station Supervisor IEDs.

Page 29: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

28

For example, if one IED represents only one relay, the total amount of IEDs required per pole is:

• Seven IEDs for RLBMs

• Four IEDs for RCBMs (the antenna needs only one IED for converter and line)

• Four IEDs for station supervisors

• One IED for the central supervisor

Therefore, sixteen RPI-4B are required. These devices will be mounted in a rack with power and thermal capacity

for holding up to 20 RPI model 4B devices (see Figure 2-10).

Figure 2-10. Rack system for RPI-4B.

Figure 2-11 shows the different components of the HIL test. The complexity relies on the number of signals to be

exchanged within a single process bus. An initial estimation of how many signals will be flowing through the

network goes up to around 30 SV and more than 100 GOOSE messages, assuming a configuration in which all

these messages flow through a single physical process bus (ethernet switch).

Figure 2-11. Demonstration Set-Up Architecture.

Page 30: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

29

3 HVDC GRID MODELS FOR DEMONSTRATION OF NON-SELECTIVE PROTECTION STRATEGIES

This section describes the RTS models that have been used to build the HVDC benchmark network. These

models were built based on knowledge about the system behavior and deliverables from WP6 and WP4.

3.1 Four-terminal HVDC systems

A four-terminal network for small-impact system studies has been proposed in [1]. Offline simulation studies were

carried out in WP4 using this network architecture for the proof of concept of two non-selective protection

strategies: CBS and FBS. Modelling was done using EMTP® and PSCAD respectively for WP4. In WP9 it is

required that system models are upgraded from offline to RTS models for CBS and FBS, both using HYPERSIM®

by OPAL-RT®, in order to perform HIL tests. A simplified view (single pole) of the 4T system is given in Figure

3-1. The following is a list of main elements presented in Figure 3-1. More details about each model will be given

in sub-sequent chapters.

Table 3-1. Benchmark grid characteristics studied in WP9: tasks T9.7/T9.8.

BENCHMARK GRID 1 (CBS) BENCHMARK GRID 2 (FBS)

1

AC Grid Two strong (land side): AC network 1 and 2

Two weak (offshore side): AC network 3 and 4

Configuration Bipole Monopole

Grid size 4 stations (meshed)

Grounding Solid ground at each station Star point reactor

2

Converters HB-MMC FB-MMC

Communication IEC61850

AC switching equipment

ACBM:

Only required during start-up. Scenarios in which ACBMs are required to open during a DC fault have not been considered in test cases for

CBS and FBS.

DC switching equipment CBM and LBM:

MDCCB + RCB

LBM:

RCB + UFD

Sensors Ideal (*)

3

Restoration means PIR at MDCCB

HB-MMC control FB-MMC control

Converter controls HB-MMC provided by SuperGrid

Institute FB-MMC provided by RWTH Aachen

Fault clearing philosophy Converter breakers

at station output Fault blocking converters

(FB-MMC) based

*RT simulation target converts data from simulation into SV and GOOSE packets.

1: System architecture; 2: Technology; 3: Protection sequence and algorithms

Page 31: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

30

SMALL IMPACT STUDY NETWORK TOPOLOGY FOR PROMOTION WP9 T9.7/T7.8

*For CBS the converter is HB-MMC in bipole, solidly grounded inside the converter (star-point reactor is absent), CBM is present. For FBS the converter is a FB-MMC in monopole, with star-point reactor for grounding, CBM is absent. †Only one pole is illustrated for simplicity, the negative pole is symmetrical for both bipolar and monopolar cases:

Figure 3-1. One-line diagram of the four-terminal meshed HVDC system studied in WP9, proposed in [8].

Page 32: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

31

While certain specifications given in [1] for the small-impact system where respected by both, it was not possible

to align on some of them. When writing this report, functions for voltage rebalancing were not available in the first

version of IEDs and supervision systems. For this reason, benchmark grid 1 has been configured in bipole. Indeed,

in a bipolar HVDC network there is no need for voltage rebalancing in case of pole-to-ground fault. Modifying the

benchmark grid 1 into a monopole is not difficult, but models of power components for pole rebalancing and new

IED and supervision functions are needed. On the contrary, benchmark grid 2 can be configured in monopole and

be tested against pole-to-ground and pole-to-pole faults since pole re-balancing is part of the converter functions,

meaning no dedicated power components or IED functions are needed in addition to the converter.

In HYPERSIM®, the main difference between bipole and monopole will be the number of converters. In the bipole

case, eight HB-MMC converters will be simulated. In the monopole case, four FB-MMC converter will be

simulated. The remaining components (downstream from CBM) are symmetrical and are present in both

monopole and bipole configurations.

Table 3-2. Benchmark network 1 parameters.

Item Station 1 Station 2 Station 3 Station 4

Rated Apparent Power (S) 632MVA 632MVA 632MVA 632MVA

Rated Active Power (P) per pole ±632MW ±632MW ±632MW ±632MW

Converter Nominal DC Voltage ±160kV ±160kV ±320kV ±160kV

Converter Nominal AC voltage 160kV 160kV 160kV 160kV

AC Grid Voltage 400kV 400kV 400kV 400kV

Nominal Frequency 50Hz 50Hz 50Hz 50Hz

SCR 20 20 6 6

X/R Ratio 10 10 10 10

Transformer rated Power 632MVA 632MVA 632MVA 632MVA

Transformer Voltage ratio (Yg-D) 400/320kV 400/320kV 400/320kV 400/320kV

Transformer Reactance 0.15pu 0.15pu 0.15pu 0.15pu

*values for bipolar configuration

Table 3-3. Benchmark network 2 parameters.

Item Station 1 Station 2 Station 3 Station 4

Rated Apparent Power (S) 1265MVA 1265MVA 1265MVA 1265MVA

Rated Active Power (P) per pole ±1265MW ±1265MW ±1265MW ±1265MW

Converter Nominal DC Voltage 640kV (±320kV) 640kV (±320kV) 640kV (±320kV) 640kV (±320kV)

Converter Nominal AC voltage 350kV 350kV 350kV 350kV

AC Grid Voltage 400kV 400kV 400kV 400kV

Nominal Frequency 50Hz 50Hz 50Hz 50Hz

SCR 20 20 6 6

X/R Ratio 10 10 10 10

Transformer rated Power 1265MVA 1265MVA 1265MVA 1265MVA

Transformer Voltage ratio 400/350kV 400/350kV 400/350kV 400/350kV

Transformer Reactance 0.16pu 0.16pu 0.16pu 0.16pu

*values for monopolar configuration

Page 33: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

32

3.2 DC cable

The cable models from SGI and RWTH will be presented in these tables below. Cable data is based on WP2 data

published in [9].

Figure 3-2. Layout underground transmission cables.

Table 3-4. Cable geometrical data used for benchmark network 1.

Table 3-5. Cable material data used for benchmark network 1.

Table 3-6. Cable ground parameters.

The main assumptions concerning the cable model is that its grounding (of screening parts) is considered regularly

distributed across its length. This is a valid assumption for the scope of WP9 demonstration since the effect of

Number of cables

Number of conductors

h: Vertical distance (m)

Dipole: Horizontal distance (m)

Outer radius of insulation (mm)

1 2 1.33 -0.25 63.8

2 2 1.33 0.25 63.8

Material properties

Cable No. 1 1 2 2

Conductor Core Screen Core Screen

Internal radius (mm) 0 56.9 0 56.9

External radius (mm) 32 58.2 32 58.2

Resistivity (Ω.m) 1.72e-08 2.83e-08 1.72e-08 2.83e-08

Relative permeability 1 1 1 1

Relative permeability of insulation 1 1 1 1

Relative permittivity of insulator 2.5 2.5 2.5 2.5

Loss factor of insulator 4e-03 4e-03 4e-03 4e-03

Number of phases 1 2 3 4

Ground parameters

Ground resistivity (Ω/m) 100

Ground relative permeability 1

Cut-off frequency of conductance (Hz) 100

Page 34: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

33

grounding defects is not under the aim of this demonstration. A wideband cable model in HYPERSIM® has been

studied in offline and imported into HYPERSIM® via data files. Both grounding modelling approaches are

illustrated in Figure 3-3 and Figure 3-4.

Figure 3-3. Cable grounding concentrated on each end.

Figure 3-4. Cable grounding regularly distributed each 10 km.

Simulation results on both configurations are shown in Figure 3-5, where Immc and Vmmc are plotted. Fault currents

start to differ in steady state, around 8 ms after the fault inception. The difference between current magnitudes

reaches up to a 100A, 20 ms after the fault inception. There is no impact on the voltage value.

Fault current interruption actions taken in CBS and FBS strategies happen during the first 10-15 ms after the fault

inception. In the CBS strategy the DCCB is rated for interrupting fault currents up to 20 kA in less than 10 ms. In

the FBS the current is driven to zero by the FB-MMC. Thus, no significant difference will be observed during the

simulation of the CBS and FBS strategies using either cable models.

Page 35: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

34

Figure 3-5. Offline simulation results for comparison between the two grounding modeling approaches.

This being known, a light cable model consisting on a few cable sections with a screen grounded at its ends has

been chosen. This model is simpler and easier to implement in real-time. The lesser the cable sections required

to model our system; the lower computation means required to simulate it in real-time. Furthermore, if the effect

of the screen can be neglected, it can be completely removed from the cable data input of Table 3-5, reducing

the number of conductors from 4 to 2 and simplifying the wideband cable model.

3.3 Converter and line breaking modules

CBM and LBM present in the CBS strategy are DCCB breakers of the active resonant type. The model has been

previously studied and presented in WP6 [10]. The principle of operation of this type of breaker is to create a zero-

crossing point through the main breaker contacts (SW1 in Figure 3-6) by opposing a current generated in an

auxiliary branch in parallel. The auxiliary branch uses a pre-charged capacitor with a series inductor ready to

create current oscillations when the discharge switch SW3a is closed. These elements are sized to follow given

specifications (see Table 3-7). SW2 is required when disconnection is required beyond the interruption (usually

the case in faults due to cable short-circuit). A closing procedure is aided by means of PIR (pre-insertion

resistances) that limits the overcurrent when the closing is done between zones with large voltage difference.

SW3b is used in case of second consecutive opening is required, but this is not a scenario included in WP9 tests.

The surge arrester (SA) role is to limit the overvoltage at the ends of the mechanical breaker.

Page 36: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

35

Figure 3-6. Schematic of DC breaking modules models used in WP4.

Table 3-7. Electrical specifications of CBM and LBM models.

Table 3-8. Additional specifications on the DC breaking module.

Parameter Value Unit

Rated voltage 320 kV

Rated current 2 kA

Breaking capability 20 kA

C 3 µF

Vprech >320 kV

L 1100 µH

SA 1.6 pu

Opening mechanical delay

(SW1)

8 ms

Interruption time 20 ms

Closing time

(SW1)

10 ms

Open-close operation O – 50 ms – CO

Parameter Value Unit

RCB-O mechanical delay (SW2) 5 ms

RCB-C mechanical delay (SW2) 5 ms

PIR-O delay 5 ms

PIR-C delay

SwPIR1 ,SwPIR2 ,SwPIR3

10, 15, 20 ms

R1, R2, R3 700, 50, 50 Ω

Page 37: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

36

The model was validated in real time according to the EMT M-DCCB used in SuperGrid Institute for WP4

(“Offline” Curves). The breaker was validated in EMTP® through a simplified circuit (see Figure 3-7) as well as in

HYPERSIM® for cross-validation. Even though the test circuit is not representative of the HVDC system, this

model has been tested already in offline tests in WP4 [1] and WP6 [10]. The aim was to reproduce the offline

model in the RTS environment; thus, a simplified test circuit well suits this need. A fault-to-ground triggers at 0.5

seconds. Short circuit ratio and load has been tuned to obtain the same maximum fault current that in EMTP®

Validation. Current during opening and reclosing procedures well match between offline and RTS models as

observed in Figure 3-8.

Figure 3-7. DC Breaker module test circuit for cross-validation between offline (EMTP®) and real-time (HYPERSIM®) models.

Figure 3-8. Breaker current; upper side: current during opening; lower side: current during closing.

Page 38: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

37

The FBS protection strategy doesn’t require DC protection devices as breakers. Indeed, the FB-MMC can

suppress DC Current. The line isolation is ensured by the operation of a high-speed switch (HSS in Figure 3-9).

The residual current breaker (RCB, which technology is discussed in [11]) function is to break at a minimal current

once the FB-MMC has manage to reduce the fault current to zero. It is assumed in [11] that the RCB has a low

voltage withstand, so an ultra-fast disconnector (UFD) is needed to effectively isolate the faulted zone. A detailed

modelling of such devices is not needed for system studies such as those carried out in WP9. The system

response will behave as expected using ideal switches respecting timings, breaking capabilities and voltage

withstand provided in specification sheets for UFC and RCB.

Figure 3-9. Topology of a HSS located at line ends in FBS, taken from [1].

Table 3-9. Electrical specifications of UFD model.

Table 3-10. Electrical specifications of RCB model.

* No reclosing considered in FBS scenarios studied † Considering solid-state technology [1]

Parameter Value Unit

Rated voltage 320 kV

Rated current 2 kA

Breaking capability 5 A

Opening time 2 ms

Voltage withstand 320 kV

Closing time N/A* /

Open-close operation N/A* /

Parameter Value Unit

Rated voltage 320 kV

Rated current 2 kA

Breaking capability 100 A

Opening time 1 ms

Voltage withstand 15† kV

Closing time N/A* /

Open-close operation N/A* /

Page 39: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

38

3.4 Ac network representation

The AC network is represented by an equivalent AC generator in which R and L parameters are defined

according to a SCR. THE SCR is important because it defines the “strength” of the AC network. For instance,

offshore windfarms will have a low SCR whereas a continental network will have a high one. The AC voltage is

reduced to the converter nominal voltage (160 kV) by wye/delta transformers.

3.5 HB-MMC converter implementation

3.5.1 Introduction to HB-MMC converters

The topology of a typical three-phase half bridge MMC is shown in Figure 3-10 (a). Each converter leg is

composed by two arms, with N identical sub-modules (SMs) connected in series. Each SM has two power

switches (two IGBTs with anti-parallel diodes) and one capacitor connected as shown in Figure 3-10 (b). The SM

can provide two different voltage levels, when S1 is ON and S2 is OFF. The SM provides a voltage Vc when the

capacitor can be charged or discharged depending on the current direction. When S2 is ON and S1 is OFF, the

capacitor is bypassed by S2 and the SM has zero output voltage. In blocked state: S1 and S2 are off, the capacitor

may charge through the antiparallel diode of S1 but cannot discharge.

Figure 3-10. (a) Three-phase half-bridge. (b) Half-bridge sub-module.

Page 40: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

39

3.5.2 Modelling

Different approaches for HB-MMC modelling have been studied in SuperGrid Institute and are resumed in [12].

The semi-analytical average model shown in Figure 3-11 is the one implemented in HYPERSIM®. This model

can be used for protection system studies since the focus is rather on the interaction between the MMC and the

transmission network rather that the internal behavior of the SM. In addition, the average model can be simulated

in real-time using low resources. Not to be confused with AVM models (type 5) from [13], were average models

were not able to represent the MMC blocked state.

Figure 3-11. Semi-analytical model, illustration taken from [14].

The HB-MMC submodules electrical model are based of the HYPERSIM® library element described hereunder.

It is based of ideal voltage sources, so the physical switching devices are not represented.

Figure 3-12. Sub-module model for HB-MMC in HYPERSIM®.

Page 41: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

40

This model has various tunable parameters as the cell capacitance, arm inductance and resistance and the

number of submodules in an arm.

Table 3-11. HB-MMC sub-module parameters.

Item All MMC

Arm inductance 10% (20mH)

Number of cells per arm (N) 16

Cell capacitance 1.32mF

Average arm capacitance 82.29𝜇F

The input of the modules are the modulation index and the trigger of the submodule blocking. Both are given by

the MMC control.

3.5.3 HB-MMC control

The control was implemented in Simulink following the work in [14]. The controller receives orders and set points

from the station supervisor as well as some system measurements. From them, it manages the modulation index

and the blocking/unblocking of the submodules.

The MMC blocks itself if:

- An overcurrent is detected in the lines or in the sub-modules.

- The control is disabled.

Activate the control will unblock the MMC and reset all the overcurrent protections.

Figure 3-13. Inputs/outputs interfaces of the MMC control module.

This control is and imported into an UCM thanks to Hyperlink, a tiers-software which enable to transform a

scheme from Simulink to a code C importable in an UCM for HYPERSIM®.

Page 42: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

41

The parameters in the control mask are equations-based, which are therefore automatically tuned according to

loop time constants and physical parameters. We can also manually implement values in this controller.

Table 3-12. Tunable parameters of MMC control module.

Parameters Description

Num_Station Number of stations in the MTDC grid

Num_SM_losses Losses in the Submodules

Num_Arm Number of arms

Tr_ig Global current loop time constant

Tr_idiff Differential current loop time constant

Tr_Wg Global energy loop time constant

Tr_Wph Energy/phase loop time constant

Tr_Wdiff Differential energy loop time constant

Tr_Vdc Voltage loop time constant

Note: The damping coefficients for these loops are also tunable. But a value of 0.7 (for all loops) is considered

the best to have the faster response while avoiding overshoots.

3.6 FB-MMC converter implementation

3.6.1 Introduction to FB-MMC converters

The topology of the FB-MMC and the HB-MMC are alike, the main difference relies on the SM configuration. As

observed in Figure 3-14, two additional IGBT devices are present in the SM, increasing the number of SM states,

with the possibility to insert a voltage with negative polarity.

Figure 3-14. Full-bridge MMC topology [15].

Page 43: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

42

This feature is useful to control DC fault currents, since the DC voltage can be varied over the full range (from

rated -Vdc to +Vdc), which is the principle of operation used in the FBS strategy.

3.6.2 Modelling

The FB submodules are also represented by a reduced order semi-analytical average model. A manual

implementation in HYPERSIM® was required due to unavailability of the model in its library. The capacitor

voltages of all N submodules within an arm are always assumed to be equal. The model is represented by the

following scheme:

Figure 3-15. Semi-analytical model scheme taken from [14].

For the electrical representation of two controlled voltage sources and two ideal, antiparallel diodes, two reference

voltages are calculated, and the currents of each branch are measured. The average capacitor voltage Vc is

directly transferred to the control of the MMC. Although also calculated within the submodule representation, the

arm voltage transferred to the control is the measured value. As for the HB-MMC, the pulses and

blocking/unblocking of the SM is given by the controller.

Here are the parameters used for this model:

Table 3-13. FB-MMC sub-module parameters.

Item All MMC

Arm inductance 16%

Number of cells per arm (N) 350

Cell capacitance 8.8mF

Average cell capacitance 25.14𝜇F

Page 44: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

43

Figure 3-16. Overview of the FB-MMC sub-module block in HYPERSIM®.

3.6.3 FB-MMC control

The delivered HYPERSIM® model uses the non-selective fault clearing strategy based on fault blocking

converters (in this case full bridge MMCs) presented in [1] and [8]. For detailed information, please refer to chapter

5 of deliverable [8]. Figure 3-17 gives a short overview of the control block. The FB-MMC grid controller was

implemented in Simulink and imported into an UCM.

Figure 3-17. FB-MMC control block in HYPERSIM®.

Page 45: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

44

The control contains the following:

• Startup Sequence (via state chart in Simulink)

• Steady state MMC control (“standard MMC Control” comparable to D2.1)

• Modulation (NLM) and third harmonic injection which can be disabled

• Internal protection

• FB-MMC DC line fault control + fast fault detection (dV/dt)

• Restart & recovery logic/sequences including grid discharge detection

3.7 Functional tests

Following the methodology already introduced in section 1.6 and presented again in Figure 3-18, the four-terminal

HVDC meshed system (plant in HIL terminology) requires validation. The validation is based on knowledge about

the behavior expected of the plant during different operating modes such as: start-up, fault inception, fault

clearance and recovery. These are the operating modes that will appear during HIL tests.

Figure 3-18. Workflow to implement a test plant for HIL tests.

However, DUT nor the interfaces have been configured since those systems behavior can only be tested

alongside the plant, at least during WP9 studies. Indeed, the DUT (protection and supervision IEDs) is a prototype

not an industrial device with known testing protocols and compatible with testing hardware. To overcome this, IED

functionalities, which are priorly known, are tested in simulation. For this purpose, simulated IEDs are required.

When no IED simulated models are available for testing. Another approach is to perform open-loop simulations,

in which the different components of the system can only follow a pre-defined sequence. This sequence is

programmed by the user in order to force the system to reach the desired states (start up, fault inception, fault

clearance…). This workflow is better understood from the following scheme:

Develop models

•Choose the level of model refinement.

•Provide correct interfaces: I/O pins and tunable parameters.

Test models

•Provide a simplified test environment.

•Run off-line tests to compare with other models.

•Run real-time tests to check computation time.

Build system

•Build the HVDC network interconnecting models.

•Anticipate tests with a neat arrangement of the system and providing a clear system description.

Test system

•Off-line: verify the system behavior under same operating conditions expected for tests.

•Real-time: check stability of real-time simulation.

Page 46: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

45

Figure 3-19. Plant testing workflow, communication interface is the same for both prototypes (IEC61850).

3.7.1 Benchmark network model 1

Due to the availability of IED prototype already for HIL tests, and the unavailability of Supervisor IED, functional

tests of the four-terminal HVDC meshed network are done here in open-loop (according to Figure 3-19). Operating

sequences that will be tested in the station supervisor must communicate set points and control order to the MMC

but also tripping orders to the different breakers of the terminal. A rough view of the “sequencing blocks” that

replace the role of supervisor in open-loop tests is shown in Figure 3-20.

Page 47: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

46

Figure 3-20. Sequenced supervisory system for the HB-MMC startup and test fault scenario.

The process of start-up is defined by the following sequence diagram:

Figure 3-21. Start-up sequence of a four-terminal base in HB-MMC converters.

Page 48: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

47

A successful start-up of the 4T network was obtained in Figure 3-22. We can see that the voltage is regulated to

its nominal values and the power controlled MMC can regulate their current in order to reach the given power.

3.7.1.1 Start-up

Figure 3-22. EMT waveforms for the benchmark network 1 simulation during start-up.

3.7.1.2 Pole-to-ground fault

The table below describes the 4 MMC state during a fault sequence, as defined in [1].

Table 3-14. MMC states and parameters during a test sequence.

This sequence has been run in offline mode. A ramp of 1 p.u/s is applied for the power restoration. The fault is on

the line 1-3 near the converter 1. As the station 3 is the radial section, we clear the fault before reclosing the

breakers.

Stage MMC1 MMC2 MMC3 MMC4

Pre-fault Vdc (1pu), Droop control

300MW, -250MVAR

Vdc (1pu), Droop control

150MW, 0MVAR

P control

-150MW

P control

-300MW

Blocked MMC Blocked Blocked Blocked Blocked

STATCOM Mode

(CBM opens)

Vdc (1pu), Q control

-250MVAR

Vdc (1pu), Q control

-250MVAR

Blocked Blocked

Voltage restoration

(CBM closes, PIR)

Vdc (1pu), Q control

-250MVAR

Vdc (1pu), Q control

0MVAR

P control

0MW

P, control

0MW

Power restoration

(ramp-up)

Vdc (1pu), Q control

0->300MW, -250MVAR

Vdc (1pu), Q control

0->150MW, 0MVAR

P control

0 -> -150MW

P, control

0 -> -300MW

Post-fault Vdc (1pu), Droop control

300MW, -100MVAR

Vdc (1pu), Droop control

150MW, 0MVAR

P, Q control

-150MW

P, control

-300MW

Page 49: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

48

Figure 3-23. Voltages, active and reactive power during a CBS fault sequence for the benchmark network 1.

The 4 MMC succeed to change state according to the phase in the fault sequence. For instance, the station 2

successfully enters in STATCOM mode as we can see on the reactive power measurements. A delay appears in

the opening-reclosing time of the CB because we open the RCB in addition to the main breaker, which is not

mandatory for the converter breaker because they are not meant to be open for a long time. This will be considered

in the future.

3.7.2 Benchmark network model 2

Benchmark network model 2 was able to be tested in SIL (second step according to Figure 3-19) due to availability

of simulation models for supervision and protection IEDs. Two types of supervision are possible:

• Decentralized: the restart is decentral; it could be considered open loop. In this demo mode, the only

communication outside HYPERSIM® would be:

o IED to HSS (localization)

o IED to/from MMC (optional)

• Centralized: with communication to a supervisor, the restart can be centrally controlled and tested in the

loop with a real device (SiL and then HiL).

As for the HB-MMC system, the station supervisor manages the controller and the tripping of the breakers. Beware

that for now, the following simulations are not real time ones.

Page 50: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

49

3.7.2.1 Start-up

Voltage is regulated to its nominal values and the power controlled MMC can regulate their current in order to

reach the given power.

Figure 3-24. EMT waveforms for the benchmark network 1 simulation during start-up (PtoG).

3.7.2.2 Pole-to-pole fault

The model can run a fault sequence (recovery included) for a pole-to-pole fault.

Page 51: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

50

Figure 3-25. Voltages, currents, active and reactive power during a FBS fault sequence for the benchmark network 1 (PtoP).

3.7.2.3 Pole-to-ground fault

The model can run a fault sequence (recovery included) for a pole-to ground fault.

Page 52: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

51

Figure 3-26. Voltages, currents, active and reactive power during a FBS fault sequence for the benchmark network 1 (PtoG).

Page 53: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

52

4 PROTECTION SEQUENCES FOR NON-SELECTIVE STRATEGIES

4.1 Protection sequences for converter breaker strategy

This non-selective fault clearing strategy uses converter breaking modules (CBM) at each converter output and

line breaking modules (LBM) at each line end. Every CBM and LBM is equipped with a mechanical DC circuit

breaker and a residual current breaker (RCB). In addition, each CBM contains a pre-inserted resistance (PIR)

that assures a smooth voltage restoration after reclosing. Besides the PIRs, no current limiting devices are

needed. For the station connected to the antenna, no line breaker is needed since only one line is connected to

the station. The protection algorithm for the IED located at the antenna is adapted in the way that the CBM3 can

perform as both a converter breaker and a line breaker. The following figure illustrates the location of the described

components.

Figure 4-1. Switchgear location for CBS in a small-impact HVDC meshed network from [8].

Page 54: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

53

4.1.1 Primary sequence

Figure 4-2. Converter breaker fault clearing strategy (CBS). Primary, converter breaker and line breaker failure sequences.

As shown in Figure 4-2, when a fault is detected, the fault current is suppressed by the converter MDCCBs. The

use of MDCCBs allows the quick suppression of the AC contribution to the fault current. Right after a converter is

disconnected and before the faulty line isolation occurs, the converters can be controlled to provide reactive power

if the AC network requires it.

On the line side, the faulty line isolation starts after the execution of the fault identification algorithm; the MDCCBs

are tripped as well to suppress the fault current. Only after the fault current suppression, the line RCBs are opened

to isolate the faulty line.

If everything goes well and the stations are isolated, the converters are reconnected to the grid through the PIRs

once the reclosing counter has elapsed. The reclosing delay needs to be long enough to ensure that the faulty

line isolation has already been performed. The use of PIRs ensures that the converter will not block again due to

Page 55: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

54

in-rush currents. After voltage restoration, the power flow is re-established by the MMC controllers. The sequence

is also described by the following timeline:

Figure 4-3. Timeline describing the converter breaker fault clearing strategy (CBS).

Interval Duration

tf → tf,1 µs to ms

tf,1 → td µs to ms

t

d → t

br,o 10-20 ms

Fault propagation tlbr,t

→ tlbr

20-40 ms

Fault detection t

d → t

dly 50-70 ms

Fault discrimination

tdly

→ trec

20-30 ms

Current checking tf → trec 70-100 ms

Converter breakers opening

Fault current interruption

Line Breakers and line RCB opening

Delay before converter MDCCB reclosing

Converter breaker reclosing

Power flow recovery

4.1.2 Converter breaker failure backup

There is the possibility that a MDCCB of a converter fails to open resulting in a partial fault current suppression.

In case of non-opening of one converter MDCCB (partial fault current suppression), the fault current suppression

is still performed by the line MDCCBs (the failure of two MDCCBs is not under the scope of this study). The

converter RCB is then opened to isolate this converter and it remains at this state until the end of the sequence

(assuming the MDCCB is faulty and requires maintenance). The failure sequence is shown in Figure 4-2 as

converter breaker failure backup. As shown in Figure 4-4, having MDCCBs with fault current suppression

capability online and converter sides is a redundancy that ensure equal duration of both primary and converter

MDCCB failure backup sequences.

tf

tf,1

td=t

br,t tbr,o

tlbr,t

tlbr,o

tdly

trec

tr

Page 56: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

55

Figure 4-4. Converter breaker failure sequence.

Interval Duration

tf → tf,1 µs to ms

tf,1 → td µs to ms

td → t

br,o 10-20 ms

Fault propagation tbr,o

→ tb,d 1-2 ms Fault detection

tlbr,t

→ tlbr

15-25 ms Fault discrimination

tdly

→ trec

20-30 ms Current checking t

d → t

dly 50-70 ms

Converter breakers opening tf → trec 70-100 ms Fault current interruption attempt (faulty station) Line Breakers and RCB opening

Converter RCB opening (faulty station)

Delay before converter DCCB reclosing (healthy stations)

Converter breaker reclosing (healthy stations) Reduced power flow recovery (-1 converter)

4.1.3 Line breaker failure backup sequence

In case of line MDCCB failure the sequence is the same as for the primary sequence (Figure 4-3). Indeed, even

if a line breaker fails to open, the fault current is still cleared by the converter breaker. The RCB associated to the

failed line breaker will open when the RCB opening conditions are ensured and it will isolate the faulty line. As

already mentioned, the reclosing time of the converter breaker delay needs to be long enough to ensure the

operation of the line RCB in case of a line breaker failure. This sequence appears in Figure 4-2 as line breaker

failure backup.

4.1.4 Protection algorithms

This protection strategy uses two criteria for the converter side fault detection:

- Bus voltage / Line end voltage

- Converter output current / Line current

The mode of operation of the fault detection algorithm is shown in Figure 4-5. The measured values of iBM, vBM

are stored in a vector for a number of Nverif = 3 time steps. For a fault detection, all samples of the vector need to

overshoot the threshold. Nothing but one threshold overshoot is enough to detect the fault.

tf

tf,1

td=t

br,t tbr,o

tlbr,t

tlbr

tdly

trec

tr

Page 57: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

56

Figure 4-5. Fault detection algorithm.

The fault identification algorithm is only actively used for the line breaking modules. The line breaker relay

continuously verifies the direction of the current in order to discriminate whether the line is faulty. The principle is

based on the current direction comparison between both line ends using a remote communication link. The

robustness of the current direction identification needs to be high because a spurious tripping or a line

identification failure have important consequences for the DC grid. Therefore, a floating vector is stored for a

verification period of Tverif = 8ms. The mean value of the current vector is continuously compared to zero. If the

value is greater than zero, the current flows into the line. The signal is then compared to the signal of the opposite

line end. Only if the mean value of both line ends is greater than zero, the line is identified to be faulty. Figure 4-6

describes the faulty line identification algorithm.

Figure 4-6. Faulty line identification algorithm.

Table 4-1: Parameters of protection algorithms.

Fault Detection

Overcurrent vth = 2 irated

Undervoltage vth = 0.8 vrated

Fault Discrimination

Directional Current iavg (8 ms) > 0 on both line ends

Page 58: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

57

4.2 Protection sequences for FB-MMC based fault clearing strategy

This fault clearing strategy takes advantage of the possibility to control the full range of the DC voltage

from -Vdc to +Vdc using MMCs equipped with full-bridge submodules. Due to the fault blocking and fault current

controllability of these converters, DC grid protection systems based on FBCs can use DC circuit breakers with

significantly reduced requirements and footprints [16] or DC high-speed switches (HSS) as fault separation

devices [17]. The location of the HSS are illustrated in Figure 4-7.

Figure 4-7. Switchgear location for FBS in a small-impact HVDC meshed network from [8].

4.2.1 Primary sequence

The fault clearing strategy is presented in detail in [11]. The sequence steps are described by the corresponding

flowchart (see Figure 4-8) and timeline (Figure 4-9). In case of a fault, the fault current reduction process of the

converter is triggered. All converters stop their fault current contribution from the AC to the DC grid by actively

controlling their DC current to zero. Thereby the HVDC network quickly de-energizes, the fault currents decay to

values very close to zero and the faulted line (or zone) can be isolated under low voltage and current conditions.

Consequently, the fault separation can be realized by high-speed switches (HSS), which can quickly isolate the

faulted line and interrupt a residual current. The requirements on the residual (DC) current interruption capability

determine which HSS technology needs to be used.

A fault localization process performed at the line IED localizes the faulty line and opens the HSS as soon as its

opening condition is fulfilled. A possible opening condition is the decay of the current flowing through a selected

HSS to below a pre-set interruption current ion and/or decay of the DC grid voltage below a pre-set interruption

voltage vInt.

Page 59: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

58

Figure 4-8. FB-MMC based fault clearing strategy (FBS). Primary failure sequence.

As it can be seen from the timeline in Figure 4-9, this is an exemplary sequence (since the output voltage of an

FB-MMC can be adjusted in many ways). Combinations of the options (b) to (f) in Figure 4-9 can be applied, as

depicted here for combining TZC and LCZ upon localization. It could be highlighted that for the “Line Current

Control”, the MMC also needs communication from the Switchyard/IED to the converter, whereas the MMC

terminal currents/voltages (TCZ or TVZ) are measured directly at the converter for control purposes. The

sequence also works with TCZ only, but LCZ might improve the KPIs (see [11] [15]). It’s important to remind that:

• activation of LCZ needs communication from switchyard to IED (line current and fault localization),

• the information about the HSS state needs to be communicated (or slow backup via deadtime)

Page 60: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

59

Figure 4-9. Timeline describing the FB-MMC based fault clearing strategy (FBS). Possible control loops of the FB-MMC that can be enabled through a fault.

After fault separation the converters restore the DC voltage and subsequently the power flow. The converter

launches the grid recovery process after a predefined automatic restart time, in which fault clearing processes

should be finished. If no fault is localized on a line connected to the converter’s busbar the converter remains in

the fault limitation mode until the fault is cleared by the related HSS. A major advantage of controlling the fault

currents instead of converter blocking is the uninterrupted reactive power control of the converters.

4.2.2 HSS failure backup sequence

An HSS failure can cause a permanent outage of the entire DC network. Consequently, a backup sequence for

the failure mode is required. Depending on the requirements on robustness redundant HSSs can be placed in

series with the primary HSSs or adjusted HSS can be opened. The HSS failure operation should be coordinated

with the time of the automatic start-up.

4.2.3 Protection algorithms

Since all converters of the affected protection are involved in the fault clearing process, the fault discrimination

can be split into two main parts – fault detection and fault localization – without affecting the security of the

components.

To ensure fast and robust detection of DC line faults, the usage of a fault detection based on single-ended

methods, which do not require communication, is proposed. The detection algorithm applied in the following

studies comprises a combination of an undervoltage, a voltage and a current derivative protection. This algorithm

is part of the FB-MMC internal control and protection and drives each MMC to the “fault clearing mode” upon

detection – decentral and fast, no communication needed.

Since the security of the HVDC grid components does not depend on fault separation and hence on the fault

discrimination, double-ended methods can be applied without a compromise in safety. In contrast to detection,

localization is done by the IEDs – can be slow, communication is needed. Within this work, the simple approach

of a longitudinal DC line current differential protection is used for fault discrimination and the selection of the

relevant fault separation devices. A great advantage of this fault discrimination principle is that no fault current

Page 61: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

60

limiting inductors are required at the line ends. The parameters of the protection algorithms are summarized in

Table 4-2.

Table 4-2. Parameters of protection algorithms.

Fault Detection

Undervoltage vth = 0.75 vrated

Voltage derivative dvth/dt = 35 kV/ms

Fault Discrimination

Differential Current idiff = 3 kA

Page 62: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

61

5 FUNCTIONAL SPECIFICATIONS FOR SUPERVISION SYSTEM

5.1 Introduction to supervision system

As presented in section 2.4, the supervision architecture has been defined following a hierarchical and distributed

approach. Two levels of supervision have been defined: the station supervisors and the grid supervisor. Given

that the greatest possible autonomy has been given to the protection devices close to the process lever for faster

reaction time, the coordination of sequences, e.g. start up, shutdown, etc., between all components in each station

is determined to be realized by a station supervisor, which interacts with the devices at the bay level (i.e. IEDs,

MMC controller, MUs).

The grid supervisor, on the other hand, oversees the station’s modes coordination, adapting dynamically the

setpoints and control configurations to be able to keep or bring the system back as soon as possible to normal

operation. This supervisor interacts exclusively with each of the station supervisors, hence the data flows from

the lower to the upper control and protection layers (as shown in section 2.4), in a way that the information is

treated and refined at each level. Thus, the grid supervisor receives less volume of data but richer information, as

opposed to devices close to the process level.

5.2 I/O specifications

Each of the four station supervisors and the grid supervisor are implemented in distinct supervision IEDs, which

include a code layer that formats the I/O signals to the IEC 61850 protocol and communicates them via a single

process bus. No communication delays are considered to occur in the first place. The input signals are then read

by the C functions implementing the supervisor routine and the outputs are modified according to the obtained

control law.

We shall detail in the following the signals exchanged by each one of the prototypes and a description of the

possible values those signals can take. Please note that, because all the station supervisors have the same

functionalities, all the exchanged signals are equivalent and so we only show here the I/O of a standard station

as an example. The only difference between them is that there may be instances of a signal depending on the

number of DC cables connected to the station.

Page 63: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

62

Table 5-1. Station supervisors IED, input signals

INPUT SIGNALS

Pin Name Source Values / Description

1 ACBM_state Relay ACBM 0: ACCB status opened

1: ACCB status closed

2 Conn_order Grid

Supervisor

0: Disconnect station from AC & DC sides order

1: Connect station to DC side order

2: Connect station to AC side order

3 I_state Relay LBM 0: Low or near zero DC current

1: DC current within security limits

2: Overcurrent

4 V_state Relay LBM 0: Low or near zero DC voltage

1: DC voltage within controllability limits, no room for Q

control

2: DC voltage within controllability limits, enough room for Q

control

3: Overvoltage

5 MMC_V_state Relay MMC 0: Low or near zero MMC average arms voltage

1: MMC average arms voltage within controllability limits, no

room for Q control

2: MMC average arms voltage within controllability limits,

enough room for Q control

3: Overvoltage

6 MMC_Ctrl_Mode Grid

Supervisor

0: Not defined

1: Set MMC control mode to AC startup

2: Set MMC control mode to DC startup

3: Set MMC control mode to Droop control and MMC energy

contribution from DC side

4: Set MMC control mode to Droop control and MMC energy

contribution from AC side

5: Set MMC control mode to Voltage control and MMC

energy contribution from DC side

6: Set MMC control mode to Voltage control and MMC

energy contribution from AC side

7: Set MMC control mode to Power control and MMC energy

contribution from DC side

8: Set MMC control mode to Power control and MMC energy

contribution from AC side

Page 64: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

63

7 MMC_state Relay MMC 0: MMC status running

1: MMC status blocked

8 Operating_mode Grid

Supervisor

0: Not defined

1: Grid starting startup operation mode

2: Grid ending startup operation mode

3: Grid starting power ramp mode, all stations connected

4: Grid ending power ramp mode, all stations connected

5: Grid starting power ramp mode, station 2 disconnected

6: Grid starting power ramp mode, station 4 disconnected

7: Grid starting power ramp mode, station 1 disconnected

8: Grid starting power ramp mode, station 3 disconnected

9: Grid starting power ramp mode, station 1 and station 3

disconnected

10: Grid in short-circuit fault protection mode

9 CBM_state Relay CBM 0 : CBM state closed

1 : CBM state opened

2 : CBM state closed not ready to open (RCB closed but

some failure occurred)

3 : CBM state opened not ready to close (RCB opened but

some failure occurred)

4 : DCCB and RCB opened but not PIR

10 CBM_Fault_info Relay CBM 0 : No short-circuit fault detected

1 : Short-circuit fault detected

2 : Short-circuit fault is not isolated after DCCB and RCB

closure

3 : Short-circuit fault is not isolated after CBM closure

4 : Short-circuit fault is isolated after CBM closure

11 LBM_Fault_info Relay LBM 0 : Line not faulty

1 : Line faulty

12 CBM_status Relay CBM 0 : Not defined

1 : The first opening happened after fault

2 : Primary protection sequence is over

3 : Reopening happened

4 : CBM failure occurred

Page 65: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

64

Table 5-2. Station supervisors, output signals.

OUTPUT SIGNALS

Pin Name Destination Values / Description

1 ACBM_order ACBM 0: No tripping order

1: Tripping order

2 AC_Conn_St Grid Supervisor 0: Station disconnected from AC side

1: Station connected to AC side

3 CBM_order CBM 0: No tripping order

1: Tripping order

4 DC_Conn_St Grid Supervisor 0: Station disconnected from DC side

1: Station connected to DC side

5 Station_Ener_St Grid Supervisor 0: MMC and cables deenergized

1: MMC and cables energized, no room for Q control

2: MMC and cables half energized

3: MMC and cables energized to rated values,

enough room for Q control

4: MMC energized to rated value, enough room for Q

control

5: Station energization started

6 Station_Mode Grid Supervisor 0: Not defined

1: Station operating normal

2: Station operating in short-circuit

3: Station recovered operation after fault

4: Station did not recover operation after fault

7 ON_OFF_Ctrl MMC 0: Disable MMC control order

1: Enable MMC control order

8 Wg_AC_or_DC MMC 0: Set MMC energy contribution from AC

1: Set MMC energy contribution from DC

9 Ctrl_V_P MMC 1: Set MMC to Power control

2: Set MMC to Voltage control

10 Master_Droop MMC 1: Set MMC to Master control

2: Set MMC to Droop control

11 Q_Vac_Ctrl MMC 0: Set MMC to Q control

1: Set MMC to Vac control

Page 66: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

65

Table 5-3. Grid supervisor IED, input signals.

INPUT SIGNALS

Pin Name Source Values / Description

1 - 4 AC_Conn_St_i

(i ϵ [1,4])

Station

Supervisor i

0: Station disconnected from AC side

1: Station connected to AC side

5 - 8 DC_Conn_St_ i

(i ϵ [1,4])

Station

Supervisor i

0: Station disconnected from DC side

1: Station connected to DC side

9 - 12 Station_Ener_St_ i

(i ϵ [1,4])

Station

Supervisor i

0: MMC and cables deenergized

1: MMC and cables energized, no room for Q

control

2: MMC and cables half energized

3: MMC and cables energized to rated values,

enough room for Q control

4: MMC energized to rated value, enough room

for Q control

5: Station energization started

13 - 16 Station_Mode_ i

(i ϵ [1,4])

Station

Supervisor i

0: Not defined

1: Station operating normal

2: Station operating in short-circuit

3: Station recovered operation after fault

4: Station did not recover operation after fault

17 - 24 LBM_Fault_info_ij

(i,j ϵ [1,4])

Station

Supervisor i

0: Line not faulty

1: Line faulty

Page 67: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

66

Table 5-4. Grid supervisor IED, output signals.

OUTPUT SIGNALS

Pin Name Destination Values / Description

1 - 4 Conn_order_ i

(i ϵ [1,4])

Station

Supervisor i

0: Disconnect station from AC & DC sides order

1: Connect station to DC side order

2: Connect station to AC side order

5 - 8 MMC_Ctrl_Mode_ i

(i ϵ [1,4])

Station

Supervisor i

0: Not defined

1: Set MMC control mode to AC startup

2: Set MMC control mode to DC startup

3: Set MMC control mode to Droop control and MMC

energy contribution from DC side

4: Set MMC control mode to Droop control and MMC

energy contribution from AC side

5: Set MMC control mode to Voltage control and

MMC energy contribution from DC side

6: Set MMC control mode to Voltage control and

MMC energy contribution from AC side

7: Set MMC control mode to Power control and MMC

energy contribution from DC side

8: Set MMC control mode to Power control and MMC

energy contribution from AC side 0: Not defined

9 Operating_mode Station

Supervisor 1

Station

Supervisor 2

Station

Supervisor 3

Station

Supervisor 4

0: Not defined

1: Grid starting startup operation mode

2: Grid ending startup operation mode

3: Grid starting power ramp mode, all stations

connected

4: Grid ending power ramp mode, all stations

connected

5: Grid starting power ramp mode, station 2

disconnected

6: Grid starting power ramp mode, station 4

disconnected

7: Grid starting power ramp mode, station 1

disconnected

8: Grid starting power ramp mode, station 3

disconnected

9: Grid starting power ramp mode, station 1 and

station 3 disconnected

10: Grid in short-circuit fault protection mode

Page 68: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

67

5.3 Algorithms to be included in the IED

In this section, the methodology followed to obtain the supervisory control functions to be included in the IEDs is

presented. At first, the different development steps of the workflow are detailed, and then the state machine

diagrams of the discrete-event controllers are shown. Finally, it is presented how the controller code that will be

effectively executed during the tests is obtained from the automata models.

5.3.1 Workflow

Figure 5-1 describes the steps of the workflow necessary to obtain the supervisors code functions. At first, the

components (also called plants) of the system, along with the functional requirements imposed by the experts,

are modelled in the form of automata in the Supremica® software [18]. Then, by using formal methods within the

Supervisory Control Theory (SCT) framework [19], the supervisor automata enforcing the specifications on the

system components is synthesized. Once the supervisory control models are obtained, it is possible to export

them as XML files, which contain all the information about the automata: that is, each automaton’s name and type

(i.e. plant, supervisor or specification), the list of events, the list of states and the list of transitions.

At this point, the automata models need to be transformed into an executable code that can be implemented in

the IED prototypes. This is done by means of a code generation tool, developed in Python by SuperGrid Institute.

This software takes as input the XML file generated by Supremica® and outputs in return a source and a header

C code file containing the control law, in the form of Moore machines, to be implemented in the IEDs [20]. The

user intervenes in order to make the link between the I/O signals of the hardware and the corresponding variables

in the C functions, however, the C code is generated by the Python program. This mechanism is called automatic

programming: a code at a lower abstraction level (C) is written by a code at a higher abstraction level (Python).

The obtained C code can then be executed in the IEDs for validation and testing.

Figure 5-1: Supervisory control development workflow.

Page 69: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

68

5.3.2 Supervisor synthesis

In this section, the obtention of the supervisory control automata for the station and grid levels is detailed. In order

to reduce the complexity of the supervisory control design, each operating mode (e.g. start-up, protection…) is

studied separately at first. Hence, at the beginning of the control design, the components in each station of

section 2.4 are modelled as automata. From the supervisory control point of view, the system state is influenced

by the state of the breaking modules (AC and DC sides) and the MMC. Also, the state of the cables (i.e. voltage

and current levels) must be known in order to monitor the system’s state. On the other hand, components such

as the transformer do not have a direct influence in the control sequences and thus are not modelled.

As an example, the CBM and LBM models of each converter station during the non-selective protection strategy

is shown in Figure 5-2. All transitions depicted in red are labelled by events that are uncontrollable, meaning that

they cannot be prevented from happening by the supervisory control. This kind of events are usually related to

measurement, status or alarm signals. The left automaton in Figure 5-2 describes the behavior of the CBM during

a short-circuit fault scenario: once a fault is detected, the breaker will be automatically tripped. Once it is effectively

opened, the S_First_Opening_happened event will occur. If it was not able to open, the S_Failure event would

happen, thus leading to a termination of the CBM operation (ProtectionTerminated state). If not, the CBM will be

reclosed after a certain time delay has passed. As the CBM does not communicate with other devices, it is not

aware if the fault has been correctly isolated or not. It is then necessary to perform an analysis for this purpose

once the CB is closed and will be reopened it if the fault has not been isolated. Given that the pre-insertion

resistors (PIRs) are first inserted during the CBM reclosing, then bypassed, this fault analysis could be launched

in parallel. On the other hand, if the fault has been correctly isolated, the protection sequence will be terminated,

and grid operation can be restored. All the S_Failure events correspond to a scenario where a CBM is not able to

open or close after it has received the corresponding order from the relay, which terminates its action during the

protection sequence.

As it can be observed in Figure 5-2, the CBM model of converter station 3 is similar to the one in the other stations.

However, given its nature of antenna station, it has an additional functionality that corresponds to the LBMs

capability to identify the location of the fault (represented by the Line_faulty event). Therefore, if line L13 is faulty,

CBM3 will not be closed again after its opening; in the case the fault is located in another line, CBM3 will behave

as the rest of the CBM components.

Page 70: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

69

Figure 5-2: CBM models of converter station 1, 2, 4 (left) and converter station 3 (right)

Then, once the different components in a station have been modelled (i.e. the MMC, the CBM, the LBMs, the

ACCB and the cables), it is necessary to model the specifications related to the functional requirements we wish

to impose on the station operation. As an example, we wish to perform AC grid support in each station during the

short-circuit fault in the form of reactive power regulation or AC voltage regulation. Because the MMC will be

automatically blocked once the DC current is higher than the safety threshold of 2 pu, AC grid support will only be

realized once the MMC has been secured from the fault (that is, the CBM has been opened) and the MMC control

loops (MMC energy and DC voltage regulation) have been correctly configured. Similarly, AC grid support can

also be performed if the station is disconnected from the DC grid, either because the CBM endures a failure or

because the fault cannot be isolated. All these functional requirements have been modelled in the automaton of

Figure 5-3. The transitions depicted in green are labelled by controllable events, that is, events that can be

prevented from occurring by the supervisory control.

Figure 5-3: Specification automaton describing the activation of the AC grid support during a short-circuit fault.

Once the all the component behaviors and the functional requirements we wish to impose on a station’s operation

for a given mode (the non-selective protection mode in our example), the different models are composed and the

supervisor of the station for that mode is obtained through synthesis, as described in the SCT [19]. As illustration,

the supervisor for converter stations 2 and 4 is shown in Figure 5-4. The state surrounded by two green circles is

called the marked state and corresponds to the final desired state of the control and protection sequence.

Page 71: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

70

Figure 5-4: Supervisor of stations 2 and 4 for the non-selective protection mode.

Page 72: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

71

In order to obtain the grid supervisor, we follow the same approach that the one needed to obtain the station

supervisor: this time, we should compose the station supervisors’ models along with the specification automata

at the grid level. However, as it can be observed, the resulting station supervisor (29 states, 23 transitions) has a

size that will make the automaton resulting from the composition of the four station supervisors difficult to

understand. For this reason, the station supervisor models are simplified and all those events that are not crucial

for grid-level coordination removed from the automata.

Figure 5-5: Simplified station supervisor automaton

The size of the automaton is then drastically reduced, as it can be observed in Figure 5-5. Indeed, given that the

grid supervisor needs to know only the configuration of the grid after the fault, the sole events that need to be

communicated are those indicating if a station is connected to a faulty line or not (and which one), and if the

station can still be used for power transfer or not (e.g. if the CBM is not able to reclose, the station will be

permanently disconnected from the DC grid).

Then, from the simplified model of the station supervisors, the grid supervisor is synthesized for the given

operating mode, as shown in Figure 5-6. The resulting automaton has a size of 127 states and 257 transitions.

Figure 5-6: Grid supervisor for the non-selective protection mode. Only to show the complexity of the supervisor for a network of four-terminals.

Finally, because the station and grid supervisors have been obtained separately for each operating mode, the

automata of each operating mode need to be merged in a single model that follows the considered sequence of

operation. In our case study, the sequence of operation is defined by the model given in Figure 5-7. At first, the

DC grid is discharged, and all stations disconnected; then, when the start-up mode is activated, all the converters

and cables are charged to their rated voltage and all circuit breakers are closed. At this moment, it is possible to

begin the power transfer mode. Once the currents have reached their nominal value, the supervisory control

reaches the desired nominal operation mode. If a short-circuit fault occurs, the supervisory control enters the

protection mode until the fault has been isolated. Then, depending on the post-fault configuration of the grid, the

!Lin

e_fau

lty3[2

]

!Lin

e_fau

lty3[1

]

!Lin

e_fau

lty3[3

]

!Lin

e_fau

lty4

!Lin

e_fau

lty1[2

]

!Lin

e_fau

lty1[1

]

!Lin

e_fau

lty2[1

]

!Lin

e_fau

lty2[2

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_lo

st[4]

!STA

TIO

N_ok[1

]

!STA

TIO

N_lo

st[1]

!STA

TIO

N_lo

st[2]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_lo

st[3]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_lo

st[3]

!STA

TIO

N_lo

st[4]

!STA

TIO

N_lo

st[2]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_lo

st[1]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_lo

st[3]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_lo

st[4]

!Lin

e_fau

lty2[1

]

!Lin

e_fau

lty4

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!Lin

e_fau

lty1[1

]

!STA

TIO

N_lo

st[3]

!STA

TIO

N_lo

st[4]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_lo

st[4]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_lo

st[3]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!Lin

e_fau

lty3[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]!S

TA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!Lin

e_fau

lty2[2

]

!Lin

e_fau

lty3[3

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_lo

st[1]

!STA

TIO

N_lo

st[2]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_lo

st[3]

!STA

TIO

N_lo

st[4]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_lo

st[4]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_lo

st[3]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_lo

st[3]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!Lin

e_fau

lty3[2

]

!Lin

e_fau

lty1[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_lo

st[4]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[1

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[3

]

!STA

TIO

N_ok[2

]

!STA

TIO

N_ok[4

]

!STA

TIO

N_ok[2

]

Page 73: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

72

power is restored with the appropriate set of references. For the sake of understanding, the following acronyms

are detailed: SAO (Stations All Ok), S1L (Station 1 Lost), S2L (Station 2 Lost), S3L (Station 3 Lost), S4L (Station

1 Lost), S34L (Station 3 & 4 Lost).

Once each station and grid supervisor has been placed in the corresponding mode, as presented in Figure 5-7,

the supervisory control synthesis is concluded and we can proceed to the generation of the executable code to

be implemented in the IEDs.

Figure 5-7: Modes automaton.

5.3.3 Code implementation

As mentioned in Section Workflow5.3.1, each of the obtained supervisor models can be exported from

Supremica® as XML files. At this point, the automata models need to be transformed into an executable code

that can be implemented in the IED prototypes. This is done by means of a code generation tool, developed in

Python by SuperGrid Institute. This software takes as input the XML file generated by Supremica® and outputs

in return a source and a header C code file containing the control law to be implemented in the IEDs [20].

For this, the user who synthesized the supervisor models has to make the link between a set of inputs and the

corresponding event in the models. In the same way, the user has to make the link between an event in the

automata and the corresponding set of outputs. In order to do this, two YAML configuration files are generated by

the Python program and the user is invited to complete them. The YAML files list all the events of the models and

ask the user to complete the conditions on the system inputs that trigger the related uncontrollable event, this

relation should also be indicated by the user. Similarly, the user should identify in the second YAML file the link

Page 74: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

73

between the IED outputs and the model events, so that whenever the associated controllable event occurs, the

corresponding IED outputs are modified.

Once the two files are completed, the Python program can process the user inputs using a third YAML file:

dll_pins.yml. In this configuration file, the user lists all the inputs and outputs of the IED at the exact order they

have been configured in the hardware. Indeed, the order of the pins is very important because the C code

generation tool uses it to link the correct I/O signal to the correct C code variable by translating the human-

generated comprehensible names into list indexes.

Finally, the user needs to fill a fourth configuration file in order to choose the sequence of actions to be performed

by the controller whenever two or more are possible. For the moment, the program considers only decisions

before the execution, meaning that if several sequences of events are possible from a given state, the user has

to choose only one among them, before the C code generation. Then, the other sequences are deleted. Thus,

the Python program creates a YAML file choice_needed.yml listing all the situations where a choice is necessary.

The user can fill this file with the chosen event for every conflicting situation. Then, the code generation tool

removes the unselected transitions.

The workflow necessary to generate and complete the four configuration files is illustrated in Figure 5-8.

Figure 5-8: Workflow to generate the four configuration YAML files

At this point of the program, everything is ready and the two C code files (the source and header files) are

generated by the Python program for each of the four station supervisors and the grid supervisor. The source

code contains a “main” function which is called from the IED at each cycle and in turn executes the following C

code functions in the given order:

Uncontrollable events generation: given a set of inputs, all possible uncontrollable events are generated when the

associated conditions are respected.

Controllable events generation: given a state in the supervisor, all authorized controllable events are generated if

no uncontrollable event has been generated yet.

Supervisor authorizations: the authorizations for the allowed controllable events are generated.

Page 75: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

74

Update of the automaton’s state given the chosen controllable event, the corresponding transition is realized

within the automaton.

Outputs generation: given the chosen controllable event, the corresponding outputs are generated.

Page 76: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

75

6 DC GRID PROTECTION TESTING PROCEDURES

The second objective of WP9 is to propose test procedures for protection system testing. The objective of these

HIL tests is to generate the necessary amount of results that will be analyzed to evaluate the performance of the

protection strategy. In order to evaluate protection strategies performance some metrics must be defined as well.

These metrics are referred as the Key Performance Indicators (KPI) and can be used both to establish thresholds

of minimum performance and to compare different protection strategies. Based on the work proposed in WP4,

two kinds of KPIs have been identified: protection strategy efficiency indicators and IED performance indicators.

Figure 6-1. KPI categories in WP9.

KPIs for protection strategies have been a matter of discussion in [1] and [21]. In this section, some concepts and

calculation methods for these KPIs are summarized. Finally, test procedures for WP9 are synthetized.

6.1 Efficiency indicators

Figure 6-2 Efficiency KPIs for fault clearing strategies.

Key performance indicators

Efficiency indicators

IED performance

Protection strategy

efficiency

Active power restoration time

DC voltage restoration time

Fault interruption time

Reactive power restoration time

Transient energy imbalance

Page 77: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

76

Efficiency indicators are the KPIs related to how the protection strategy manages the fault clearing process and

the grid restoration. The main goal of the efficiency indicators can be understood as to express the impacts that

the protection sequence performed can cause to the system. These indicators are useful to assess the stress of

HVDC grid components during the fault. They can also, if needed, be used to estimate how much the AC grid is

disturbed during the DC fault clearing and restoring process. It is proposed to calculate five efficiency indicators

as shown previously in Figure 6-2.

6.1.1 Active power restoration time

The power restoration is the process of returning to an acceptable range of power exchange after a disturbance.

In AC systems, the power restoration performance is a fundamental process once it is related to the frequency

deviation during and after the disturbance [22]. According to [23] the fast post fault active power recovery also

ensures voltage stability and mitigate overvoltage problems after the faults.

The KPI active power restoration time is defined as the time span from the fault occurrence until the power flow

of all concerned converters is restored and remains within a range of +-10% of its post-fault value. The concerned

converters are those that remain connected to the grid after the fault clearing. Despite the lack of grid code

specifying the band for considering the power as restored, similarly to the last KPI, the value of 10% is considered

as a plausible value once it is already adopted in AC systems [23]. By post-fault value, it must be understood the

power the converter exchanges when in steady state after the fault (power re-dispatching is not considered).

Figure 6-3 illustrates the active power restoration time for a case in which the pre- and post- fault power exchanged

are the same.

Figure 6-3. Illustration of the active power restoration time for an AC zone (AC1).

The power exchanged by the converter used as reference for this KPI is the power measured at the converter

stations AC side. Due to the energy storage capability of MMC capacitors the power measured at the DC side

has not the same shape as at the AC side during fault conditions. Due to its insensitivity to AC system parameters

and its direct link with relevant issues for the AC grid, it is considered that for the purpose of performance

evaluation, the power measured at the AC side of the converter is more pertinent.

The definition for active power restoration time uses the time when the power is restored on all converters in the

DC grid. However, the information about the power restoration of only part of converters can also be pertinent.

Page 78: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

77

Using the topology in Figure 6-4 to illustrate, when there are two or more AC zones (AC zone A and B in Figure

6-4), it can be of interest to assess the power restoration for the zones separately, thus the power restoration is

calculated for each zone. In Figure 6-5 an illustrative case for the active power restoration is presented. Instead

of using all converters in the grid (all zones without distinction), each active power restoration time would use only

the power exchanged by converters connected to the respective assessed AC zone.

Figure 6-4: HVDC grid connecting two different AC zones.

Figure 6-5: Active power restoration time for different zones.

Figure 6-5 shows an example of how to find the KPI Active power restoration time for the two different zones on

Figure 6-4. The plots in Figure 6-5 represent the power measured at the AC side of the converters on Figure 6-4.

In the example, after a fault occurrence in the HVDC, a protection strategy is performed, such strategy performed

the fault suppression and the power restoration. It is important to point out that the time until complete power

restoration does not depend only on the protection. When the power exchanged by converters starts to ramp-up,

the rising and setting time for the post-fault power depend also on the tuning of converter's control. Some aspects

related to the protection strategy, like the amount and value of limiting reactors, required might also impact these

times.

Page 79: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

78

6.1.2 DC voltage restoration time

This KPI is defined as the time from the fault occurrence until DC grid voltage is restored and remains within a

10% range of its nominal value. Figure 6-6 illustrates the time span defined as DC voltage restoration time.

Figure 6-6. Illustration of the voltage restoration time for a DC grid bus.

The DC voltage observed is the voltage of all grid’s bus bars, therefore in the calculation of the voltage restoration

time multiple voltages are considered. For a given fault case, the voltage restoration is considered complete only

when all applicable bus bars have recovered their voltage and stay within the 10% band. The value of 10% is

borrowed from AC systems codes which often considers that once the bus voltage has reached 10% of the pre-

fault voltage it can be considered as restored [23].

6.1.3 Fault interruption time

The investigation of the duration of faults in the grid is a common practice in AC systems, the fault clearance time

(clearing time) is defined as the time interval between the fault occurrence and the fault clearance. This time is

the longest fault current interruption time of the associated circuit-breaker(s) for elimination of fault current on the

faulty item [24].

In literature, the definition of similar concepts regarding reaction time or speed of the protection differ on the above

listed choices in the definition. Regarding the event that starts the interruption time, there are two mainly used

options: when the fault event occurs (similarly to AC fault clearing time definition) or when the measuring

equipment providing the fault information detects the presence of a fault in the DC grid. The basic difference

between these two events is that if the former is used the travelling delay of the fault location until the measuring

equipment is considered in the indicator.

Page 80: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

79

Figure 6-7. Fault current interruption process of a DC mechanical breaker.

Based on the definition found in [25] for fault interruption time (see Figure 6-7). The KPI fault interruption time is

defined as the time span from the fault occurrence until the fault current interruption within the protected zone.

The DC fault current is considered interrupted when it crosses zero and the switching equipment protection zone

ends can open. The definition given for the fault interruption time of DC protection strategies uses the term

protection zone to indicate the grid components where the current is measured. The protection zone considered

for the calculation of the fault interruption time is the faulty component.

6.1.4 Reactive power restoration time

The reactive power support that the HVDC links can give to AC grids features among the most common arguments

for defending the spread of HVDC links. Even when HVDC converters are not transmitting active power, they can

provide reactive support operating in STATCOM mode. The fast reestablishment of reactive power impact not

only voltage restoration at the AC side of the converter, but also the transient stability of the AC grid [26].

The amount of reactive power exchanged with the DC grid after a fault occurrence depends on how the AC voltage

was affected by the DC fault, while the AC voltage restoration is not completed, the Q injection required can

change. The reestablishment of reactive power support to the AC grid after a HVDC fault is greatly dependent on

the protection strategy implemented on the HVDC grid. For most protection strategies, the reactive power is lost

momentarily. However, in some strategies, FB-MMCs based for example, the reactive power support to the AC

grid is not interrupted during the fault clearing [1].

In order to measure the performance of the HVDC grid protection strategy in reducing the disturbance caused by

a DC fault to the reactive support for the AC grid, the KPI reactive power restoration time is proposed. This KPI is

defined as the time from the fault occurrence until the reactive power of an AC zone is restored and remains within

a range of +-10% of its post-fault level. Figure 6-8 illustrates the reactive power restoration time for an AC zone.

Page 81: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

80

Figure 6-8: Illustration of the ready to restore reactive power time for one AC zone (AC1).

Like the active power restoration, the post-fault level of reactive power is the value the converter must exchange

right after the fault; also this value must not change before the reactive power settles in the 10% band. Another

similarity is that the reactive power restoration time can also be calculated separately for AC zones connected to

the HVDC grid.

The ramp-up of the reactive power restoration can be performed in few milliseconds [1] and unlike the active

power restoration, it is not affected by inductances placed at the DC side.

6.1.5 Transient energy imbalance

The KPI transient energy imbalance is defined as the difference between the energy that should be exchanged

between the AC zone and the DC grid if the grid were healthy, and the actual energy exchanged by the zone

under fault conditions of the DC grid. The considered time span for calculation of this KPI is the same as for the

active power restoration time.

Figure 6-9 illustrates the elements for the calculation of the energy imbalance. AC1 represents an AC system and

P1 is the active power exchanged between AC1 and the HVDC grid before the fault. A0 and A1 represent the

energy exchanged between the AC system and the HVDC grid when the system is healthy and when it is in fault

condition respectively. For the given figure the transient energy imbalance is calculated by subtracting A1 from

A0.

Figure 6-9: Illustration of elements used in the calculation of energy imbalance for one AC zone (AC1).

Page 82: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

81

Given the meaning of this indicator, similarly to the active and reactive power restoration time, it might be of

interest to calculate the energy imbalance per AC zone.

6.2 IED performances

The security of an HVDC protection strategy must consider protection equipment (IED) security failures for the

faulty and healthy condition of the grid. In order to represent such features of a protection strategy, three

indicators are proposed:

Figure 6-10. IED performance indicators.

6.2.1 Dependability and security

Dependability and security imply the correct functioning of the algorithm for all faults for which it is designed

(dependability) and the restraining of actions in case of no faults or faults outside of the zone of protection

(security). Thus, when testing the IED, dependability and security of the algorithms implemented in the IED must

be tested.

Figure 6-11 Dependability curves for underreaching and overreaching elements [1].

IED performance

Dependability

(spurious operation failure rate)

Security

(sympathetic operation failure rate)

Speed

Page 83: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

82

For non-unit protection algorithms, the dependability and security depend on the available margins between the

worst-case scenarios for detection of the internal faults and non-detection of the external faults or non-fault

scenarios. Dependability curves are used to register the speed and dependability of the IED as a function of the

fault location along the line. Before such a curve may be constructed, the fault discrimination threshold and

maximum fault resistance must be specified.

6.2.2 Speed

The IED must be sufficiently quick so that the negative effects of the fault are limited and the protection is able to

clear the fault, e.g., the current to be interrupted must lie within the interruptible current of the DC circuit breakers

(if any).

The speed is measured based on the time between the arrival of the fault wave at the relay location and the

instant of sending a trip command to the breaker. The speed of the IED depends on several factors such as

algorithms used, sensors performances, IED hardware and its communication. For instance:

• Fault location along the line

• Fault resistance or arc-fault voltage

• Termination impedance

• Current and voltage instrument transformer characteristics

• Algorithm post-processing

• Communication (IEC61850 in this case)

6.3 Influence of real communication interface

HIL tests will allow testing the IEDs using a real communication standard which is the IEC61850. It is then possible

to evaluate the impact of using IEC61850 in the overall efficiency of non-selective strategies using the same KPIs.

For this, optimum parameters of SV sampling rate, information packets quality and network load level need to be

determined.

Figure 6-12. Characteristics of the communication link using IEC61850.

Indeed, data is affected by the communication network; data at the arrival point (the IED) is distorted by several

factors:

Communication parameters

SV sampling rate

Min packet size

Min packet quality

Min network load level

Page 84: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

83

• Latency of communication due to creation of data packages (SV, GOOSE) at the output of the simulation

(or sensors and merging units in a real substation)

• Latency inherent to the network due to its configuration, buffer overflows, transport delay

• Processing time of the IED running the algorithms

6.4 Calculating efficiency indicators

Since timings, equipment and algorithms used in the primary and backup protection sequence are not the same,

different protection sequences also have different impacts on the grid. As consequence, the efficiency indicators

must be calculated per protection sequence. The general proposed procedure for the calculation of the efficiency

indicators is shown on Figure 6-13.

Figure 6-13: Procedure for the calculation of the efficiency indicators.

HIL simulations are used to calculate the efficiency indicators. These simulations (n simulations in total) consist

in inserting a fault in the grid and performing the protection sequence under analysis. For each simulation, the

values used for the KPIs calculation are found and stored. The n in Figure 6-13 represents the number of

simulations required for an acceptable accuracy level. Several simulations are required in order to consider

different parameters that can affect the values calculated. Since to simulate all possible scenarios is impossible,

it is recommended to identify the scenarios to simulate that are pertinent to the KPIs calculation. For example, if

only maximum values are considered for the KPIs value, the set of simulations to be performed can be reduced

to the scenarios considered as the most severe for the protection. These scenarios are characterized by the high

currents and swift drop of voltage.

The test cases proposed in this work are resumed in Figure 6-14. For benchmark grid 1, since it is a bipole system,

only P-to-G faults are tested (a total of 36 simulations). For the benchmark grid 2, a total of 72 simulations need

to be performed, P-to-G and P-to-P.

Page 85: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

84

Figure 6-14. Proposed test cases to compute KPIs for CBS and FBS. Note: half the cases will be tested in CBS due topology assumptions.

Figure 6-15. Fault locations and cable distances for HIL tests of the 4T meshed HVDC network.

To test the influence of the communication, the worst-case scenario among the test cases is chosen. It

corresponds to the one with the lowest KPI. The following set of case scenarios are then used to test the system

and calculate the KPIs for each case.

Page 86: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

85

Figure 6-16. Proposed test cases to study communication implementation impact on CBS and FBS.

The data required for the calculation of a given efficiency KPIs is the value of respective measurement indicated

in Table 6-1 during the time span also indicated in the table. Basically, the time span required for a given

measurement starts with the fault occurrence and finishes with the fulfillment of the condition associated to the

KPI. Figure 6-2 shows the measurements from each simulation required for the calculation of IED KPIs.

Table 6-1: Measurements required for each efficiency KPI.

KPI Measurements required

per simulation

Time span

Start End

Fault interruption time

Current at faulty line ends

Fault occurrence or Security failure occurrence when no

fault happens

Current is zero or first zero-crossing

DC voltage restoration time

All busbar voltages Voltage settles within +-10% of the nominal voltage

Active power restoration time

Active power at AC side of all converters

Active power settles within +-10% of the post-fault

active power

Reactive power restoration time

Reactive power at AC side of all converters

Reactive power settles within +-10% of the post-

fault reactive power

Transient energy imbalance

Active power at AC side of all converters

Active power settles within +-10% of the post-fault

active power

Table 6-2. Measurements required for IED KPIs.

KPI Measurements required per simulation

Criterion

Dependency [%]

Tripping signals Ratio of sympathetic tripping per IED NT/Next-f

N: number of fault scenarios where a tripping is expected

Page 87: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

86

Security [%] Tripping signals Ratio of spurious tripping per IED NT/Nt-f

N: number of fault scenarios where a tripping is expected

Speed [ms] Current at faulty line ends plus tripping

signals

Time from arrival of the fault front wave to the terminals of the IED until the

instant were a tripping signal is generated.

Table 6-3. Protection strategy efficiency KPIs for all fault cases with best communication performances set.

Primary protection sequence

Time [ms]

Min Avg Max

Fault interruption time 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛

𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒

DC voltage restoration time 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛

𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒

Active power restoration time 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛

𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒

Reactive power restoration time 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛

𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒

Transient energy imbalance 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛

𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒

Table 6-4. IED KPIs for all fault cases with best communication performances set.

IED 1 IED 2 … IED n

Min Avg Max Min Avg Max … Min Avg Max

Dependency [%] %𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛

𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 …

Security [%] …

Speed [ms] …

Table 6-5. Protection strategy efficiency KPIs calculated for the worst case scenario and degraded communication settings.

Time [ms]

Min Avg Max

Fault interruption time

DC voltage restoration time

Active power restoration time

Reactive power restoration time

Transient energy imbalance

Table 6-6. IED KPIs calculated for the worst case scenario and degraded communication settings.

IED 1 IED 2 … IED n

Min Avg Max Min Avg Max … Min Avg Max

Dependency [%] %𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛

𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 …

Security [%] …

Speed [ms] …

Page 88: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

87

REFERENCES

[1] PROMOTioN-WP4, "D4.3 Report on Performance, interoperability and failure modes of selected protection methods," 2018.

[2] M. Héder, "From NASA to EU: The Evolution of the TRL Scale in Public Sector Innovation," 2017.

[3] I. Jahn, F. Hohn, G. Chaffey and S. Norrga, "An Open-Source Protection IED for Research and Education in Multiterminal HVDC Grids," IEEE Transactions on Power Systems, vol. PP, pp. 1-1, 1 2020.

[4] J. Bélanger, P. Venne and J.-N. Paquin, "The what, where, and why of real-time simulation," Planet RT, pp. 37-49, 1 2010.

[5] M. Zillgith, "Open source libraries for IEC 61850 and IEC 60870-5-104," MZ Automation GmbH, Bahnhofplatz 7, 79183 Waldkirch, 2020.

[6] E. Tebekaemi and D. Wijesekera, "Designing An IEC 61850 Based Power Distribution Substation Simulation/Emulation Testbed for Cyber-Physical Security Studies," 2016.

[7] F. Steinhauser, Measuring Propagation Delays and Assessing Performance of Power Utility Communication Networks, 2014.

[8] PROMOTioN-WP4, "D4.1 Definition of test cases and functional requirements for DC grid protection methodologies," 2017.

[9] PROMOTioN-WP4, "D2.1 Grid topology and model specification," 2016.

[10] PROMOTioN-WP6, "D6.9 Standard DC CB model verification plan and RTDS models," 2017.

[11] P. Ruffing, N. Collath, C. Brantl and A. Schnettler, "DC Fault Control and High-Speed Switch Design for an HVDC Network Protection Based on Fault-Blocking Converters," IEEE Transactions on Power Delivery, vol. 34, pp. 397-406, 2 2019.

[12] A. Zama, S. Bacha, A. Benchaib, D. Frey and S. Silvant, "A Novel Modular Multilevel Converter Modelling Technique Based on Semi-Analytical Models," 2016.

[13] R. Wachal, A. Jindal, S. Dennetiere, H. Saad, O. Rui, S. Cole, M. Barnes, L. Zhang, Z. Song, J. A. Jardini, J. Garcia, F. Mosallat, H. Suriyaarachich, P. Le-Huy, A. Totterdell, L. Zeni, S. Kodsi, D. Tiku, P. Thepparat and Y. Yang, Guide for the Development of Models for HVDC Converters in a HVDC Grid, 2014.

[14] M. Zama, "Modeling and Control of Modular Multilevel Converters (MMCs) for HVDC applications," 2017.

[15] P. Ruffing, A. Schnettler, C. Brantl and M. Stumpe, "A Novel DC Fault Blocking Concept for Full-Bridge Based MMC Systems with Uninterrupted Reactive Power Supply to the AC Grid," 2018.

[16] D. Jovcic, W. Lin, S. Nguefeu and H. Saad, "Low Energy Protection System for DC Grids Based on Full Bridge MMC Converters," IEEE Transactions on Power Delivery, vol. PP, pp. 1-1, 1 2018.

[17] C. Petino, M. Heidemann, D. Eichhoff, M. Stumpe, E. Spahic and F. Schettler, "Application of multilevel full bridge converters in HVDC multiterminal systems," IET Power Electronics, vol. 9, pp. 297-304, 2016.

[18] R. Malik, K. Akesson, H. Flordal and M. Fabian , "Supremica - An efficient tool for large-scale discrete event systems," IFAC PapersOnline, vol. 50, no. 1, pp. 5794-5799, 2017.

[19] C. G. Cassandras and S. Lafortune, Introduction to Discrete Event Systems, Springer, 2008.

[20] M. Romero-Rodríguez, R. Delpoux, L. Piétrac, J. Dai, A. Benchaib and E. Niel, "An implementation method for the supervisory control of time-driven systems applied to high-

Page 89: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

88

voltage direct current transmission grids," Control Engineering Practice, vol. 82, pp. 97-107, 2019.

[21] G. Dantas de Freitas, "Développement d'une méthodologie de comparaison des stratégies de protection pour les reseaux DC," 2016.

[22] J. C. Gonzalez-Torres, V. Costan, G. Damm, A. Benchaib, A. Bertinato, S. Poullain, B. Luscan and F. Lamnabhi-Lagarrigue, "HVDC protection criteria for transient stability of AC systems with embedded HVDC links," The Journal of Engineering, vol. 2018, pp. 956-960, 2018.

[23] ENTSO-E, "ENTSO-E guidance document for national implementation for network codes on grid connection: post-fault active power recovery," 2016.

[24] IEC-60050, "IEC 60050: 2018--International Electrotechnical Vocabulary," 2018.

[25] CIGRE, "Technical requirements and specifications of state-of-the-art HVDC switching equipment," 2017.

[26] J. C. Gonzalez-Torres, "Transient stability of high voltage AC-DC electric transmission systems," 2019.

[27] E. O. I. Schweitzer, B. Kasztenny, M. V. Mynam, A. Guzman, N. Fischer and V. Skendzic, "Defining and Measuring The Performance of Line Protective Relays," in 43rd Annual Western Protective Relay Conference, Spokane, WA, 2016.

[28] N. Johannesson, S. Norrga and C. Wikstrom, "Selective Wave-Front Based Protection Algorithm for MTDC Systems," in Proc. IET DPSP, Edinburgh, UK, 2016.

[29] W. PROMOTioN, "D4.3 Report on Performance, interoperability and failure modes of selected protection methods," 2018.

[30] C. I. G. R. E. W. G. A3/B4, "Technical requirements and specifications of state-of-the-art HVDC switching equipment," 2017.

[31] M. Wang, G. Chaffey, D. Van Hertem, I. Jahn, F. Page, K. Ishida, K. Kuroda, L. Kunjumuhammed, I. Cowan, B. Ponnalagan, M. Rahman and O. Adeuyi, "Multi-vendor interoperability tests of IEDs for HVDC grid protection," 2020.

[32] W. R. LEON GARCIA, "Hardware-in-the-loop testing of IED prototypes for HVDC systems protection," in RT18, 2018.

Page 90: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

89

7 APPENDIX – PRELIMINARY TESTS: FEASIBILITY OF IEC61850 FOR CBS

Preliminary tests were performed in a three-terminal HVDC grid for which the CBS strategy has been tested prior

to WP9 tests. The scheme is illustrated in Figure 7-1. In this test case, distance between terminals was not

emulated, which could be done through delays. The effect of this distance has already been studied in offline

simulations without effect on the protection sequence performances. Under this assumption, process bus 1, 2 and

3 share together the same physical link, one single ethernet switch.

Figure 7-1: Three-terminal HDVC test network with communication links illustrated.

Figure 7-2. DCCB tripping signals. 0: opened, 1: closed.

Page 91: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

90

Figure 7-3. Successful Fault sequence and clearing using prototyped IEDs in a 3T grid.

Page 92: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

91

Figure 7-4. Printed messages when launching IED program in RPI.

Page 93: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

92

The latency linked to the IEC61850 standard was tested in a loopback configuration for a sampling rate of the SV

set at 15.36 kHz (65.1 µs). According to the standard, one single SV message contains the information of

8 samples (points). Hence, the latency linked to the package creation must be around 520 µs. This was confirmed

through these tests, as it is shown in the following chart.

Figure 7-5. Latency measured for 10 different loop backed SV and GOOSE messages.

In addition, the following waveforms can be observed for a qualitative analysis of the data using IEC61850. The

first plot shows the ideal value obtained with the real-time simulation during a fault on an HVDC grid.

Figure 7-6. Data generated by simulation at sampling rate of 40 kHz.

The HVDC grid tested to obtain the following plots has three terminals in meshed configuration and three cables.

There are two parallel programs running in the IED. The first one is the main program that configures the

communication, initializes relay parameters and run the algorithms. The second one is a parallel thread launched

from this main program. This parallel thread manages the capturing and creating of SV and GOOSE messages.

-2

3

8

13

18

0 50 100 150 200 250 300 350

Cour

ant (

kA)

Sample number

Data obtained from real-time simulation

Page 94: D9.5 Hardware-in-the-loop test environment and guidelines ...

PROJECT REPORT

93

Both programs run at different non synchronized speeds. Thus, the shape of data seen from these two programs

differ from each other. This is observed in the following two plots.

Figure 7-7. Data stored from the SV Listener thread (function in charge of hearing SV messages)

Figure 7-8. Data stored from while (1), the program executing protection functions in protection IED.

Both above plots clearly show a distortion with respect from the original data coming out of the simulation.

However, fault cases performed with the converter breaker strategy on a three-terminal grid show a successful

fault clearing in all case scenarios, meaning that detection and identification algorithms were not affected by this

distortion. To know the limits, tests are still being performed at the time of writing this report.

-1

4

9

14

0 300 600 900 1200 1500 1800 2100

Cour

ant (

kA)

Sample number

Data seen from the SV Listener thread(this thread runs in parallel with the algorithms program)

-1

4

9

14

0 100 200 300 400 500 600 700

Cour

ant (

kA)

Sample number

Data seen from the IED program running the protection algorithms