IT 20 022
Examensarbete 30 hp Maj 2020
Test Automation for HVDC System Protection
A Proof of Concept for ABB Jose Luis Ruiz Yuncosa
Institutionen för informationsteknologi
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
Abstract
Test Automation for HVDC System Protection
Jose Luis Ruiz Yuncosa
When a software is designed, one of the most critical aspects of the process is the verification. In most cases, this operation can be time consuming, which is why it is always needed to speed up the process by the use of automated tools to perform the task.
ABB Power Grids Division uses a large software for monitoring the HVDC system, which is one of the high voltage power transmission systems they offer. This control and protection software is called MACH3, and it is created in a graphical programming development environment called HiDraw, which is proprietary to the company.
HiDraw allows to design the code by using graphical blocks, which receive data as inputs, processes it and produces results at their outputs. Some critical functions of the software are presented in the form of individual graphical blocks, and during the software
development they may need to be verified. Since some of these blocks can have a quite large amount of inputs and outputs, the verification process is lengthy, and hence, the company is looking for ways to automate it.
This project shows the design details of two tester modules created in the HiDraw graphical programming environment to perform the verification of two blocks used inside the MACH3 control and protection software. It is initially presented the characterization made for the logical behaviour of the two blocks to be verified, which was done by using Signal Temporal Logic (STL) language.
Following, it is presented the two tester modules created in the HiDraw environment, which assess all the requirements previously defined in STL for the two blocks under test. This assessment is done by means of a predefined set of inputs that the testers feed to the blocks under test, and by verifying whether their outputs satisfy the requirements or not. The testers automatically run the set of test inputs in sequence, and produce outputs indicating if the tests have been passed or not. The implementation of this kind of testers can reduce the time invested by the ABB personnel on performing regression tests that are usually done manually. The proposed testers are incorporated as part of the MACH3 system, and run on its embedded computers.
It is also presented the alternatives that were considered for automating the verification and the decision process that took place to choose the presented alternative.
IT 20 022
Examinator: Phillipp Rummer Ämnesgranskare: Bengt Jonsson Handledare: Jonas Wide
Dedicated to my loving supporting Family
Contents
Part I: Introduction 9
1 Introduction 11
1.1 Project Objectives . . . 11
1.2 Outline of the Report . . . 12
2 Background 13 2.1 Active and Reactive Power . . . 13
2.2 High Voltage Direct Current Power Transmission . . . 13
2.3 MACH3 Control and Protection System . . . 15
2.3.1 Control Functions . . . 15
2.3.2 Protection Functions . . . 16
2.3.3 PS700 Main Computer . . . 17
2.3.4 PS935 DSP Computer . . . 17
2.3.5 HiDraw Studio Graphical Programming Environment . . . 17
2.3.6 Factory System Test (FST) . . . 20
2.3.7 Protection Symbol Blocks in HiDraw . . . 21
2.4 Software Checking . . . 22
2.4.1 Software Testing . . . 23
2.4.2 Software Model Checking . . . 24
2.5 Formal Requirement Specification Languages . . . 24
2.5.1 Signal Temporal Logic . . . 24
Part II: The Project 27
3 Project Requirements 29 3.1 Protection Module DVP112 Requirements . . . 293.1.1 Alarm Voltage Level Functionalities . . . 29
3.1.2 Alarm Timing Functionalities . . . 30
3.1.3 Miscellaneous Logic Functionalities . . . 31
3.2 Protection Module AVP110 Requirements . . . 31
3.2.1 Alarm Voltage Level Functionalities . . . 32
3.2.2 Alarm Timing Functionalities . . . 33
4 Project Design 35 4.1 Project Development Options . . . 35
4.1.1 KLEE Tester . . . 35
4.1.2 HiDraw Tester . . . 36
4.1.3 Project Design Decision . . . 36
4.2 Design of the Tester Programs . . . 36
4.3 Common Sections in the Tester Programs . . . 36
4.3.1 Test Type 1: Signal Activation Level . . . 37
4.3.2 Test Type 2: Signal Deactivation Level . . . 37
4.3.3 Test Type 3: Signal Activation Time . . . 37
4.3.4 Test Type 4: Signal Deactivation Time . . . 38
4.4 DVP112 Tester Design . . . 38
4.4.1 Test A Subtask - Fire Level ON . . . 40
4.4.2 Test B Subtask - Fire Level OFF . . . 42
4.4.3 Test C Subtask - Trip Time ON . . . 42
4.4.4 Test D Subtask - Trip Time OFF . . . 43
4.4.5 Test E Subtask - General Trip ON . . . 44
4.4.6 Test F Subtask - General Trip OFF . . . 45
4.4.7 Test G Subtask - SS Time ON . . . 46
4.4.8 Test H Subtask - SS Time OFF . . . 47
4.4.9 Test I Subtask - Enable ON/OFF . . . 47
4.5 AVP110 Tester Design . . . 47
4.5.1 Test A Subtask - Start Level ON . . . 49
4.5.2 Test B Subtask - Start Level OFF . . . 50
4.5.3 Tests C and D Subtasks - Trip Time ON (Fundamental and Harmonics) . . 51
4.5.4 Tests E and F Subtasks - Trip Time OFF (Fundamental and Harmonics) . . 52
4.6 Design Performance and Additional Considerations . . . 54
Part III: Conclusions 57
5 Conclusions 59
6 Future Work 60
List of Figures
2.1 Basic ABB’s HVDC Light System Diagram. [2] . . . 14
2.2 IGBT element constituting the Valve. [2] . . . 14
2.3 MACH 3 System Overview. [6] . . . 16
2.4 PS700 Main Computer. [6] . . . 18
2.5 PS935 DSP Computer. [6] . . . 18
2.6 Detail of symbol blocks and lines forming a HiDraw drawing. . . 19
2.7 MACH3 System under test in FST Lab. [1] . . . 21
2.8 Representation of Block Symbol for AVP110 Protection. . . 22
2.9 Representation of Block Symbol for DVP112 Protection. . . 23
3.1 Internal alarms generated by AVP110 module. . . 32
4.1 Type 1 test signal. . . 37
4.2 Type 2 test signal. . . 38
4.3 Type 3 test signal. . . 38
4.4 Type 4 test signal. . . 39
4.5 Original Setup of DVP112 Module in HiDraw schematic. . . 39
4.6 Proposed Setup of DVP112 Module and Tester in HiDraw schematic. . . 40
4.7 Internal Diagram of DVP112 Module Tester. . . 41
4.8 Block Diagram of Test A section. . . 41
4.9 Test signal created by the Test A section. . . 41
4.10 Block Diagram of Test B section. . . 42
4.11 Test signal created by the Test B section. . . 42
4.12 Block Diagram of Test C section. . . 43
4.13 Test signal created by the Test C section. . . 43
4.14 Block Diagram of Test D section. . . 44
4.15 Test signal created by the Test D section. . . 44
4.16 Signals created by the Test E section. . . 45
4.17 Block Diagram of Test E section. . . 45
4.18 Signals created by the Test F section. . . 46
4.19 Signal created by the Test G section. . . 46
4.20 Signal created by the Test H section. . . 47
4.21 Signals created by the Test I section. . . 48
4.22 Block Diagram of Test I section. . . 48
4.23 Placement of the AVP110 module in the MACH3 application. . . 48
4.24 Placement of the AVP110 Tester in the MACH3 application. . . 49
4.25 Block Diagram of the AVP110 Tester. . . 49
4.26 Generated Test Signal at the Test A section. . . 50
4.27 Block Diagram of the Test A section. . . 50
4.28 Generated Test Signal at the Test B section. . . 51
4.29 Block Diagram of the Test B section. . . 51
4.30 Block Diagram of the Test C and D section. . . 53
4.31 Generated Test Signal at the Test C and D section. . . 53
4.32 Block Diagram of the Test E and F section. . . 54
4.33 Generated Test Signal at the Test E and F section. . . 54
List of Acronyms
AC Alternate Current DC Direct Current
DSP Digital Signal Processing FPGA Field Programable Gate Array FST Factory System Test
IGBT Insulated Gate Bipolar Transistor HMI Human Machine Interface HVDC High Voltage Direct Current
IDE Integrated Development Enviroment LAN Local Area Network
MACH3 Modular Advanced Control for HVDC - Generation 3 OV Over Voltage
OVF Over Voltage Fundamental AC OVH Over Voltage Harmonics AC PCI Peripheral Component Interconnect SCADA Supervisory Control and Data Acquisition SCM System Control Monitor
STL Signal Temporal Logic RTDS Real Time Digital Simulator UVF Under Voltage Fundamental AC
Part I:
Introduction
The two following chapters will present the basic motivation for the project, as well as some necessary theoretical background for its understanding.
1. Introduction
One of the building blocks in our modern infrastructure is the electrical power generation and transmission system. This structure has evolved to such levels of reliability, that sometimes it makes us forget that it is even there. But the level of efficiency achieved by the power grid is the result of years of development and refinement of complex systems used for the power conversion, transmission, as well as the necessary supervision and control systems. Among the companies pushing the boundaries of what can be achieved in this field is ABB’s Power Grids division. And one of the most versatile systems they have to offer is the High Voltage DC (HVDC) power trans- mission system. This is a highly complex structure that relies on an automated system performing all the necessary control tasks. This control system created at ABB is called Modular Advanced Control for HVDC (MACH3). The system is developed at ABB using a graphical software pro- gramming tool called HiDraw. In HiDraw, the different tasks performed by the control system appear as graphical functional blocks, which can be modified and interconnected according to the specific project design needs. When the software is modified, different tests must be done to ensure that the software is still performing in the expected way (regression tests). These tests in- volve a high amount of manual labor to give the system under test different inputs and verifying if some key outputs are still valid. When multiple modifications are needed, the time invested in the tests can build up considerably, which can have an impact in the ability to meet the tight deadlines usually set for most projects. If some of the verification tasks can be automated, a benefit in terms of time saving can be achieved.
1.1 Project Objectives
This project is focused on two HiDraw graphical blocks used in the MACH3 system. These blocks are named AVP110 and DVP112. The blocks are essentially pieces of code that perform some actions and generate specific signals at their outputs according to the values of the signals at their inputs. Since the amount of outputs can be specially large, their testing can be time consuming.
The purpose of this project is to find an optimal way to automatically test the functionalities of the AVP110 and DVP112 blocks. The specific objectives of this project are:
• Formally define the requirements that need to be tested in the AVP110 and DVP112 blocks,
• Create a program that can automatically test the requirements of the AVP110 and DVP112 blocks by using predefined inputs and an oracle, and
• Assess the performance of the chosen solution for the automated testing in terms of accuracy and applicability.
The project requires the use of a formal language to clearly define the features that need to be tested in both AVP110 and DVP112 blocks, and later translate them into the implemented testing software. It must be studied different approaches and tools to achieve the automated testing of the aforementioned blocks, considering not only the performance of the selected solution, but also how easily it can be incorporated in the everyday design work of the team creating the MACH3 system. The tester program must be able to offer information of which requirements are met and which are not, and in the last case, it must also give additional information of why the requirement was not met, which can later help in the debugging process.
It is necessary to produce a working solution for blocks testing automation, however, the solu- tion is a proof of concept to show how the automated testing can be done, hence not all the block’s features need to be addressed.
1.2 Outline of the Report
Chapter 2 presents the background of the project, which includes an overview of the ABB’s con- trol system used in DC power transmission systems, the programming environment where it is developed (HiDraw), and the blocks to be tested. It is also presented the basic concepts of the Signal Temporal Logic (STL) language, which was used to express the different properties to be checked in the blocks under test.
Chapter 3 shows the creation of the formal requirements to be tested in the two protection blocks, which were described using the STL language. Chapter 4 presents the implementation of the tester programs which were created in the HiDraw environment.
2. Background
Traditionally, electrical power has been generated and transmitted in the Alternate Current form (AC). The reasons for this are diverse, including the fact that power generators operate in AC and the convenience of using power transformers to step up and down voltage levels according to the power grid design needs. But when it comes to transmitting power in a big scale, Direct Current (DC) is a valid alternative, in many cases offering advantages over its AC counterpart.
2.1 Active and Reactive Power
In the AC power transmission, the portion of the power that results in a net transfer of energy from the source to the load is called Active Power. Some elements in the power transmission circuit can have energy storage properties (acting as capacitors or inductors) which can create an oscillating power in the transmission line with each cycle of the AC. This is called Reactive Power. A generalization for describing the active and reactive power is given by Budeanu [9], starting from a harmonic decomposition of the voltage and current, being the active power
PA=
∑
k
UkIkcos(φk) (2.1)
with Uk and Ik denoting the rms value of the k-th harmonic component of the voltage and the current, respectively, and φkdenoting the phase difference between the k-th harmonic component of the voltage and the current. In the same manner, the reactive power is defined as
QB=
∑
k
UkIksin(φk) (2.2)
2.2 High Voltage Direct Current Power Transmission
High Voltage Direct Current power transmission (HVDC) was first developed in the 1930 by ASEA, the Swedish electrical company preceding ABB [2], being the world’s first commercial power link the one between Gotland Island and mainland Swedish. After that, many projects in medium and large scale has been implemented around the world, usually involving interconnec- tion between existing AC power grids. A typical HVDC system will include two main elements:
The converter station and the power line.
Converter Station
HVDC systems usually operate in conjunction with existing AC power grids. As a consequence of that, an element is needed to convert the power from AC to DC form and back. In ABB’s systems, the converter station is the one responsible of performing the two conversion functions:
the rectification, bringing power from AC to DC form, and the inversion, which translates power from DC to AC. The HVDC Light system allows to use the same hardware for inversion and rectification, thus allowing an easy current flow reversal if needed. Among the elements in a converter station, they are found transformers for the AC side coupling, filtering elements and the valve array. Figure 2.1 shows the basic diagram of a the HVDC Light system showing the converter station basic functionalities.
The core element in the converter station is the electrical valve, which is a controllable switch that links the AC and DC portions of the system. ABB uses two different valve technologies.
Phase reactor
Harmonic filter Valve IGBT & diode
DC
Transformer
DC
DC
Figure 2.1.Basic ABB’s HVDC Light System Diagram. [2]
One of them is called HVDC Classic and it is based on tyristor switches, while the most recent is called HVDC Light and it is based on Insulated-Gate Bipolar Transistor (IGBT) switches. Figure 2.2 shows the IGBT switching semiconductor element. An array of these elements is needed to form a valve. Overseeing the converter station, there is a control and protection system, which will be further discussed below.
Figure 2.2.IGBT element constituting the Valve. [2]
Power Line
The power line is the element transmitting the power, and it usually takes the form of either cables or overhead power lines. When it comes to cables, two main types are used: Those designed to be used in land and those designed to be use in undersea environments. DC cables are usually more efficient than AC cables when transmitting high power, specially at long distances, the reason being that AC cables must be rated for the capacitive charging current in addition to the active power being transmitted. Since the capacitive charging current is proportional to the cable length and the AC voltage, over long distances there is no capacity left for the active power transmission. DC overhead power lines can be built in the same way as traditional AC power lines are constructed, and as in DC power cables, the absence of reactive current offers an increased efficiency, which is about 50% over a similar AC line.
There are several advantages of DC over AC power transmission, which make HVDC systems more suitable in many circumstances. The superior efficiency when DC transmission lines are compared to AC lines is one of the most important. Greater efficiency means more transmit-
ted power, but also less land needed for a given amount of transmitted power (when comparing overhead power lines). DC transmission generates less audible noise, and produces less electro- magnetic fields which generates less radio interference. On the other hand, HVDC is ideal for interconnecting independent AC power grids, hence its use as mean of electrical interconnection between countries. The easy current direction reversal means that power can be transferred from one power grid to another and back according to the power demand and generation availability. It is also easier to connect distributed power sources into the main power grid, which makes HVDC an excellent choice for adding renewal energy (such as wind and solar generation) to existing power grids.
2.3 MACH3 Control and Protection System
In order to properly control the HVDC power transmission system, ABB has developed a complex control and protection system called Modular Advanced Control for HVDC, which is now in its third generation (MACH3). The system is designed under redundancy, containing elements that are duplicated and acting in parallel. Figure 2.3 shows the basic layout of the system. The core of the design consists in two systems, named A and B, which are always working in parallel. These systems perform the control and protection functions using separate computers for that purpose, each system having one computer for the control portion and another one for the protection. Both computers are identical in hardware, using the ABB’s PS700 computer. Each PS700 computer is connected, via PCI bus, to an ABB’s PS935 computer, which serves as an interface to the different sensors and actuators (shown at the bottom of figure 2.3). The connection to these sensors and actuators is made using a combination of industry standard EtherCAT bus, as well as ABB’s pro- prietary bus, using either optical fiber or electrical connections, depending on the sensor/actuator.
All the PS700 control and protection computers are interconnected via a dedicated control LAN.
This setup can be seen at bottom right of Figure 2.3.
The other part of the system consists of another set of computers used as user interface for operators, and some background functions. All computers in this section are also ABB’s PS700, and they are interlinked using a second LAN named station monitoring LAN (shown at the middle of figure 2.3). The main purpose of this part of the system is to provide the Human Machine Interface (HMI). The HMI is implemented using two PS700 computers. One of them is called the operator workstation aimed to serve as the main Supervisory Control and Data Acquisition (SCADA) interface, where the overall status of the system can be monitored and basic commands can be issued. The second computer is called the engineering workstation, serving the purpose of setting up more advanced parameters, as well as managing critical aspects such as software updates to the entire system. Some additional computers, named System Control Monitor (SCM) are used as servers for the two systems, hosting some specialized code needed during updates.
Some additional computers are used as gateway computers to manage some remote access and monitoring services offered as part of the MACH3 capabilities. All these computers are shown at the top of Figure 2.3.
2.3.1 Control Functions
The MACH3 Control Functions are aimed to provide full government over the HVDC power transmission system. This part of the system receives commands and parameters from the op- erators via the HMI, as well as data from multiple external sensors to provide regulation of the multiple variables of the system. Two PS700 computers operate in parallel, one of them being in activestate and the other one in hot standby state. At any given point, only one computer is in active state, controlling the system, while the other one in hot standby state is also running the same code and generating the same control signals, but its outputs are disabled. If a failure is de- tected in the active system, the standby system automatically takes over control and becomes the active system. The internal supervision generating this switchover includes program execution
LAN: Local area network SCM: Station control and monitoring
Dispatch center communications DNP 3.0
IEC 60870-5-104
Operator workstations
ABB Ability edge gateway
Fiber optic fieldbuses
Station monitoring LAN
Fiber optic fieldbuses Engineering
workstations
Gateway
SCM A server
SCM B server Remote control from
regional dispatch center ABB Ability cloud
Telecommunication to other stations
System A
System B
Protection Control Control Protection Protection
A
Control LAN
Protection B
Figure 2.3. MACH 3 System Overview. [6]
supervision (stall), communication supervision, hardware and auxiliary power supervision, and memory testing.
There are several control functions performed by the system, the most important being:
• DC Voltage Control: Makes the maximum DC voltage in the system to track a reference setting via a feedback control.
• Active Power Control: This is the actual active power being transmitted over the HVDC link. This parameter responds to a power setting defined by the operator, and it can define not only the amount of power being sent, but also the power direction.
• Reactive Power Control: The HVDC converter can either generate or consume reactive power at each control station, according to the parameters set by the operator. The active and reactive power are controlled to ramp in a smooth way to the desired value.
• AC Voltage Control: The operator can set the AC voltage, as well as the ramp speed.
• AC Current Control: The current control includes the regulation of the active current as well as the reactive current. These controls are not accessible by the operators.
• Tap Changer Control: This function controls the stepping of the transformer tap changer.
The purpose is to keep the relationship between AC and DC voltage within specified ranges.
2.3.2 Protection Functions
The protection computers are constantly monitoring multiple variables to decide whether the sys- tem is working properly or not. This information is coming from sensor data, usually obtained via the PS935 interface. The monitoring covers the full extent of the system, including the AC por- tion, the converter elements and the DC portion. Some of the most important protection functions are the AC overcurrent and overvoltage, ground connection faults, converter overvoltage and over- current, valve short circuit, valve cooling, DC overvoltage, DC poles unbalance, DC cable fault, among others. These functions are highly customized with multiple parameters and reference values that are fine tuned for every particular implementation of the HVDC system.
The two PS700 computers performing the protection functions are working in parallel in a redundant configuration. This means, the outputs of both computers are constantly active, so both are able to generate the signals required to activate the protection elements of the system. The ultimate purpose of the protection is to disconnect different elements from the electrical system in the event of a fault. This is done by the use of electrical breakers that can disconnect portions of the AC or DC networks from the converters on command. Different faults can generate different actions, according to their severity. The most relevant are:
• Alarms: Alarms will appear as a notification to the operator in the HMI, but the system will continue its normal operation.
• Temporary Blocking: In the event of high current or voltage in the converter, the IGBTs can be temporary shut down, resuming normal operation once the faulty values are back to normal.
• Permanent Blocking: As in the temporary blocking, the IGBTs are shut down, but in this case, the action will always be followed by a tripping of the AC breakers.
• AC circuit breaker trip: The tripping of the AC breakers disconnects portions of the AC network from the converter section. The AC breakers are built with redundancy on its activation.
• AC circuit breaker lockout: In some cases, in addition to the AC breaker trip, a lock order can be sent, in order to prevent the breaker from being closed before the failure is investi- gated.
• Pole Isolation: This sequence disconnects the DC side of the converter (positive and nega- tive poles) from the DC cable.
2.3.3 PS700 Main Computer
The PS700 computer is the latest main computer for the MACH3 system. The computer is a 64 bit multicore processor running INtime for Windows as the real time operating system. To ensure long life and and stable operation, the computer is passively cooled, so there are no fans or air filters that need to be replaced. This is possible thanks to the high energy efficiency of the equipment [4]. The computer is connected to other parts of the MACH3 system using Ethernet and PCI links. Several units are used in a single MACH3 system, and they can serve specific functions as control, protection, external communications, HMI and server. Figure 2.4 shows the PS700 computer.
2.3.4 PS935 DSP Computer
The PS935 computer is a dedicated module aimed to process data received from external sensors in the system. Data can be diverse in nature, such as voltages, currents and temperatures. De- pending on the case, data is pre-processed in this module before it is sent to a PS700 computer via PCI link. The module uses 8 Digital Signal Processor (DSP) floating point cores, along with some Field Programmable Gate Arrays (FPGA). The execution of the software in the 8 DSP cores run synchronized on the same interrupt at 10 µs execution time [4]. Thanks to its energy efficiency, the module is passively cooled. The links between the PS935 and the sensors are mostly based on fiber optics, but some of them are also based on cooper wires. Figure 2.5 shows the PS935 computer.
2.3.5 HiDraw Studio Graphical Programming Environment
Since the MACH3 system is formed by different computers using different kind of processors, a graphical Integrated Development Environment (IDE) called HiDraw was created, to allow the en- tire hardware to be programmed in the same platform. HiDraw is a fully graphical block program- ming language [11], able to generate a high level or assembly language code from the schematic
Figure 2.4. PS700 Main Computer. [6]
Figure 2.5.PS935 DSP Computer. [6]
drawings created by the user. The graphical code can also serve as an accurate documentation which describes the system and can later be reviewed by the user or other parties. HiDraw is a proprietary tool developed by ABB, and it is used not only in the MACH3 system design, but also in other applications across the company.
A HiDraw program is presented as a series of schematics called drawings, each one contain- ing different function blocks called symbols, and the lines interconnecting them. In general, each symbol has inputs, outputs and parameter values (which can be individually tuned for each in- stance of the symbol). Lines are used to interconnect a symbol’s output to one or more inputs in other symbols. The lines are similar to variables in a programming language, and as such, it is possible to define its type in the drawing (such as Boolean, integer, float, among others). It is also possible to create bus lines, which may contain several instances of a basic type of line, bundled together in a single entity. When a line is drawn, HiDraw assigns a name which is correlated to the name of the drawing containing it. This ensures that there are no conflicts due to recurrent
names. It is possible for the user to change those names though, for better understanding of the drawing.
The symbol blocks, on the other hand, can be seen as functions in a programming language, as they can perform diverse calculations over the input data, and present the result at the output.
Symbol capabilities are broad, from basic arithmetic to complex algorithms specific for control and protection functions. Some symbol blocks can perform functions related to specific hardware features, such as sending data between different computers using specific physical buses.
During the program creation, the developer has a predefined set of symbols to be used, grouped into libraries. Libraries are unique for each type of computer processor available on the MACH3 system hardware, and as a consequence of that, not all symbols can be used when creating a drawing, but only those that can be later compiled for the desired computer type. HiDraw symbols differ if they are intended to be used in different processors, even if they perform similar functions.
The creation of a drawing is based on the simple point, click and drag method. The user combines and connects symbols blocks from a symbol library to a schematic [11]. The user can create custom symbols blocks, named components, by combining existing symbols, and add them to an existing or new user-defined library. The internal functioning of a component is described by one or more drawings. It is also possible to create components inside components.
Figure 2.6 shows a basic example of how a HiDraw drawing looks like. The symbols at the left represent the inputs of the drawing, while the lines represent boolean variables. All the lines have names, which can be shown or not in the drawing. The symbols at the center are OR logical operators, while the symbol at the right represents the output of the drawing. This example is performing a simple OR operation between the eight inputs, and the drawing is part of an user made component.
Figure 2.6.Detail of symbol blocks and lines forming a HiDraw drawing.
Types of drawing schematics and Hierarchy in HiDraw
When making a program in Hidraw, the user creates schematics that can serve different purposes, hence drawings can be defined as one of the different predefined types. The most common case is to define a single drawing as a task. Several tasks can be grouped together into an entity called application. A typical application contains several tasks, plus an overhead section (in the form of another drawing) that contains the application metadata. This metadata includes the order in which each task in the application is executed, as well as the clock timing determining how often the task is executed (in an application, some tasks can be executed at a higher pace than others).
If the size of a design is larger than what can be fit in a single drawing, additional drawings can be defined as subtasks and be associated to a task, so they behave as an extension of it, being executed at the same time, and sharing the same variables.
All the applications that form the MACH3 software are grouped together into an unit called workspace. The user can access, explore and modify the files in the workspace using a file ex- plorer section in HiDraw Studio. The workspace is shown with a hierarchy scheme, splitting the applications created for the PS700 unit (Main Computer) from those created for the PS935 unit (DSP). There are different resources in the form of symbol blocks, that can be used to share data between the different applications and across the different computers that form the MACH3 system.
Code Compilation and Download Process
Going from the HiDraw graphic design to the final download of the code into the hardware is a two steps process.
The first step is referred as the build, which is done entirely in the HiDraw environment. In this part, the information contained in the graphical code is converted first to C++ or VHDL language (depending on the target hardware) and later compiled to the binary files specific for each hardware. Usually, all the files contained in a workspace are build together, that means, binary files for the whole hardware (PS700 and PS935 computers) are created. Nevertheless, in order to save time during the build process, it is possible to build just partial portions of the code, such as the one targeting a specific computer.
The second step involves the download of the binary files to the target hardware. This is ac- complished by using a software tool named McFeeder. This tool manages all the possible files available for download to the different computers that comprises the MACH3 system. The down- load process is independent for each computer, so it is possible to modify the code for a single computer, download it and test the result without re-downloading the code to the rest of the hard- ware.
HiBug
Once the desired code is downloaded to the hardware, the debugging process can be done. To perform this, HiDraw offers a tool called HiBug. HiBug is a a fully graphical debugger embedded into HiDraw Studio, that allows to link the graphical code shown on the screen to the code that is actually running on the MACH3 hardware. In that way, the user can watch in real time the values of any variable in the code (that means, the values of the data in every line in the drawing) as numbers printed over the lines. In some cases, HiBug also allows the user to change the variable’s values in real time, via a dialogue box. The fact that HiBug allows inspection while the application is up and running makes it a convenient maintenance tool as well.
2.3.6 Factory System Test (FST)
MACH3 is a highly customized system, not only because its design is adapted to the power grid architecture where it is installed, but also because customers can ask for specific requirements to be met. Testing the performance of the MACH3 system to ensure that it is compliant with the requirements is one of the key aspects of the overall system design procedure. All systems have to pass a series of tests before being shipped to the final user, this being known as the Factory System Test (FST), which is performed at a dedicated lab inside ABB Power Grids HVDC division.
It is not possible to have in the lab the same transformers and breakers used in a real power grid, operating at the real power levels (which can be in the order of gigawatts), therefore simulators are used to recreate the behaviour of a real power grid and to determine how the MACH3 control and protection features will work. The most common simulator used is known as Real Time Digital Simulator (RTDS). During tests, the MACH3 system sends control signals to the simulator, which sends back simulated signals that represent data that would be acquired by different sensors in the real system. The tests performed during FST are diverse, but they can be separated in two kinds:
Those aimed to control functions and those aimed to protection functions. In the first case, the MACH3 system sends control signals to the simulator (usually triggered by operator’s inputs at the HMI) to keep simulated variables within the expected range. In the second kind, the simulator itself introduces anomalies in the simulated data sent to the MACH3, and this in turn has to respond according to the programmed behaviour. Another important aspect addressed during the FST is the customization of the HMI, since customer needs may introduce changes on the design.
The FST includes verification of functions, for which testing on site is not feasible [11]. Figure 2.7 shows part of a MACH3 system under test at FST lab.
The FST makes it possible to shorten the commissioning time of the system and to improve the quality of the design. During the FST, the control and protection modules are energized and kept in continuous operation for a couple of months [11].
Figure 2.7.MACH3 System under test in FST Lab. [1]
2.3.7 Protection Symbol Blocks in HiDraw
HiDraw Studio contains symbol libraries created for the PS700 and PS935 computers. Some of these block symbols carry out basic generic functions, but some of them are aimed to perform specific functions inside the MACH3 system. Two of the multiple symbols available for the protection functions are the DVP110 and AVP112. These blocks are intended to monitor voltage levels at the power grid lines and generate alarms if values are out of range. The generated alarms can have several uses, from showing alerts to the operator on the MACH3 HMI, to automatically disconnect portions of the physical circuits.
AVP110 Protection Module
The AVP110 protection module is a symbol block available for use in the PS700 main computer.
The module compares AC voltage signals to predefined reference levels to generate different alarms if the levels are surpassed. The AVP110 symbol block is a large module that contains over 70 inputs and outputs but for the purpose of this thesis, only those relevant to the performed work will be described. The symbol block is built out of multiple HiDraw drawings, which can be viewed by the user. A simplified representation of the module will be used, as shown in Figure 2.8.
The most important block’s input signals are the Fund_U and Harm_U, which represent the fundamental AC and full AC harmonics components respectively. The AVP110 module compares each of these signals to the four Reference voltage level inputs. If an input exceeds and stays above a reference level, the first Trip1 output will activate after a time given by the corresponding Time Delayinput. If the input remains above the reference, the output Trip2 will activate after a 2x Time Delay delay. The sequence continues for Trip3 and Trip4 activating after 3x and 4x the time delay, respectively. If at any moment the input goes below the exceeded reference, all the four trip signals will deactivate, after a time given by the input Hold Time has elapsed. These four steps are referred to as stages.
There are a total of eight Reference inputs (four for the AC fundamental and four for the AC full harmonics comparisons), each one having a corresponding Time Delay and Hold Time. Each one of these sets is called a level.
In addition to the trip signals, the AVP110 module offers eight outputs named Start. There are four start signals for the AC fundamental voltage monitoring, and four for the full harmonics AC monitoring, each one associated to a level. As soon as an input surpasses a reference, the corresponding start output activates, and it deactivates when the input falls below the reference.
The AVP110 module has multiple inputs that can inhibit the trip outputs, but for the purpose of this project, they are collectively addressed as a single Enable input.
AVP110
Fund_U Harm_U
Reference_F1 Reference_F2 Reference_F3 Reference_F4
Reference_H1 Reference_H2 Reference_H3 Reference_H4
Hold_Time_F1 Hold_Time_F2 Hold_Time_F3 Hold_Time_F4
Hold_Time_H1 Hold_Time_H2 Hold_Time_H3 Hold_Time_H4
Time_Delay_F1 Time_Delay_F2 Time_Delay_F3 Time_Delay_F4
Time_Delay_H1 Time_Delay_H2 Time_Delay_H3 Time_Delay_H4 Enable
Trip_1 Trip_2 Trip_3 Trip_4
Start_F1 Start_F2 Start_F3 Start_F4
Start_H1 Start_H2 Start_H3 Start_H4
Figure 2.8.Representation of Block Symbol for AVP110 Protection.
DVP112 Protection Module
The DVP112 protection module is a HiDraw symbol block used to monitor DC voltage lines, and to generate alarms if some reference values are exceeded. The module is created to be used in the PS935 computer in the MACH3 system. For the purpose of this work, the module will be represented as in figure 2.9, with inputs at the left and outputs at the right.
The input Udc represents the monitored DC voltage. This signal is compared to four different reference voltage values, designated as levels, and then it is assessed whether the input signal is above those levels or not.
The reference levels are brought to the module as four inputs named Ref. Correspondingly, there are four outputs named Trip that are activated when each reference level is surpassed by the input Udc. The trip signals become active once Udc is above the corresponding reference level for a lapse given by the input Dly (delay). There are 3 of such delay inputs, corresponding to the levels 1, 2 and 3. Level 4 has no delay signal, so its related trip output should become active as soon as the reference level is exceeded.
When Udc goes below a reference level, the corresponding trip output has to become inactive again. In the levels 2, 3 and 4, the trip signal goes inactive instantaneously, but in the level 1 the action is retarded. The delay time is given by the input Hld1 (hold).
The output named SS behaves in the same way as the Trip1 (using the same reference level), but the initial delay when activating is given by the input SS_Dly. The delay when de-activating is fixed at 10 µs. The Trip output is the logical OR combination of all the four trip outputs.
All the symbol’s outputs can be deactivated using the input Enable. When this input is false, all the outputs become false. The output Disabled is the negated value of the enable input.
2.4 Software Checking
A key part of a software development is the software testing. There are many different defini- tions of it, but in general they can be summarized in what is called Verification and Validation.
DVP112
Udc
Ref1 Ref2 Ref3 Ref4
Dly1 Dly2 Dly3 SS_Dly
Hld1 Enable
Trip1 Trip2 Trip3 Trip4
Fire1 Fire2 Fire3 Fire4
SS Trip Dissabled
Figure 2.9. Representation of Block Symbol for DVP112 Protection.
Verification is the process of determining whether the products of a phase of the software devel- opment process fulfill the requirements established during the previous phase, while validation is the process of evaluating software at the end of software development to ensure compliance with intended usage [3].
There are different approaches when it comes to testing the correctness of a software. The techniques vary from the traditional software testing using test cases, to the more novel model checking. The following sections show some of the more widespread techniques in use today.
2.4.1 Software Testing
The software testing in general consists of the use of different input values to execute a software system. The software system has a specification that is therefore proved correct or incorrect by observing the exhibited behaviour. In software testing, a test vector is defined as a sequence (η1, ... ηn) of n input values, from η1to ηn. A test case is defined by some preconditions in the software system, a test vector and certain expected results. A collection of test cases is called a test suite.
The software used to automatically execute the test cases in the system under test is called the test harness. The test harness supplies the test vectors one by one as inputs to the program [5]. Once a test case is finished, a part of the tester called test oracle is responsible for deciding whether the test has been passed or failed, and producing some sort of output accordingly. The test cases can be either manually created, or automated techniques can be used to create them. For the last case, among the most used techniques are random fuzz testing and the symbolic execution.
Random Fuzz Testing
According to Hicks et al. [10], a fuzz tester (or fuzzer) is a tool that iteratively and randomly creates inputs (vectors) with which it tests the target program. The term is broad, and very different models can be described as fuzzers, In general, fuzzers start by feeding the software under test with a seed input, and then this input is mutated and fed again while the software response is observed. If the response is interesting, both the input and the response are recorded. The process stops when a certain goal is achieved (either a particular response is obtained or a timeout is reached). In this context, an interesting response can also have multiple meanings, from the software crashing to the outputs not complaining with some given parameters.
Symbolic Execution Testing
Symbolic execution is an alternative to manual or random input generation to test software. The symbolic execution doesn’t run the software under test using input values, but rather converts it to a version where the inputs are symbolic and can take any value. The symbolic inputs substitute the original inputs in the program, and the operations that were made over inputs are then modified
to operate over the symbolic values. When there is a branch in the program execution, the tester follows both branches, creating a path condition that must hold on each path during the software execution. When a path reaches an end, or a bug is encountered, a test case is generated by solving all the path conditions for real values [7]. One of the symbolic execution strengths is the fact that it can ensure a higher branch coverage of the software under testing than what is achieved in manual or random input generation. This can lead to scalability problems, since in many cases the amount of paths can grow exponentially when the program becomes more complex and even become infinite. Another disadvantage of testing systems using symbolic execution is the fact that it is usually more difficult to test a code that interacts more with its surrounding environment (the user, the network or the operating system).
A commonly used tool for symbolic execution is called KLEE [7]. It was created at Stanford University, and it allows to maximize path coverage by automatically generating test cases for all possible path execution. KLEE is also able to detect a variety of bugs in the software under test.
2.4.2 Software Model Checking
Software model checking is another approach, where the objective is to explore all the possible states the program under test can enter, and then verify if any of them violates the program spec- ifications. In general, the number of states in a program can be infinite, so a principle called abstractionis used to reduce the amount of spaces to be explored. A good abstraction not only reduces the number of states, but also eliminates false alarms.
2.5 Formal Requirement Specification Languages
In the formal verification field, it is common to use formalism to express the way a system behaves over time in a declarative manner. It can be specified which sequences of states and events fulfill the requirements of the designer in terms of functionality and which behaviours do not. These specifications can be later translated into a program that monitors the behaviour of the system and decides if the requirements are met. Among these formalisms, regular expressions and temporal logicare frequently used.
2.5.1 Signal Temporal Logic
Signal Temporal Logic (STL) is one of the different languages used in temporal logic, and it can work over real-valued variables defined over discrete or continuous time. The subsequent definitions are based on the version of STL presented by E. Bartocci et al. [8].
X and P are defined as finite sets of real and propositional variables. Then it is defined w : T → RmxBnas a multi-dimensional signal, where T = [0, d) ⊆ R, m = |X| and n = |P|. Given a variable v ∈ X ∪ P, it is denoted by πv(w) the projection of w on its component v. The semantics of an STL formula contains a temporal logic expression ϕ which is time dependent, with the satisfiability relationof the form (w,t) |= ϕ indicating that the formula ϕ holds for the signal w at the time point t.
The syntax of an STL expression ϕ over X ∪ P is defined by the grammar:
ϕ := p|x ∼ c|¬ϕ |ϕ1∨ ϕ2|ϕ1UIϕ2|ϕ1SIϕ2| (2.3) where p ∈ P, x ∈ X , ∼∈ {≤, <}, c ∈ Q, and I ⊆ R+. Since the logic is interpreted over finite traces only, the satisfaction relation is only defined for t ∈ T. The different grammatical expressions in the STL language are defined as follows:
(w,t) |= p ↔ πp(w)[t] = true (w,t) |= x ∼ c ↔ πx(w)[t] ∼ c
(w,t) |= ¬ϕ ↔ (w,t) 2 ϕ
(w,t) |= ϕ1∨ ϕ2 ↔ (w,t) |= ϕ1or (w,t) |= ϕ2
(w,t) |= ϕ1UIϕ2 ↔ ∃t0∈ (t + I) ∩ T : (w,t0) |= ϕ2and ∀t00∈ (t,t0), (w,t00) |= ϕ1 (w,t) |= ϕ1SIϕ2 ↔ ∃t0∈ (t − I) ∩ T : (w,t0) |= ϕ2and ∀t00∈ (t0,t), (w,t00) |= ϕ1
The two temporal operators in the basic grammar are until (UI) and since (SI). The until is the future operator. An expression in the form ϕ1UIϕ2(ϕ1 until ϕ2) is satisfied if ϕ2 occurs at some point in the future while ϕ1 continuously hold until then. The past counterpart of the until operator is since. An expression in the form ϕ1SIϕ2 (ϕ1 since ϕ2) is satisfied if ϕ2occurred in the past and ϕ1has been holding since then.
In addition to this grammar, E. Bartocci et al. introduce additional derived operators, which can be expressed in terms of the basic grammar. Among them, it can be mentioned:
Conjunction: ϕ1∧ ϕ2 ≡ ¬(¬ϕ1∨ ¬ϕ2) Eventually: ♦Iϕ ≡ trueUIϕ
Always: Iϕ ≡ ¬♦I¬ϕ
Part II:
The Project
The two following chapters show the created project. It goes from the formal requirements that had to be defined for the symbol blocks under test, to the actual software design.
3. Project Requirements
MACH3 is a complex software in constant evolution. Changes are constantly made for multiple reasons, the most common being the tailoring of the system for a particular customer application, but also improvements can be made when a new piece of hardware is added or updated, or just to upgrade the system performance. Once changes are made, it is common to carry out regression tests, to verify that the system is still performing as required. The regression tests are usually time consuming since some of the tasks are performed manually, and consequently, it is on the ABB’s interest to study ways of automate some of the duties.
The thesis project was expected to perform tests over two of the control and protection HiDraw blocks used in the MACH3 system: The DVP112 and the AVP110. The design had to be able to prove the module functionalities and to decide whether they are working properly or not. There were no formal requirements predefined for the two modules, therefore, one of the first tasks done during the project was to define them.
3.1 Protection Module DVP112 Requirements
The DVP112 symbol block has different functions that can be individually defined. They can be grouped into three categories: Those related to alarm voltage levels, those related to alarm timings and some miscellaneous logic functions. Although more functions could be defined as require- ments for the module, these are the ones requiring attention during regression tests, therefore they need to be verified in this project.
3.1.1 Alarm Voltage Level Functionalities
The DVP112 symbol block has four Boolean output signals (Fire1, Fire2, Fire3 and Fire4) which depend on the Udc voltage input. The input Udc is compared against four references (Ref1, Ref2, Ref3and Ref4 respectively). Some comparisons use hysteresis, Fire1 has 2% hysteresis, Fire2 and Fire3 have 0.05 kV hysteresis, Fire4 has no hysteresis. Below are the requirements for the Fire signals behaviour, expressed in STL. For the Fire1 signal:
[(Udc >= Re f 1) → Fire1] (3.1)
[(Udc < 0.98 ∗ Re f 1) → ¬Fire1] (3.2)
Requirement 3.1 needs Fire1 to be always true if Udc is above the reference, while requirement 3.2 makes Fire1 always false if Udc is below the reference (including hysteresis). Analog reasoning is applied in the following requirements. For the Fire2 signal:
[(Udc >= Re f 2) → Fire2] (3.3)
[(Udc < Re f 2 − 0.05) → ¬Fire2] (3.4)
For the Fire3 signal:
[(Udc >= Re f 3) → Fire3] (3.5)
[(Udc < Re f 3 − 0.05) → ¬Fire3] (3.6) For the Fire4 signal:
[(Udc >= Re f 4) → Fire4] (3.7)
[(Udc < Re f 4) → ¬Fire4] (3.8)
3.1.2 Alarm Timing Functionalities
The four Boolean trip signals (Trip1, Trip2, Trip3 and Trip4) have analog behaviour to the fire signals, becoming true or false according to a comparison of the Udc signal to a reference value (Ref1, Ref2, Ref3 and Ref4 respectively), but they add time delays for the moment when they become true or false. The delays for becoming true are given by the Dly (delay) inputs while the delay when the trip signals become false are given by the Hld (hold) inputs. Below are the requirements of the trip signals behaviour expressed in STL. For the Trip1 signal:
[[0,Dly1](U dc >= Re f 1) → ♦[Dly1,Dly1](Trip1)] (3.9)
[♦[Hld1,Hld1](¬Trip1) → [0,Hld1](U dc < 0.98 ∗ Re f 1)] (3.10) The requirement 3.9 always needs Udc to be above the reference for the time Dly1 for Trip1 to become true, while the requirement 3.10 determines that if Trip1 is not true, Udc has been below the reference (including hysteresis) for Hld1 time. Analog reasoning applies in the following requirements. For the Trip2 signal:
[[0,Dly2](U dc >= Re f 2) → ♦[Dly2,Dly2](Trip2)] (3.11)
[♦[Hld2,Hld2](¬Trip2) → [0,Hld2](U dc < Re f 2 − 0.05)] (3.12) For the Trip3 signal:
[[0,Dly3](U dc >= Re f 3) → ♦[Dly3,Dly3](Trip3)] (3.13)
[♦[Hld3,Hld3](¬Trip3) → [0,Hld3](U dc < Re f 3 − 0.05)] (3.14) For the Trip4 signal:
[(Udc >= Re f 4) → Trip4] (3.15)
[¬Trip4 → (Udc < Re f 4)] (3.16)
The Boolean SS output is similar in behaviour as the Trip1 output, but having a different delay when becoming true (time is given by the input SS_Dly, while the delay for becoming false is given by the the input Hld1 (hold1) plus 10 ms. The overall behaviour of the signal is also conditioned by the Enable input. This can be expressed in temporal logic as:
[[0,SS_Dly]((U dc >= Re f 1) ∧ Enable) → ♦[SS_Dly,SS_Dly](SS)] (3.17)
[♦[Hld1+10ms,Hld1+10ms](¬SS) → [0,Hld1]((U dc < 0.98 ∗ Re f 1) ∧ Enable)] (3.18)
[¬Enable → ¬SS] (3.19)
3.1.3 Miscellaneous Logic Functionalities
Two additional functions of the DVP112 symbol block are considered. The first is the Trip output, which is the ORed combination of the four individual aforementioned trip signals. This signal activation is delayed by 10 ms. The signal though, is inhibited by the additional DVP112 input Enable. This behaviour can be described in STL expressions as:
[((Trip1 ∨ Trip2 ∨ Trip3 ∨ Trip4) ∧ Enable) → Trip] (3.20)
[[0,10ms]((¬Trip1 ∧ ¬Trip2 ∧ ¬Trip3 ∧ ¬Trip4) ∧ Enable) → ♦[10ms,10ms](¬Trip)] (3.21)
[¬Enable → ¬Trip] (3.22)
The last function to consider in the DVP112 symbol block is the Disable output, which is the complement of the Enable input. In STL, it is expressed as:
[Enable → Dissable] (3.23)
[¬Enable → ¬Dissable] (3.24)
3.2 Protection Module AVP110 Requirements
The AVP110 system block has multiple functions that can be defined, but for the purpose of the project, only a portion of them were considered. The AVP110 symbol block generates a set of internal alarmsbased on comparing the two AC voltage input signals (the fundamental compo- nent signal Fund_U and the full harmonics signal Harm_U) to several reference parameters. In total, twenty nine internal alarms can be generated, sixteen for the fundamental AC voltage signal and thirteen for the full harmonics AC voltage signal. An overview of these generated internal alarms can be seen in figure 3.1. The diagram at the left (figure 3.1a) shows the alarms internally generated out of the fundamental AC signal. This input signal is compared against four different voltage values (references). Each reference voltage corresponds to each one of the levels in the figure. When the input voltage signal exceeds a reference, there will be a time delay given by the Time Delayparameter, after which the corresponding alarm in the Stage 1 column will be active.
If the input remains above the reference level, the following alarm in the Stage 2 column will be active after 2xTime Delay time. The pattern continues for the Stage 3 and Stage 4 alarms. After 4xTime Delay time, the four alarms will be active (as long as the input voltage remains above the reference value). When the input voltage signal goes below a reference value, any alarm that would be active in that level becomes inactive after a time given by the Hold Time parameter.
The reference, time delay and hold time parameters are exclusive and individual for each level.
For this project, the internal alarms generated for the fundamental AC signal input are named as F_Li_Sjwhere i corresponds to the level and j corresponds to the stage.
The internal alarms generated by the full harmonics AC input are similar in nature to the pre- viously described. Again, there are four levels and four stages, but in this case, Level 4 generates one alarm only. As with the fundamental alarms, the reference, time delays and hold time param- eters are independent for each level. The upcoming description refers to these internal alarms as H_Li_Sjwhere i, where i corresponds to the level and j corresponds to the stage.
The design of this project must be able to determine if these alarms are triggering at the proper voltage references (for each level), as well as the correct timing for activation and deactivation. As in the DVP112 symbol block case, there were no formal description for the expected behaviour of this module, and consequently, a more formal definition had to be made. The descriptions cover two essential kind of features: those related to the voltage at which the alarms are activating and those describing the timing for alarms activation and deactivation.
Level 1
Level 2 Level 3
Level 4
Time Stage 1
F_L1_S1 F_L2_S1 F_L3_S1 F_L4_S1
Stage 2 F_L1_S2 F_L2_S2 F_L3_S2 F_L4_S2
Stage 3 F_L1_S3 F_L2_S3 F_L3_S3 F_L4_S3
Stage 4 F_L1_S4 F_L2_S4 F_L3_S4 F_L4_S4
1x TD 2x TD 3x TD 4x TD
(a)Alarms for Fundamental AC.
Level 1
Level 2 Level 3
Level 4
Time Stage 1
H_L1_S1 H_L2_S1 H_L3_S1 H_L4_S1
Stage 2 H_L1_S2 H_L2_S2 H_L3_S2
Stage 3 H_L1_S3 H_L2_S3 H_L3_S3
Stage 4 H_L1_S4 H_L2_S4 H_L3_S4
1x TD 2x TD 3x TD 4x TD
(b)Alarms for All Harmonics AC.
Figure 3.1.Internal alarms generated by AVP110 module.
3.2.1 Alarm Voltage Level Functionalities
There are eight output signals in the AVP110 symbol block that can be used to verify the volt- age level at which the alarms are triggered. Those signals are the Start outputs. There is one start signal per each level (four for the fundamental AC signal and four for the full harmonics AC signal). All these signals become active when the input signal become higher than the re- spective reference, and become inactive when the input signal becomes lower than the reference (accounting for hysteresis of 2%) and a delay given by the Hold Time has elapsed. The signals are also enabled by several additional signals, which might prevent them to become active. The start signals can therefore be used to assess the voltage level at which the alarms for the four level are activating and deactivating (given that the effect of the enable signals and the hold time delay can be somehow bypassed).
The requirements for the four start signals Start_Fi related to the fundamental AC input are shown below in STL language.
[((Fund_U >= Re f _Fi) ∧ Enable) → Start_Fi] (3.25)
[[0,Hld_Fi]((Fund_U < 0.98 ∗ Re f _Fi) ∧ Enable) → ♦[Hld_Fi,Hld_Fi]¬Start_Fi] (3.26)
[¬Enable → ¬Start_Fi] (3.27)
where i refers to the level (ranging from 1 to 4), variables Ref_Fi refer to the reference voltage input for the level i, Hld_Fi refers to the hold time for the level i, and the variable Enable refer to all the enable signals activating the start outputs. The requirement 3.25 states that Start_Fi will be true when Fund_U is above the reference level, while the requirement 3.26 needs Fund_U to be below the reference (accounting for hysteresis) for a time Hld_Fi in order to Start_Fi becomes false. Each start signal has four different independent enable signals that might inhibit it, but since their functioning is not covered in this project, they are collectively referred to as Enable.
The requirements for the full harmonics AC start signals Start_Hi are similar to those of the fundamental AC start signals. Below they are expressed in STL language.
[((Harm_U >= Re f _Hi) ∧ Enable) → Start_Hi] (3.28)
[0,Hld_Hi](Harm_U < 0.98 ∗ Re f _Hi) → ♦[Hld_Hi,Hld_Hi]¬Start_Hi] (3.29)
[¬Enable → ¬Start_Hi] (3.30)
where i refers to the level (ranging from 1 to 4), Ref_Hi refers to the reference voltage input for the level i, Hld_Hi refers to the hold time for the level i and Enable refers to the enable signals
activating the start outputs. As in the fundamental AC case, each start signal has four different independent enable signals that might inhibit it, and they are collectively referred as Enable.
3.2.2 Alarm Timing Functionalities
The alarm timing functionalities refer to the timing when the different internal alarms activate and deactivate. In this project, these internal alarms are named as shown in figure 3.1a for the fundamental AC alarms and in figure 3.1b for the full harmonics AC alarms. The behaviour of all the alarms can be described as activating once the corresponding voltage input surpasses the as- sociated reference voltage for that particular level for a given amount of time (defined by the time delay parameter), and deactivating when the corresponding input voltage is below the reference (with some hysteresis correction of 2%) and certain time, given by the hold time parameter, has elapsed. For each alarm, a tolerance on when it should activate is also considered, to account for the delays in the hardware response. And as with the start signals described in the previous sec- tion, all the internal alarms are also conditioned by the same previously mentioned enable signals.
All this can be summarized in the following formal requirements in STL.
In the fundamental AC section, the alarms can be described as:
[[0, j∗Dly_Fi]((Fund_U >= Re f _Fi) ∧ Enable) → ♦[ j∗Dly_Fi, j∗Dly_Fi+HD j]F_Li_S j] (3.31)
[[0,Hld_Fi](Fund_U < 0.98 ∗ Re f _Fi) → ♦[Hld_Fi,Hld_Fi+HD j]¬F_Li_S j] (3.32)
[¬Enable → ♦[0,HD j]¬F_Li_S j] (3.33)
where i is the level (ranging from 1 to 4), j is the stage (ranging from 1 to 4), F_Li_Sj is the alarm for the level i and stage j, Dly_Fi is the time delay for the level i, Hld_Fi is the hold time for the level i, Enable refers to all the enable signals for the corresponding alarm, and HDj is an extra time added to account for the hardware delay to execute the desired action for the stage j. This additional time is 15 µs for stage 1, 20 µs for stage 2, 25 µs for stage 3 and 30 µs for stage 4.
The requirement 3.31 states that if Fund_U is above the reference level for a j*Dly_Fi time, then F_Li_Sjwill be true. The requirement 3.32 states that if Fund_U is below the reference level (given a hysteresis correction) for a Hld_Fi time, then F_Li_Sj will become false.
In the same manner, the alarms for the full harmonics AC section can be described as:
[[0, j∗Dly_Hi]((Harm_U >= Re f _Hi) ∧ Enable) → ♦[ j∗Dly_Hi, j∗Dly_Hi+HD j]H_Li_S j] (3.34)
[[0,Hld_Hi](Harm_U < 0.98 ∗ Re f _Hi) → ♦[Hld_Hi,Hld_Hi+HD j]¬H_Li_S j] (3.35)
[¬Enable → ♦[0,HD j]¬H_Li_S j] (3.36)
where i is the level, j is the stage, H_Li_Sj is the alarm for the level i and stage j, Dly_Hi is the time delay for the level i, Hld_Hi is the hold time for the level i, Enable refers to all the enable signals for the alarm and HDj is the previously defined added time to account for the hardware response for each stage j.
All the previously described alarms are not available as single outputs from the AVP110, but are internal to the module. All the alarm signals from each stage are ORed into a single output signal called Trip_j where j refers to the stage. There are four trip outputs (one per each stage).
The requirements for the stage 1 trip output can be expressed in STL as:
[(F_L1_S1) ∨ (F_L2_S1) ∨ (F_L3_S1) ∨ (F_L4_S1)
∨(H_L1_S1) ∨ (H_L2_S1) ∨ (H_L3_S1) ∨ (H_L4_S1) → Trip_1] (3.37)
[¬((F_L1_S1) ∨ (F_L2_S1) ∨ (F_L3_S1) ∨ (F_L4_S1)
∨(H_L1_S1) ∨ (H_L2_S1) ∨ (H_L3_S1) ∨ (H_L4_S1)) → ¬(Trip_1)] (3.38) while the requirements for the trip signals for stages 2, 3 and 4 can be expressed as:
[(F_L1_S j) ∨ (F_L2_S j) ∨ (F_L3_S j) ∨ (F_L4_S j)
∨(H_L1_S j) ∨ (H_L2_S j) ∨ (H_L3_S j) ∨ (H_L4_S1) → Trip_ j] (3.39)
[¬((F_L1_S j) ∨ (F_L2_S j) ∨ (F_L3_S j) ∨ (F_L4_S j)
∨(H_L1_S j) ∨ (H_L2_S j) ∨ (H_L3_S j) ∨ (H_L4_S1)) → ¬(Trip_ j)] (3.40) where j is the corresponding stage. It can be seen that from the outside perspective, it is not possible to directly check the behaviour of an individual alarm, since at the output it would be ORed with all the other alarms in that particular stage. Therefore, any kind of test applied to verify their functioning by only looking at the module’s trip outputs would have to isolate the effect of the other alarm’s activation that are combined in that specific Trip output.
