Automated Testing of HVDC Control & Protection Systems: A study on Automated Regression Testing

(1)

Examensarbete 30 hp Juni 2018

Automated Testing of HVDC Control & Protection systems

A Study on Automated Regression Testing

Hampus Halvarsson

(2)

(3)

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress:

Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress:

Box 536 751 21 Uppsala

Telefon:

018 – 471 30 03

Telefax:

018 – 471 30 00

Hemsida:

http://www.teknat.uu.se/student

Automated Testing of HVDC Control & Protection Systems

Hampus Halvarsson

Testing is an important activity when developing a system. Testing requires resources in terms of time, labour and money. By correctly automating the tests, the development time may either be shortened or there will be a possibility to run more tests. ABB in Ludvika has

developed MACH, a control & protection system for HVDC (high power electrical transmission over long distances) applications. During

development of the control & protection system for each HVDC project, which are all unique, the system is today tested manually, which

takes considerable time.

This thesis project studies the possibility of automating parts of the MACH system tests, by investigating current testing procedures, the control & protection system itself, and how a test tool may interact with the system. Using this information a test framework, aimed towards test automation, was created, and a simple test execution tool was developed. A new test case, a combination of multiple smaller test cases, ran on the system using the test execution tool.

The outcome proves the proof of concept of automating parts of the system tests. The economics and the scope of the automated testing however, is dependent on how automation is implemented.

Tryckt av: Uppsala

ISSN: 1650-8300, UPTEC ES18 028 Examinator: Petra Jönsson

Ämnesgranskare: Juan de Santiago

Handledare: Raheleh Mahdivand-Avilagh, Archit Singh, Linlin Wang

(4)

(5)

Popular Scientific Summary in Swedish

När ett system ska utvecklas är det viktigt att det även testas, vilket kostar både arbetstid och pengar. För att försöka minska ner på de resurser som krävs för att utföra tester, kan testning automatiseras. Med automatisering menas att ett datorprogram utför idag de uppgifter som en människa normalt sett utför.

Automatisering kan leda till att fler tester hinner utföras under en bestämd period eller minska ner den tid som behövs för att utföra samma tester.

På ABB i Ludvika utvecklas system för elektrisk kraftöverföring med hjälp av HVDC (högspänd likström). Kraftstationerna som sammankopplar HVDC systemet med det vanliga elnätet har ett sofistikerat kontrollsystem som utvecklats på ABB (MACH). MACH-systemet kontrollerar viktiga funktioner på HVDC kraftstationen, till exempel hur mycket kraft som överförs, men även andra funktioner på stationen såsom ventilation och reservkraft. Då varje HVDC-projekt är unikt, behöver MACH-systemet anpassas för varje individuellt projekt. Un- der utvecklingen av MACH-systemet utförs det tester kontinuerligt, av vilka alla idag utförs manuellt.

Syftet med detta examensarbete har varit att studera vilka möjligheter som finns för att automatisera testningen av MACH-systemet. Detta för att möjliggöra mer frekvent testning jämfört med idag.

Metoden har varit att undersöka de tester som utförs idag för att identifiera vilka typer av tester som utförs, och även identifiera vilka gränssnitt som finns mot MACH-systemet för ett datorprogram. Därefter, genom att använda materialet som tagits fram via undersökningen, utveckla en struktur för hur automatiska tester bör utformas, samt skapa en program-prototyp som kan utföra tester automatiskt.

Efter litteraturstudie och konsultering med anställda på ABB utvecklades sedan en struktur för testautomatisering som utgick ifrån att gränssnittet skall vara enkel för en testare att förstå sig på och använda. Efter att ett lämpligt sätt att ansluta sig mot MACH-systemet funnits, utvecklades ett datorprogram som kunde tolka enkla instruktioner för tester och sedan utföra dessa instruktioner.

För att utvärdera det utvecklade programmet och strukturen utfördes ett demon- strationstest där de olika funktionaliteterna i programmet testades på realistiska testfall. Dessa visade att det finns möjligheter för att införa automatisk testning på MACH-systemet. Lönsamheten däremot beror på hur den automatiska testningen implementeras.

(6)

(7)

Executive Summary

Testing requires resources in terms of time, labour and money. By correctly automating tests it may be possible to run regressions tests on large parts of the system more frequently, compared to manual testing. Frequent regression tests are desirable, since they may help to find unexpected defects in the system in an earlier stage of the development process.

This thesis project studies the possibility of automating parts of testing of the ABB’s MACH Control & Protection system, starting by investigating three different areas:

1. Today’s testing procedure: review what actions that is included in current test process to see what is needed in the framework for automated testing.

2. Control & protection system itself: reviewing architecture of the MACH- system and the software that is used.

3. Interfaces that could be used for a test tool to interact with the system.

A literature study in automated testing was made to find a good practice of how an automated testing framework may be structured. Based on the information from the investigation, a framework aimed towards automated testing for MACH was created. Using the framework, a simple text execution tool was developed, which uses HiBug (an existing protocol at ABB) to interface with the system.

An evaluation was made by creating a demonstrative test case that included a combination a few realistic test cases into one test. The different functionalities from the framework were implemented in test files and run by the tool. The demo showed that there are possibilities to automate the execution of tests on the MACH-system. The feasibility of the automated testing however, is dependent on how automation is implemented.

The proposed framework and tool proves a concept of how a test executing tool can be implemented in practice. There is is still areas left to study in order to reach a complete automated testing procedure e.g. tests including operations on RTDS, automatic test result verification, coordination with a test management tool.

(8)

(9)

Foreword

This thesis work has been both captivating and educational. We would like to thank to following persons for their contributions and involvement in this thesis project.

• Raheleh Mahdivand-Avilagh, Archit Singh, & Linlin Wang; who super- vised this project at ABB and offered both guidance and ideas all throughout the project.

• Aditya Deb, Ted Persson, and other colleagues at ABB’s TK department;

for repeatedly answering our unreasonable questions.

• Bengt Jonsson, professor at Department of Information Technology; and Juan de Santiago, senior lecturer at Department of Engineering Sciences;

our reviewers at Uppsala University for their invaluable feedback during the writing of the thesis.

Lastly we would like to thank everyone at ABB who, during our time at the office, made it a good working environment.

(10)

(11)

List of Figures

1 The V-model development life cycle . . . 4

2 A typical MACH System setup [7] . . . 10

3 A typical popup window for order execution showing a voltage setting [7] . . . 11

4 A screenshot of the HMI showing the SLD and operator actions [7] 12 5 Illustration of C&P phases of an HVDC project [26] . . . 12

6 Illustration of C&P V-model structure [26] . . . 12

7 A signal with three connection points (an excerpt from Figure 11) 14 8 Two different types of symbol blocks in HiDraw, a boolean NOT and a booleanAND . . . 14

9 An analog order . . . 15

10 A digital order . . . 16

11 A typical HiDraw drawing showing inputs and outputs for a digital order . . . 17

12 On the right side, the cubicles that contains the MACH main computers and the I/O systems are shown. . . 18

13 Demonstration test case visualised . . . 21

14 Testing structure overview . . . 25

15 Adding sequence of actions to a test file in HiDraw . . . 29

16 An overview over the flow of the automation tool . . . 31

17 Overview of the flow for parsing actions files. . . 32

18 Overview of the flow for running actions . . . 32

(16)

List of Tables

1 Input and output signals of an analog order . . . 15 2 Input and output signals of a digital order . . . 16 3 Status indication of a digital order . . . 34 4 A simple feasibility calculation for running tests automatically. . 44

(17)

List of Code Listings

1 Example of a test file. . . 25

2 Example of a configuration file . . . 26

3 Examples of actions . . . 27

4 The structure of a configuration file is keyword, system name, and finally data. . . 31

5 Excerpt from the source file generated by HiDraw, from the drawing in Figure 11 . . . 34

6 The input file to the command utility . . . 36

7 Example of output from the command utility . . . 36

8 A example of a log file from the system . . . 42

9 Test case file; Kriegers.tst . . . 51

10 Test case file; Kriegers2.tst . . . 51

11 Configuration file; Nordlink.conf . . . 52

12 Preparatory actions file, Kriegers.Prep.PC1.STBY.OPN.act . . . 53

13 Preparatory actions file, Kriegers.Prep.PC2.STBY.OPN.act . . . 53

14 Test 1 actions file, Kriegers.Run.PowerTransfer.S1S2.act . . . 53

15 Test 1 actions file, Kriegers.Run.PowerTransfer.S2S1.act . . . 54

16 Test 1 actions file, Kriegers.Run.PowerTransfer.Stop.act . . . 54

17 Restoration actions file, Kriegers.Restore.PC1.OPN.STBY.act . . 54

18 Restoration actions file, Kriegers.Restore.PC2.OPN.STBY.act . . 55

(18)

Abbreviations and Definitions

Abbreviation Explanation

AC Alternating Current

AO Analog Order

Boolean0 Booleanfalse Boolean1 Booleantrue C&P Control & Protection

DC Direct Current

DO Digital Order

FST Factory System Test

GTO Gate Turn-off Thyristors GUI Graphical User Interface

HMI Human Machine Interface, i.e. User Interface HVAC High Voltage¹ Alternating Current

HVDC High Voltage Direct Current

IDE Integrated Development Environment IGBT Insulated Gate Bi-polar Transistors

IP Internet Protocol

ITI Inspection and Test Instructions

LCC Line Commutated Converter

LAN Local Area Network

MACH Modular Advanced Control for HVDC RFE Ready For Energisation

RTDS Real Time Digital Simulator SCM Station Control & Monitoring

SLD Single Line Diagram

TFR Transient Fault Recorder

TCC Tap Changer Control (for transformer) TCP Transmission Control Protocol

VSC Voltage Source Converter

WCF Windows Communication Foundation

1Typically, ≥ 115kV

(19)

1 Introduction

1.1 Statement of Originality

This thesis was written by two persons studying different programs at Uppsala University. Hampus Halvarsson’s main focus has been the testing framework.

Arnav Jain’s main focus has been the communication interfaces and the automation tool. The report is published in two copies with different identifiers, IT 18031 and ES 18028.

• Arnav: Sections 3.3,3.6

• Hampus: Section3.4

• The remaining sections are combined work

1.2 Setting

Almost every type of development today requires many hours of testing before a product is ready for production release, this testing may translate to verification and validation of intended behaviour in different scenarios [1]. The same testing is required again when the product is changed, either for correction of emerging unintended behaviour or for further development, as this may cause new unintended behaviour of previously correct behaviour [2].

Testing of complicated systems may be very costly or resource intensive, in terms of time and/or labour [3], as a small change in one part of the system may have completely unexpected consequences in another part of the system [2]

which requires re-testing of the whole system.

ABB, a multinational corporation [4], while expanding in many different fields, has stayed true to its origin, mainly electric power transmission over long distances [5], for the longest distances using HVDC (High Voltage Direct Current) transmission [6][7]. There are many different systems, parts, and components involved in electric power transmission and any unforeseen and unintended behaviour may cause major impact on the electrical grid, which is a key part of the modern infrastructure (although this may not always be visible) [8]. Thus, system development in this field requires rigorous testing prior to field deploy- ment.

HVDC Converter stations (one part of the HVDC transmission system) are spe- cialised electrical substations [9] that either convert AC to DC (rectifiers [10]) or DC to AC (inverters [10]). The Control & Protection (C&P) system developed by ABB for controlling these converter stations is known as MACH, Modular Advanced Control for HVDC [7][11][12]. Designing MACH system for any HVDC system is unique and very much tailored for the HVDC project.

During development for every HVDC project, the MACH system undergoes

(20)

multiple rounds of testing and verification [11], to ensure proper functionality of the system. One of these rounds is known as Factory Systems Test, FST [7][11][13]. During the FST, the system is tested in accordance with ITI, Inspection and Test Instructions, which defines the testing procedure. When a bug or system defect is found, said defect is rectified and the rectified system is then re-validated. Due to the complexity and interconnectivity of the system, a correction made in one part of the system may affect other parts of the system, sometimes with unintended consequences. Today these consequences may not be discovered until later in the development/testing cycle, as the whole systems is not re-tested continuously but rather only the worked/corrected parts are re-tested.

1.3 Project Purpose and Goal

The purpose of this thesis project is to evaluate possibilities for optimising the verification process, during the FST phase, through introduction of automated regression testing to enable more frequent re-testing of the whole system.

The goal is to review the current test and verification process focusing on the different types of test cases run, the systems currently in use to find possible interfaces against the MACH system. By using this data, create a prototype for a platform that may be used for implementing automated regression testing.

Focus for this project will be on the test execution part.

1.4 Scope

The scope of this thesis project will be:

• Assess a number of test cases from the current ITI, Inspection and Test Instructions, to determine if the human inputs in the test cases may be automated.

– Select three or four test cases able to be automated to create a proof of concept.

– Suggest actions to enable automation of the test cases judged unable to be automated at this stage.

• Study the current systems setup and investigate possible interfaces to MACH main computers for automation.

• Sketch on a test framework which may be used for automated testing.

• Develop a test execution tool based on the framework which can commu- nicate with the MACH main computers and run test cases.

• Investigate the feasibility of automation; taking resources spent on development and potential reduction in resources for testing.

(21)

1.5 Delimitations

• The number of cases in a test suite is dependent on the scope of each HVDC project but may require several hundred independent cases. While the end goal of the company is to have all possible test cases run automatically in a (possibly) pre-determined order, this thesis project (in case automation is possible) is limited to to create a proof of concept which focuses on two or three different types of cases and analysis of them.

• The test cases may be split into two different categories [7],control testing andprotection testing. Test cases in this project will be selected from the control category. Time did not permit to analyse protection cases.

• After verifying the test outcome, the results need to be presented in a manner which can easily be interpreted by the end user (i.e. the operator reviewing the results). The goal for the company is to have a test report generated at the end of the automatic test cycle for the operator to review the results from all test cases in the test run.

This report is not included in the scope of this degree project. If the opportunity arises during the project in terms of resources, the report may be included then. In such case the specification for the report will be specified at that point in time.

(22)

2 Background

2.1 Systems Development Life Cycle

Today, there are many different ways to manage the SDLC, System Development Life Cycle [14][15]. The very first model (or rather lack of) utilised is referred to as Code-and-Fix model [14], but some of the more common ones are the Waterfall model, Incremental model [15] and V-model [3].

Regardless of which SDLC model is chosen for development of a system, there are some steps which are common to most models. These steps include [14][15][16]:

• Requirements

• Design / Specification

• Build / Develop / Implement / Manufacture / Code

• Integration / Verification / Testing / Quality Assurance

• Acceptance / Delivery / Maintenance

2.1.1 Requirements

When developing a new system or modifying an existing system, the developer needs to know what the system is supposed to do, this is known as the system requirements [14][17]. Without a clear specification of the system requirements, the developed system will never meet the requirements and subsequently all the effort and time spent on developing will most probably be wasted [14].

Figure 1: The V-model development life cycle

2.1.2 Design Phase

Designing a system specifies how to develop a system which is capable of per- forming the activities specified in the requirements. Design is the process of transforming a problem into a solution. [14]

The design of the system can be divided into two different types, the first type is thearchitecture. The architecture describes interfaces of the system; how does the system look or how does the users interact with the system. Designing the architecture of a system is also sometimes referred to as the style. [17]

The second type is thedetailed design. Detailed design describes the algorithms and the procedures for implementing the style of architecture, i.e. the behind the scenes functionality and workings of the system. [14]

(23)

2.1.3 Implementation Phase

The implementation phase is often the heart of the systems development [17].

During implementation, the design created in the design phase is realised into a product, physical or virtual.

2.1.4 Testing Phase

Testing is defined inA Dictionary of Computer Science [18] as:

Any activity that checks by means of actual execution whether a system or component behaves in the desired manner. This is achieved by one or more test runs in which the system is supplied with in- put data, known under these circumstances as test data, and the system’s responses are recorded for analysis.

Tests can be categorized according to the conditions under which they are performed and the purposes they serve. Module testing (or unit testing) is performed on individual components in isola- tion. At the time that components are brought together to form complete subsystems or systems, integration testing is performed in order to check that the components operate together correctly. In- tegration testing typically pays particular attention to the interfaces between components. By contrast, system testing normally treats the complete system as a ‘black box’ and investigates its behaviour without concern for individual components or internal interfaces.

Acceptance testing is normally under the control of the procurers of the system, and is designed to ensure that the system is suitable for operational use.

Rectifying found errors during testing is also often covered during the testing phase.

2.1.5 Delivery Phase

When development of the system is completed, access to the system may be given to administrators, operators and end users. The process of delivery also requires planning and can be done in multiple ways. [14]

2.2 Software Testing Process

2.2.1 Test Activities

There are a number of different activities in testing, and how they are carried out differs. The core activities and the order that they are carried out are often

(24)

similar to the described activities written below. [3]

The first thing to do is determine what should be tested i.e. the identifying the conditions that can be verified by a test. There will be a lot of different conditions that can be tested for a system, such as the software functionality, security, performance etc. [3]

When test conditions are identified, test cases may be designed. Based on the test objective (reason or purpose of the test), a set of tests are chosen related to that objective. A test case should contain the specified input values, prerequisites, expected outcome and other relevant information that is needed to perform the case. If the test outcome is not specified in advance, there is an option to use the first correct outcome as a reference for future testing. Usage of this option requires the tester to have adequate knowledge of the software so that the reference outcome is correctly assessed. [3]

The next step of the process is to build the test scripts, i.e. to implement the test design into scripts. All the data, instructions, test inputs and outcomes should be in a form that could be interpreted by the test execution tool used (if there is one). All the preconditions must be implemented in the cases, since some of the tests may require a database to be initialized or some hardware is ready to be used in order to work as intended. [3]

Using the test cases, the tests may now run. If the tests are run manually, the tester may need to follow a procedure where all the actions and inputs are listed. If there is a tool for automated execution of tests, the tester would need to choose which tests that should run and then start the tool. [3]

Comparing the actual outcomes of the test, verification, is the last step in the testing process. The outcomes need to be checked to see if the software has passed the test. There are two different approaches for comparison: dynamic comparison, where results are compared during the test execution; and post- execution comparison, where results are compared after the test execution is complete. [3]

2.2.2 Verification and Validation

There are various interpretations of the terms verification and validation [3][14].

To illustrate our interpretation of these terms we will use a simple example.

Suppose that a small bank wants to develop a simple accounting system where the bank can create accounts and carry out transactions (e.g. deposit, withdrawal) on said accounts. The development of the system is divided into two phases, the first phase being dedicated for the deposit functionality and the second phase being dedicated for the withdrawal functionality.ññ

Verification is the process of checking whether the system meets all design requirements [14] and produces the correct outcome [3]. In our example above with the bank, it is translated to the following:

(25)

• By end of development phase one, verification is performed to check that a deposit can be performed correctly.

• By end of development phase two, verification is performed to check that a withdrawal can be performed correctly.

Validation is the process of checking whether the design requirements meets the intention of the product, i.e. is the system being built fulfilling its intention [3][14]? The system may passverification by meeting the set design requirements, but fail validation because the design requirements set are not correct or incomplete.

2.2.3 Automated Testing

Automated testing, compared to manual testing, can substantially decrease the effort required to perform tests, or increase the amount of tests that can be performed during a limited time. This may lead to significant savings in costs and/or time for the company [3].

Boring and repetitive tasks are often good candidates for automation [3]. Other suitable candidates for automation are re-runs of already existing tests, regression testing. One major benefit with automation is that tests may run more often, with considerable consistency and repeatability [3]. However, non-repetitive tests may not be suitable for automation as the automation process requires more resources than could be benefited from it [19].

There are some pitfalls to avoid when implementing automated testing. Auto- mated tests will not fix any deficiencies that exists in cases and procedures that the automated testing should be based upon. If tests are poorly organized and with inadequate documentation, the focus should rather be on improving the testing procedure instead of on automation. [3]

There are also limitations with automated testing. Manual testing is not fully eliminated, as sometimes not all steps in a test can be automated. It is hard to fully automate a test if it requires human interaction during the test, such as connecting/disconnecting equipment. If there are major changes during the development so that new test scripts are required, or if test cases are only used a few times, automation is not likely to be cost effective. [3]

2.2.4 Regression Testing

Regression testing is when existing test cases are re-run when a part of the system is modified [20]. Purpose of regression testing is to discover if the mod- ification has affected other parts of the system, and caused new errors (causing a regression of that component) [20]. In large systems it is not always possible to run all the different regression test cases in one go since it may be too time consuming, thus there are different techniques to handle the situation

(26)

e.g. test selection and test prioritization [21]. These techniques use different methods to ensure that the most important test cases fit within the collection of tests [21][22].

Regression tests, like many other tests, are often run manually, but unlike other tests, are good candidates for automation [3]. Take the simple bank program (from Section 2.2.2) as an example. When verifying the new functionality of second phase, the system should be regression tested to ensure that the functionality from first phase remains unchanged. This regression testing of depositing money should be performed after each and every change performed in the system, and as such this test may be automated as the input to the system and the expected output from the system is known.

2.2.5 Different Types of Regression Testing and Verification Tools

When running an automatic regression test, in some scenarios a single tool may be performing all of the actions required for configuration, running the test and verifying the test results. In other cases these different actions may be divided into multiple separate tools.

Thetest execution tool is often the heart of automated regression testing. Often the number of test cases to be run are large, and running these manually without a execution tool is either quite challenging or difficult [23].

Thecomparator is not a mandatory tool, but is a often part of automated regression testing. Performing one or multiple comparisons between the expected outcome and the actual outcome is the process of verifying a test case [3]. The comparator tool helps reducing the time and effort required to identify test failures [23].

When having multiple teams or having multiple versions of the system, tracking all different versions manually may be challenging. Aconfiguration management tool is also not a mandatory tool, but may help tracking system versions and the associated test files. [23]

A test management tool is also not a mandatory tool, but a useful one. A test management tool may help keeping track of tests executed and their results, any faults identified, and actions taken or planned as a result of said faults. [23]

2.3 HVDC Systems

2.3.1 HVDC compared to HVAC Systems

The traditional usage of HVDC is for bulk transfer of electrical power, but the technology has other benefited applications such as long distance transmission and enabling connections between asynchronous AC networks. There are many factors that differ when comparing an HVAC transmission system with HVDC

(27)

transmission system. An AC transmission system often uses three conductors with AC, alternative current, where as DC transmission system may use one conductor or two conductors.

A DC transmission has lower losses compared to an AC transmission, since there is no skin effect present in DC transmissions. An AC conductor has a physical length restrictions due to the reactive properties, but HVDC has no such limit.

HVDC converters have inherent functions for active power control, which makes HVDC more flexible. Another important benefit is that an HVDC cable can be used in long distance underwater or underground links, whereas an AC-cable would get too high capacitance. [24]

A cost comparison between HVAC and HVDC system for bulk power transmission shows that HVDC is cheaper in distances above 30-40 km for underground and sub-marine cables. For overhead cables, the HVDC technology has lower costs in systems with a distance above approximately 400 km. Some of the drawbacks with HVDC, compared to AC, is the expensive cost of the converters, creation of harmonics that need filtering and difficulty in creating DC grids with different voltage levels. [24]

2.3.2 HVDC Converter Station

A converter is the component in the HVDC system that transforms AC to DC and vice versa. The converter at the station that transmits power acts as a rectifier, transforming three-phase AC into DC. On the receiving side the converter at the station acts as an inverter, transforming DC into three phase AC.

Today, there are two different types of HVDC, the traditional line commutated converter (LCC), and the voltage source converter (VSC), both types having their benefits and applications. The biggest difference between the two techniques is the power electronic components that are used as switching devices in the valves, where LCC uses Thyristors, VSC are using insulated gate bipolar transistors (IGBT) or gate turn-off thyristors (GTO). There are many different topologies for HVDC operating configuration depending on earthing, amount of connected converters, symmetry/asymmetry etc. [24]

2.4 MACH

MACH, or Modular Advanced Control for HVDC, is a Control & Protection system developed by ABB [12] which is fully computerised [7][11]. The software orapplications running on the MACH system are developed using HiDraw (Section 2.5.1.1), a graphical block programming language, and analysed with help of HiBug (Section 2.5.1.2), a graphical debugger tool [7][11]. The MACH system consists of Station Control & Monitoring (SCM) servers, Operator Work- stations (OWS), Engineering Workstations (EWS), Control & Protection main computers and I/O system units, typically connected in a configuration shown in Figure2[7].

(28)

Operators are able to monitor and control the MACH system using an HMI, which runs on the OWS. The HMI communicates or interfaces with the main computers, which are the the central components of the MACH system. The Control & Protection logics developed in HiDraw runs on the main computer.

Each main computer is in turn connected to I/O systems. In a live environment (i.e. after delivery, on site), the I/O system is connected to and communicates with physical equipment, e.g. transformers, breakers, disconnecters, instrument transformers. During testing in the factory, before delivery, the I/O is system connected to and communicates with simulated virtual equipment modelled in a Real-Time Digital Simulator, RTDS (more information about the , RTDS, and can be found in Section 2.5.2).

All system parts involved with the operation of the HVDC transmission link and its power transfer (e.g. control system, protection system, SCM LAN) are designed with redundancy in mind, i.e. the operation of the transmission system should not be interrupted by a single point of failure. Subject systems are therefore duplicated and run in parallel. [7][12]. Among other, for the main computer this means there are two active computers for each type of system, an A system and a B system, see Figure2. The current active system is designated active, and the inactive is designated standby.

A number of different standardized buses and protocols are used for communication, these are visualised in Figure2. The communication between the servers, workstations, and the main computers on the SCM LAN is based on the IEEE 802.3 standard (Ethernet). The communication between the main computers and the I/O system, using the Field Bus System is carried out through Ether- CAT which is an Ethernet based bus. The communication between the I/O systems and main circuit equipment (e.g. disconnecters, breakers) is carried out through CAN (Control Area Network, ISO 11898). [7]

2.4.1 Main Computers

The main computers are the brains of the MACH system. On these, the Control

& Protection applications developed in HiDraw runs. Each main computer is connected to the SCM LAN for communication with SCM servers and other workstations. Each main computer is connected with I/O systems through the Field Bus System. As the main computers are designed with redundancy in mind, for each system there are two main computers.

Figure 2: A typical MACH System setup [7]

For control systems, running on the computers, there is only one active system at any time, the other non-active system is running as a hot standby, ready to go active at any time. The switch command for a standby system to become the active system may be initiated automatically or manually. The automatic switchover, for the standby system to take control, is performed in case a fault is detected in the active system. Also, a switchover to a faulty system is not

(29)

possible. [7][12]

For protection systems, also running on main computers, both systems are active concurrently. If any one of the systems detects a fault, a protective action will be triggered by that system. [7][12]

2.4.2 I/O System

I/O systems is the interface connecting the main computers to the HVDC facility. The system communicates with the main circuit equipment throughout the facility using analog and digital electrical signals. The system communicates with the main computers using optical signal. [7]

2.4.3 HMI

Operators are able to monitor and control the HVDC transmission system in real-time using the HMI, running on the OWS, which communicates with the main computers through the local area network (SCM LAN, see Figure2) [25]

using the SuitLink protocol. The HMI also shows integrated diagnostic information about the HVDC converter station such as list of alarms, events, and faults; as well as disturbance recordings [25].

The HMI contains tabs to navigate between different pages on the HMI. Each page shows different types of information and real-time status of the HVDC converter station, e.g. the Single Line Diagram, SLD, page visualises the con- verter station using a single line diagram, and shows real-time information in fields on the diagram. To change a setting of the system, the operator moves to the relevant page and selects the relevant symbol. When selecting a symbol for action, a new window pops up for confirmation before the requested change is ordered (see Figure 3). Then, the command is sent to the relevant active main computer where an analog or digital order (see Section2.5.1.1) is executed.

Figure 3: A typical popup window for order execution showing a voltage setting [7]

In Figure4, an example of a typical HMI SLD page is shown. The page in this example is divided into two sections. The top sections contains the main SLD, i.e. how the main circuit equipment is organised, whereas the bottom section contains informational fields showing real-time status of the converter station and buttons which represents various other kinds of actions, that the operator can perform. The squares in the SLD represent switching devices (e.g. breakers, disconnecters) that can be operated (opened or closed) by the operator. When the operator selects a square representing the switching device, a popup window (similar to Figure3) is shown for confirmation of action. Similarly to the squares in the top section, a popup windows as in Figure3is shown when the operator

(30)

presses on any of the buttons in the bottom section of this page. The operator then has to confirm the action in the popup window.

Let us observe the process for when the operator initiates a command (e.g. increase power transfer from 20 MW to 50 MW) on the HMI.

1. The operator initiates and confirms the command on the HMI.

2. The command is sent over SCM LAN to active main computer.

3. The main computer executes the relevant order (Section2.5.1.1).

4. The output signals from the executed order are then sent to the relevant I/O system (Section2.4.2) over theField Bus System.

5. The I/O system then converts the command signal to an output signal, analog or digital as required.

6. The output signal is sent either to the RTDS or to physical equipment depending on whether the system is under test or running live.

Figure 4: A screenshot of the HMI showing the SLD and operator actions [7]

2.5 Control & Protection Systems Development

A powerful control & protection system is required to operate an HVDC system in a reliable, flexible, and efficient way [7]. To enable this, ABB implements a linear development model (Figure5) during the development of the C&P systems for each HVDC project, which is based on the V-Model (Figure 6) [26].

The left hand side creates and refines the design requirements of the C&P system for the specific HVDC project. The right hand side compares the implementation against the design requirements specified during the earlier left hand side phases.

Figure 5: Illustration of C&P phases of an HVDC project [26]

Figure 6: Illustration of C&P V-model structure [26]

2.5.1 HiDraw Studio Software

HiDraw Studio is an integrated development environment (IDE) for development using HiDraw. HiDraw Studio manages libraries such as HiDraw drawings and symbol libraries, and includesHiDraw GUI and debugger HiBug [27].

(31)

HiDraw is mainly used for development of various applications required for Con- trol & Protection functions of an HVDC project.

HiDraw Studio and its components are developed internally by ABB, primarily for the MACH system, although most of the functionality can be used for other platforms and applications as well. [28]

2.5.1.1 HiDraw

HiDraw is (ABB’s inhouse) graphical block programming language, based on a pick-place-connect method. The user creates drawings of the logic by plac- ing symbols (function blocks) and connecting symbols with so called signals.

HiDraw can then generate source code in virtually any type of language e.g. C, FORTRAN. Using the drawings, HiDraw can not only generate source code, but also compile the generated source code to an executable file that can run on the target system. [28]

Each application created in HiDraw consists of multiple drawings, and always includes a main drawing which specifies metadata of the application and other drawings [28]. Drawings may cross-refer to signals from other drawings in the same application, but also from drawings in other applications [28]. For example the signals TCP_EQUAL and DEBLOCK_IND in Figure 11 are signals from other drawings in theTCCapplication.

A simplified workflow for designing an application for the MACH main computer in HiDraw is as followed:

1. The C&P system is designed, using HiDraw Studio, in drawings using signals, and other symbol blocks. See Figure8for example of symbol two different symbol blocks and Figure11for example of a drawing.

2. From the drawing, HiDraw Studio generates source code in the C programming language or the C++ programming language.

3. Using the source code generated, an executable binary is compiled using the inbuilt compiler in HiDraw Studio. The target platform for this binary is set when designing the system in step 1.

4. The binary file is sent to the target computer where the application runs.

Signals are analogous to variables in a procedural programming language, which may be of boolean, integer, or float type. Each individual signal has a name, known as signal ID, which is unique in the application. As there may be multiple applications where identical signal IDs are present, each unique signal is therefore identified by a combination of computer name, application name, and signal ID. All signals must be initialised, i.e. they must have a value even if said value is just the default value.

Each signal has a minimum of two connection points, but may have multiple connection points, where each connection point is connected to a symbol. One

(32)

connection point (usually the visually leftmost connection point) writes the signal value, whereas rest of the connection points read the signal value.

Figure 7: A signal with three connection points (an excerpt from Figure11)

The signal in Figure 7 (excerpt from Figure 11) is connected to an Integer symbol on the left side which sets the value to0, while both of the connection points on right side are connected to theDigital Ordersymbol inputsPermit Info (Open)andPermit Info (Close). The signalPERMIT_MANin Figure11 is connected on the left side to aBOOLEANsymbol which sets the value toTRUE, and to the right side to theDigital Order symbol inputPermit (Open).

Figure 8: Two different types of symbol blocks in HiDraw, a booleanNOTand a boolean AND

Symbols are function blocks in HiDraw that read signal values, assign signal values or with help of logic manipulates signal values. Signals are in a drawing connected to symbols with the use of connection points. Each symbol has at least 1 connection point where a signal is connected (be it a input signal or output signal). Some symbols only perform assignments, e.g. setting a signal value to 0 such as the left symbol in Figure 7. Other symbol may perform boolean operations such as booleanNOT or boolean AND, as shown in Figure 8.

Other symbols are more complex with multiple input signals and multiple output signals.

Each order has, similarly to signals, a name which is unique in the application.

For example, the order name in the digital order in Figure10isDO_GCC_ONand in Figure11isDO_TCCMANCTRL. Each unique order is identified, due to the same possible duplication as signals, by a combination of computer name, application name, and order name.

When designing the system, a parameter for execution time is set, usually around a few milliseconds. This is how long one iteration of the system loop takes. During each iteration of the loop, most symbols are evaluated, i.e. the output signals of a symbol are assigned (sometimes new) values. Signal assignments (such as the one performed by the left symbol in Figure 7) and boolean operations (such as the ones performed by the AND and NOT symbols as in Figure 8) are performed every iteration. For example, if the drawing in Figure11has an execution time of 5 ms, the signalsTCC_MAN_ORD (PUBLIC)(assigned by a boolean OR symbol), TCC_MANUAL_CONTROL (PUBLIC) (assigned by booleanNOTsymbol), andTCC_MAN_IND_DURING_OPERATION (PUBLIC)(assigned by a booleanANDsymbol) are all evaluated every 5 ms during each iteration of the loop. Also, if an operator manually changes a signal value, which is an output from a symbol (such as TCC_MAN_ORD (PUBLIC)), using HiBug (see Section 2.5.1.2), that signal value will be overwritten at next evaluation of the symbol (the booleanOR symbol).

(33)

Analog orders (Figure9) and digital orders (Figure10) are two symbols of the more complex type with multiple input and output signals. The main function of these symbols is to provide an interface for the HMI to change configuration or initiate actions in the MACH system. Consequently the output signals of the order symbols are not evaluated during each iteration of the loop, but rather when the main computer receives a command from the HMI are the output signals for the order symbols evaluated. For example, signals LOG_EVENT_MAN (PUBLIC)andCONSOLE_MAN (PUBLIC)(in Figure11) are only update when the digital orderDO_TCCMANCTRLis executed (command from HMI is received).

Figure 9: An analog order

Analog orders are symbols that write an analog value (i.e. integer value or a float value) received from the HMI to a signal. This analog value could for example be a power order reference (i.e. how much power should be transferred between stations), or in the case of Figure9, setting the power order ramp speed (i.e. how quickly the transmitted power changes, first derivative of the power order). An analog order has seven input signals and six output signals, which are defined in Table1.

Table 1: Input and output signals of an analog order Input Signals Output Signals

Permit Setpoint

Permit Status Enter

Actual Value Tag/Untag

Actual Control Location Log/Event

Max Console

Min User

Tag from other

Before any of the output signals may be changed, some checks are performed, by evaluating the input signals. First check is to verify that the order is allowed to change the value (as changing value at inappropriate times may cause unexpected outcomes) by ensuring the Permitsignal is set to a boolean1. Next check is to ensure that the new value to be set is within allowable limits, the limits are read from the Max and Min input signals, the new value should be greater or equal to minimum allowed value and less or equal to maximum allowed value. The current real-time value of the output signal can be read from the input signalActual Value. The signalActual Control Locationidentifies which workstation (OWS) is interfacing with the order.

When the order is executed i.e. the input signals and the output signals are evaluated, the new analog value is written to the output signalSetpoint. This Setpointsignal is only a buffer for the new value, the buffered value is written to the actual output signal when the output signalEnteris toggled to a boolean

(34)

1 and then back to a boolean 0. The output signals Log/Event and Console contains metadata about the execution of the order and are used for logging purposes.

The signalsPermit Status,Tag from other, Tag/Untag, andUserare legacy signals and not used today.

Figure 10: A digital order

Digital orders are symbols that write boolean values to signals and are often used to trigger individual actions or sequence of actions in the MACH system. One such action (for which the logic is shown in Figure11) is toggling the operation of the TCC equipment between manual mode or automatic mode. Each order has eight input signals and six output signals. The input signals and the output signals of an digital order are defined in Table2:

Table 2: Input and output signals of a digital order Input Signals Output Signals Permit (Open) Order (Open) Permit (Close) Order (Close) Permit Info (Open) Tag/Untag Permit Info (Close) Log/Event Actual Control Location Console Indication (Open) User Indication (Close)

Tag From Other

Similarly to analog orders, before any of the output signals of the digital order are changed, some checks are performed by evaluating the input signals to the order. A boolean1on the input signalPermit (Open) means that the order is allowed to be set or opened, whereas a boolean1on the input signalPermit ( Close)means that the order is allowed to be reset or closed. The signalActual Control Locationidentifies which workstation (OWS) is interfacing with the order. The input signalIndication (Open)and the input signal Indication (Close)indicates whether the order is currently opened or closed.

When the digital order is set/opened, the output signalOrder (Open)is briefly toggled to boolean1then back to boolean0. Similarly, when the digital order is reset/closed, the output signalOrder (Close)is briefly toggled to boolean1 then back to boolean 0. The output signals Log/Event and Consolecontains metadata about the execution of the order and are used for logging purposes.

The signalsPermit Info (Open),Permit Info (Close) Tag from other,Tag /Untag, andUserare legacy signals and not used today.

(35)

2.5.1.2 HiBug

Together with HiDraw a graphical debugger tool, HiBug, is included [11]. HiBug enables the user to connect to a MACH main computer and view the current real-time value of each signal in any one of the currently open drawings [28].

The real-time value of a signal can not only be viewed, but also changed in real- time [11]. HiBug is a protocol based on Windows Communication Foundation, WCF, for communication between HiDraw and the MACH main computer. For more information information about the protocol, see Section3.3.3.

Figure 11: A typical HiDraw drawing showing inputs and outputs for a digital order

The main use case for the HiBug tool is to find the current real-time value of a signal, and which symbol is causing that specific value. Using the cross- reference functionality of the graphical block view, the user can trace the signal and symbols through multiple drawings and between applications to find out which signals and symbols affect a specific signal. [28]

2.5.2 Factory System Test, FST

FST refers to the systems test performed at ABB’s factory before the MACH system is delivered to the site. The setup, during FST, consists of two systems [11]. The first system is the MACH system that contains all the logic and also performs the logging/collecting of data, and which will be delivered to site for installation after successful completion of FST; the second system is an HVDC Simulator [7][13] known as RTDS (Real Time Digital Simulator), that simulates the electrical grid (AC and DC sides), the HVDC converter itself, as well as the surrounding electrical components present at the converter station that the MACH system will have access to (when deployed) [29][30]. The data transfer between the two systems is performed through the analog and digital signal I/O systems connected to the RTDS [30]. Both systems are transmitters and receivers for the signals.

The test cases that are run during FST may be categorised in two different categories;control cases and protection cases. Control cases are initiated by giving commands to the MACH system to carry out its intended control functions [7]

through the HMI (i.e. a terminal) which then sends commands to the RTDS, monitors and verifies that the outcome is as intended. Protection cases are initiated by inducing an electrical disturbance (e.g. three-phase fault or single-phase fault [13]) in the RTDS and the MACH system reacts to subject disturbance to determine if any action is required and then carries out any required actions.

Generally, this means control tests are triggered in the HMI and MACH control system, while protection tests are triggered in the RTDS.

(36)

Figure 12: On the right side, the cubicles that contains the MACH main computers and the I/O systems are shown.

(37)

3 Design & Implementation

3.1 Assessing Inspection and Test Instructions (ITI)

The Control & Protection system for each HVDC project is unique, however, there are also many common factors, both in terms of hardware and software.

Thus, successful development from previous projects may be reused in new projects, instead of starting from the very beginning every time. This common starting point for each new project is known asBase Design. The base design at ABB is updated on regular basis. [11]

The ITI for current Base Design [31] include many test cases common to multiple, if not most, projects, thus the ITI for Base Design was chosen for this assessment. From this base document, three tests were chosen for further investigation to analyse how the tests are performed today. The actions that are performed manually today by the operator are the actions that must be considered in the testing framework.

3.1.1 Test Case 1 - Ready For Conditions

In order to provide a safe and reliable switching within the converter stations the MACH system contains interlocking and maneuvering sequences. Some actions require certain conditions to be fulfilled, prior to the action being performed, otherwise the action will be blocked (i.e. not allowed to run) [32]. The interlocking conditions are tested in the control tests. One category of interlocking conditions isReady for Conditions tests, which tests the interlocking for changing between different operational states [31], which can be many in one HVDC project.

Ready for energisation (RFE) is one of the tests included in the ready for con- ditions category. The test verifies that only when all pre-requisites are fulfilled, only then is the system allowed to energise. The precondition for the test is for the station to be de-energised and with the RTDS in operation [31]. The testing procedure contains:

1. Fulfilling the conditions for RFE: There are certain conditions that all need to be fulfilled in order to obtain the RFE status. Each condition is a status indicator for different parts of the system, such as auxiliary power system is running, or that there is no protective action ongoing.

The operator will have to go to the appropriate page in the HMI (refer to Section2.4.3for tabs/pages) that contains the conditions and visually check them. Then, the operator changes to each page that contains the actions that is necessary for fulfilling the conditions [31].

2. When all the conditions are fulfilled, each condition should be removed.

one by one, to manually verify that RFE is lost for each condition removed.

This is performed at the HMI pages that controls each condition [31].

(38)

3. Last step is to test whether the converter can be energised when RFE is obtained [31]. This action is commanded on the HMI.

In the steps above, step one may be possible to automate by reading signal values from relevant MACH main computers. Step two and three may be possible to automate by changing signal values and by running appropriate analog and digital orders.

The conditions for RFE are different between HVDC projects and are declared in the project specific documents [31]. The following documentation needs to be collected by the operator for this test:

1. The events log from HMI [31].

2. Screenshot of the drawing (Single Line Drawing, SLD) of the HMI where status of RFE may be observed [31], similarly to Figure4.

From the required documentation above, item one may be challenging to automate, whereas item two will not be possible without having access to an HMI.

Documentation item two may however be replaced by logging a momentary snapshot of the system by saving the signal values required.

3.1.2 Test Case 2 - Tap Changer Energised Control

The tap changer control (TCC) application controls the tap changer of the transformer in order to ensure correct relationship between the AC and DC voltages by stepping up and down the tap changer of the transformer [7]. The test case verifies that the tap changer keeps the DC voltages within accepted range even when the AC grid voltage is changed [31]. The AC grid voltage is controlled by the RTDS, so the operator has to perform the voltage changes on that system in order to complete this test case.

3.1.3 Test Case 3 - Operational Test: Start-Up

This test ensures that the start-up of power transmission is operating according to the HVDC project specific reference document [31]. The precondition of this test case is that the station is de-energised and both station are connected on the DC-side. Starting in that state, the operator commands the converter to the state of power transmission, which includes following steps:

1. Fulfilling the conditions for RFE for both stations: (as in test case 1) [31].

2. Energizing stations by starting a energisation sequence through HMI. This results in the AC-breakers are closed and the bus voltage reaches the set limits. [31]

(39)

3. Change to the appropriate page on HMI to verify the stations being ready for operation, followed by taking actions to fulfil the missing conditions if there are any. [31]

4. Deblocking/starting the converter, setting the station into operational state. [31]

The conditions for each step in this test are different between projects and are declared in the project specific documents [31]. The following documentation needs to be collected by the operator for this test:

1. List of events from HMI. [31]

2. Screenshot of the HMI that shows condition of each state [31]

3. Triggered Transient Fault Recorder files (TFR). [31]

3.2 Concept Demo Test Case

A realistic demo test case was created in consultation with the employees at ABB. The case tests the power transmission between two stations, including configuration of the required prerequisites. The idea was to automate this test case, using a framework and a tool that was to be developed. The demo should confirm that the tool works as intended and has the functions required to run similar test cases. All the different actions that the tool should execute (see Sec- tion3.4.4) were included in the test case to verify that they worked as intended.

The proposed demo included the following activities:

Figure 13: Demonstration test case visualised

• Preparation

– Start in a known reference state

– Perform appropriate action to reach a state where power transmission is allowed.

• Test Case

– Initiate power transmission from Station A to Station B with a spec- ified power order (in MW) and ramp speed (i.e. the rate of change, in MW/min).

– Wait until power ramp completes and the current power transmission level is same as the set level.

– Reverse the power direction and initiate power transmission from Station B to Station A.

(40)

• Restoration

– Stop power transmission

– Restore the system into same state as the beginning of the test.

3.3 Communication Interfaces

When creating an automation test tool, the tool needs to interface with the system being tested. Most types of interfaces can be can be categorised either as graphical user interfaces (GUI) or command line interfaces (CLI). GUI are often more user friendly when a human is supposed to work with the system.

CLI on the other hand are (often) less user friendly for humans, but are better suited for a programmatical approach.

For this thesis project, there are several alternatives for how an automation tool may interface with the MACH main computers. Some alternatives use CLI, but may require usage of proprietary protocols, others use GUI. Three different alternatives were analysed; one GUI approach which is known as Record &

Playback, two independent CLI approaches which uses the SuiteLink protocol and theHiBug protocol respectively.

3.3.1 Record & Playback

A record & playback tool records the actions performed on the GUI by an operator during a test run and saves the actions in a script [3]. The script can later be played and the actions are executed in the same order as when they were recorded [33]. Record & replay tools are an easy way of creating throwaway test cases [34], however, if the GUI is modified there is a risk that the playback will not work since the layout is not longer the expected one [33]. Consequently, there is a need to edit or re-record the test cases in order to make them work again, which is neither easy nor cost effective [3].

Record & playback was considered to have potential for usage as the interface against the MACH main computer. However, since there is diversity in the graphical user interfaces between different HVDC projects it would be necessary to make a new test tool for every project. If the testing scripts are created in the early stages of FST, there is a risk for the scripts becoming obsolete when something in the HMI is changed during the course of testing. With these facts under consideration, record & replay was only considered as a last solution as an interface in this thesis project.

3.3.2 SuiteLink

The HMI interface used in the SCM system is built using Wonderware InTouch, which communicates with the MACH main computers using a proprietary protocol known as SuiteLink. The SuiteLink protocol communicates over the SCM

(41)

LAN network using a TCP/IP based protocol [35]. The main advantage of using SuiteLink is the possibility of executing symbols (such as analog or digital order). As no detailed description nor any libraries for SuiteLink were available during the thesis project, usage of this protocol would have required a depen- dency on a 3rd party vendor, Wonderware. Hence, we decided to look for other alternatives, while keeping SuiteLink as a backup alternative.

3.3.3 HiBug & Windows Communication Foundation

As stated above in Section 2.5.1.2, HiBug is a graphical debugger which can be used to debug HiDraw code running on the main computers. HiBug used in the MACH platform uses a proprietary protocol based on WCF (Windows Communication Foundation) for communication between HiDraw and the main computers. The WCF communication is performed using a secure binary TCP protocol. [36]

The HiBug monitor service running on the main computer may be used both for reading the real-time values of the signals in the running code as well as writing/changing subject values. HiBug can also use a serial connection for communication with the main computers [36], but this option was not considered in this thesis project as the communication today and in future will be over TCP/IP network (SCM LAN). The main disadvantage of using HiBug is that it just reads and writes to signals, and can not execute symbols in HiDraw in the same way HMI does (compare SuiteLink in Section3.3.2).

3.3.3.1 FSTSettings

FSTSettings is a tool created inhouse at ABB, to quickly change values of signals in the MACH system. Often there is some equipment (such as auxiliary power or air condition) which is not simulated during FST, but which is a requirement for the converter station to function. If systems are not sending the correct signals, the rest of the converter may initiate protective actions. To circumvent this, FSTSettings is used to manually set the missing signal values.

FSTSettings uses HiBug (and WCF) for communication with the MACH main computers. The input to the FSTSettings application is a text file which defines which signals to read or to write, being able to combine signals over different main computers and applications in each run. In the beginning of this thesis project, before other options were discovered, FSTSettings was used for communication and sending commands to the main computer. The advantage of using FSTSettings is that the utility is known by the testers and is actively used. The utility is actively maintained by ABB and there is also ongoing development.

The disadvantage is that each command sent to the main computer creates lots of overhead, both in terms of network traffic as well as execution time.

Automated Testing of HVDC Control & Protection Systems: A study on Automated Regression Testing

Examensarbete 30 hp Juni 2018

Automated Testing of HVDC Control & Protection systems

A Study on Automated Regression Testing

Hampus Halvarsson

Automated Testing of HVDC Control & Protection Systems

Hampus Halvarsson

Popular Scientific Summary in Swedish

Executive Summary

Foreword

Table of Contents

List of Figures

List of Tables

List of Code Listings

Abbreviations and Definitions

1 Introduction

1.1 Statement of Originality

1.2 Setting

1.3 Project Purpose and Goal

1.4 Scope

1.5 Delimitations

2 Background

2.1 Systems Development Life Cycle

2.2 Software Testing Process

2.3 HVDC Systems

2.4 MACH

2.5 Control & Protection Systems Development

3 Design & Implementation

3.1 Assessing Inspection and Test Instructions (ITI)

3.2 Concept Demo Test Case

3.3 Communication Interfaces