Master Thesis Bai Jiachen

Master Thesis
A thesis submitted to the University Duisburg-Essen

For the degree of
Master of Science in Electrical and Electronic Engineering
A Study of Cross-Platform Interface Based on Dynamic Link

Library (DLL) between PSSNETOMAC and MATLAB for
Power Oscillation Damping (POD) Controller Design
Submitted by
Jiachen Bai
Supervised by
Univ. Prof. Dr.-Ing. habil. Istvn Erlich
University of Duisburg-Essen
Faculty of Engineering Technology
Institute of Electrical Power Systems
July 2015
Acknowledgement
Acknowledgement
I would like thank to all the staff members of the institute of Electric Power Systems of University
Duisburg-Essen for a friendly environment to study and perform research.
And, many thanks to my family for their endless love and support.
Statutory Declaration
Statutory Declaration
I declare that I have developed and written the enclosed Master Thesis completely by myself, and
have not used sources or means without declaration in the text. Any thoughts from others or literal
quotations are clearly marked. The Master Thesis was not used in the same or in a similar version to
achieve an academic grading or is being published elsewhere.
Location
Date
Signature
ii
Abstract
Abstract
Presently, power system simulation is executed in various power system simulation software. If a
model, like a control module, is intended to be used in the power system simulations based on
different software platforms, its modelling work needs to be repeated and specified for each platform.
To overcome this limitation, this thesis formulates a cross-platform interface: dynamic link library
(DLL) based application programming interface (API). First, to facilitate the creation and the use of
the API, this thesis systematically reorganizes the existing DLL-related literatures as: 1) two-layer
program architecture of DLL (code- and file layer); 2) two-phase creation procedure of DLL (codingand linking phase); 3) procedures and issues of the DLL call. Further, this thesis presents three modes
of the API creation work: 1) full-manual mode; 2) semi-automatic mode; 3) hybrid mode and their
scope of application. In this thesis, the hybrid mode is highlighted with its outstanding features, and
selected as the major mode for creating the APIs used in the case studies. To apply the hybrid mode,
a two-level DLL based API architecture is formulated: 1) the first-level DLL serves as a wrapper that
contains the compiled codes of the model; 2) the second-level DLL serves as interface for linking the
first-level DLL with the various simulation software. Next, the procedures and issues of the API call
are presented. Then, in the case studies, the cross-platform simulation is specified as the time-domain
simulation between MATLAB and PSSNETOMAC. Finally, to illustrate the three modes and to
validate the effectiveness of the API, the case study(including an addition model) is performed.
The APIs used in case studyare created in different modes. And for generality, in each mode, the
modelling work are performed with MATLAB codes and in Simulink respectively.
Next, to analyze the use of the API in a more practical case, the application of a PSS-based POD
controller in a one-machine infinite-bus (OMIB) system is simulated in the case study.This thesis
also assesses model predictive control (MPC) based POD controller by a comparison to classic PSS
in the case study:, where both OMIB- and multi-machine system cases are involved. Furthermore,
case study::also analyzes the design and the use of the MPC based POD controller by addressing
two aspects: state estimation and parameter tuning issues.
The results of case studies- show: 1) by calling the API program in simulations, functionalities
of the model can be requested in real time. As a conclusion, when a model built in MATLAB is to be
used in PSSNETOMAC, with the proposed API, extra remodeling work can be eliminated; 2) the
superior POD performance of the MPC based POD controller in the OMIB and multi-machine system;
3) the effects of different MPC parameter settings on the robustness (or response) of the controller.
iii
Table of Contents
Table of Contents
Acknowledgement ............................................................................................................................ i
Statutory Declaration......................................................................................................................ii
Abstract.......................................................................................................................................... iii
Table of Contents............................................................................................................................ iv
1 Introduction .................................................................................................................................. 1
1.1 Background and Motivation .................................................................................................... 1
1.2 Objectives and Contributions of This Thesis ........................................................................... 2
1.3 Outline of This Thesis ............................................................................................................. 4
2 Dynamic Link Library (DLL) ..................................................................................................... 5
2.1 Advantages of DLL ................................................................................................................. 5
2.2 DLL Program Architecture ...................................................................................................... 5
2.2.1 Program Code Layer ........................................................................................................ 6
2.2.2 Program File Layer ........................................................................................................... 7
2.3 DLL Creation .......................................................................................................................... 7
2.3.1 Overview .......................................................................................................................... 7
2.3.2 Coding Phase .................................................................................................................... 9
2.3.3 Linking Phase ................................................................................................................. 11
2.4 Linking Work in External Module ( .dll or .exe File) ............................................................ 12
2.5 Interoperability Issue between 32-Bit and 64-Bit Programs .................................................. 14
3 Application Programming Interface (API) and Case Study ................................................ 15
3.1 Introduction to General API .................................................................................................. 15
3.2 Introduction to API between MATLAB and PSSNETOMAC ............................................ 17
3.3 Introduction to Case Study: A Mathematical Model for API Study.................................... 19
3.4 Modelling Work in MATLAB ............................................................................................... 20
3.4.1 Introduction to MATLAB .............................................................................................. 20
iv
Table of Contents
3.4.2 Modelling Option 1: MATLAB Code ............................................................................ 20

3.4.3 Modelling Option 2: Simulink ........................................................................................ 21
3.5 Model Codes or First-Level DLL Generation with Compilation Tools .................................. 23
3.5.1 Compilation Tool 1: MATLAB Coder ........................................................................... 23
3.5.2 Compilation Tool 2: Simulink Coder ............................................................................. 25
3.6 API Program (One- or Two-Level DLL) Creation in Visual Studio ....................................... 27
3.6.1 Introduction of Visual Studio ......................................................................................... 27
3.6.2 Introduction of the Extended Simulation Environment Interface (ESE-Interface).......... 28
3.6.3 One-Level DLL Based API Creation (Mode 2) .............................................................. 29
3.6.4 Two-Level DLL Based API Creation (Mode 3) ............................................................. 31
3.7 Power System Simulation Software: PSSNETOMAC ....................................................... 33
3.7.1 Introduction to PSSNETOMAC .................................................................................. 34
3.7.2 Modelling and Linking Work in PSSNETOMAC ....................................................... 34
3.7.3 Simulation Result of Case Study ................................................................................ 36
4 Case Study: Power System Stabilizer (PSS) ......................................................................... 38
4.1 Introduction to the Power Oscillation Problem ...................................................................... 38
4.2 Introduction to the Excitation System with PSS .................................................................... 40
4.3 API Program Creation and OMIB System Modelling............................................................ 42
4.3.1 The First-Level DLL Generation in Simulink ................................................................ 42
4.3.2 API Program (the Second-Level DLL) Creation in Visual Studio .................................. 43
4.3.3 OMIB System Modelling and API Call in PSSNETOMAC ........................................ 43
4.4 Comparison between Simulation Tests with the PSS Models Included in API Program and in
PSSNETOMAC Program ......................................................................................................... 45
5 Case Study:: Model Predictive Control (MPC) Based Power Oscillation Damping (POD)
Controller....................................................................................................................................... 46
5.1 Introduction to Model Predictive Control .............................................................................. 46
5.2 State-Space Model Based MPC ............................................................................................. 48
5.2.1 State-Space Model and Prediction equations .................................................................. 48
5.2.2 Open-Loop Optimization and Moving Horizon Control ................................................. 49
5.2.3 State Estimation ............................................................................................................. 52
5.3 Introduction to the MPC Based POD Controller ................................................................... 55
v
Table of Contents
5.3.1 MPC Based POD Controller in OMIB System ............................................................... 55

5.3.2 MPC Based POD Controller in Multi-Machine System ................................................. 57
5.4 API Program Creation and Power System Modelling ............................................................ 60
5.4.1 The First-Level DLL Generation in Simulink ................................................................ 60
5.4.2 API Program (the Second-Level DLL) Creation in Visual Studio .................................. 62
5.4.3 OMIB & Multi-Machine System Modelling and API Call in PSSNETOMAC ........... 62
5.5 Simulation Tests for Analyzing Different MPC Based POD Controller in OMIB System..... 65
5.5.1 Test 1: Different State Estimator Based POD Controllers .............................................. 65
5.5.2 Test 2: Different Prediction Horizon (PH) Based POD Controllers ............................... 70
5.5.3 Test 3: Different Control Horizon (CH) Based POD Controllers ................................... 72
5.5.4 Test 4: Different Control Action Weights ( ) and Control Action Rate Weights
( ) Based POD Controllers ................................................................................... 74
5.5.5 Summary ........................................................................................................................ 79
5.6 Simulation Test for Analyzing MPC Based POD Controller in Multi-Machine System ........ 80
6 Conclusion and Future Work .................................................................................................... 82
6.1 Conclusions ........................................................................................................................... 82
6.2 Future Work ........................................................................................................................... 83
Appendix A: ext_simenv_API.c File ............................................................................................ 85
Appendix B: typedef_export.h File .............................................................................................. 89
Appendix C: Modified Appendixes A & B for the Case Study ............................................... 90
Appendix D: Modified Appendixes A & B for the Case Study: (for the OMIB Case) ......... 91
Appendix E: Modified Appendixes A & B for the Case Study: (for the Multi-Machine Case)
........................................................................................................................................................ 92
References ...................................................................................................................................... 94
vi
1 Introduction
1 Introduction
1.1 Background and Motivation
Nowadays, with the development of power systems and computer technology, software for power
system simulation becomes more various [1.1-1.2], e.g. PSSNETOMAC, PSASP, PowerFactory,
PSSE, etc. Furthermore, due to more complicated cyber-physical systems, coupling the models
modelled on different platforms in a simulation is needed [1.3] and the models have to be remodeled
for a uniform platform. In addition, manufacturer often maintains its model as reference model in a
general modelling platform [1.4]. For a simulation on a different platform, the reference model has
to be remodeled. However, the remodeling work may be a time consuming, complicated, and even
error-prone process, since different software platforms provide different modelling languages. Thus,
it is essential to present a cross-platform interface for canceling the remodeling work. Report [1.4]
presented a general binary interface with its prototype implementation for various power system
simulators. This report will be mainly referenced in this thesis for underlying the API program. Then,
references [1.5-1.6] describe the application procedure of the built-in interface function of PSASP.
References [1.3] [1.7] summarized the applications of the various interface modules of PowerFactory.
References [1.8] [1.9] presented the use of the Fortran API interface of PSSE. However, few of the
above-mentioned references are devoted to a comprehensive and systematic analysis of the crossplatform interface issues, like its underlying architecture, creation procedures and application. And a
case of cross-platform simulation between PSSNETOMAC and MATLAB is not systematically
studied, either. These limitations form the first main motivation of this thesis.
On the other hand, in todays practical power systems, small-signal stability is largely a problem of
insufficient power oscillation damping (POD) [1.10]. Specifically, with the increasing interconnected
power systems and deregulation of electrical-energy market, more inter-area oscillations may emerge,
and they degrade the reliability of such power systems and risk system security more [1.11-1.15]. As
the classical control strategy for POD, power system stabilizer (PSS) has been used for many years
[1.16]. However, for the inter-area oscillation, conventional PSS may not provide sufficient damping
[1.17-1.18]. To overcome this, three major scenarios are employed: 1) using global (remote) signals
of large power system as supplementary input to PSS for enhancing the POD performance [1.111.13]; 2) utilizing other devices, like FACTS and HVDC, to enhance POD [1.12][1.17-1.18]; 3)
adopting other control strategies, like Fuzzy or model predictive control (MPC) [1.19-1.20].
As one option for the third scenario, MPC has been proven effective for POD in different cases [1.201.28]. In [1.20-1.23] the proposed MPC based POD controllers calculated the optimal control actions
1
1 Introduction
for local controllers like PSSs and flexible AC transmission system (FACTS) devices. In [1.24-1.28],
the designed MPC controllers calculated the optimal control actions to HVDC devices for stabilizing
the power system. In [1.20-1.28], keywords like multi-machine system, wide area measurement and
inter-area oscillation are involved except for [1.22-1.23] where only the one-machine infinite-bus
(OMIB) system is studied. Additionally, providing the MPC model is of state-space form and only
part of its state variables are measurable, estimation issues should be considered in the MPC based
POD controller. Nevertheless, in [1.20-1.28], first estimation issues are either only discussed in rough
or even omitted due to problem reduction. Then, parameter tuning issues of MPC, especially the ones
related to control robustness (or response) are not discussed, either. Next, a cross-platform simulation
has not been adopted, either. Those three limitations form the second main motivation of this thesis.
1.2 Objectives and Contributions of This Thesis

The first main aim of this research is to formulate a DLL based API for cross-platform simulation
between PSSNETOMAC and MATLAB. The second main aim is to analyze the MPC based POD
controller. More specific objectives to define the scope of this thesis are:
1) To formulate a systematic survey of DLL technology, whereby the understanding and the creation
work of a DLL based API (for general case: unspecified platforms) should be enhanced.
2) To formulate the creation procedure of the general API (unspecialized platforms) and to analyze
calling process and -issues of the API, by which the API creation and application can be facilitated.
3) To perform a similar work to 2), however the two linked platforms are specified as: MATLAB and
PSSNETOMAC so that the creation and application of the corresponding API can be facilitated.
4) To create the specified API and perform its related calling work. Then validate their effectiveness.
5) To model a classical PSS controller in Simulink (MATLAB) and to simulate it in OMIB system
in PSSNETOMAC with the API technology.
6) To model a MPC based POD controller in Simulink and to simulate it in both OMIB system and
multi-machine system respectively in PSSNETOMAC with the API technology.
7) To analyze the control performance and robustness of the MPC based POD controller.
8) To analyze the estimation and parameter tuning issues of the MPC based POD controller
Then, the contributions of this thesis are mainly divided as three parts:
1) The API-related contributions:
Since the existing DLL-related resources are massive and fragmentary, this thesis has reorganized
them and formulated a systematic survey of DLL technology containing three parts: 1) two-layer
division of DLL program architecture; 2) two-phase division of DLL creation work; 3) call-related
2
1 Introduction
issues of DLL. By this survey, creation and use of a DLL-based API can be practicable and simple.
Presently, few references are devoted to a systematic formulation of the creation and calling work
of the API. Therefore, this thesis systematically presents three modes for the API creation: 1) fullmanual mode; 2) semi-automatic mode; 3) hybrid mode, and the API-related calling work, with
structure flowcharts. In addition, the feature and applied range of each mode are expounded. Then,
accordingly, a mode can be selected for planning the API creation.
One specific type of API architecture: two-level DLL is proposed for the implementation of the
hybrid mode. The first-level DLL wraps the compiled model. And the second-level DLL, whose
codes are based on a published Extended Simulation Environment Interface (ESE-Interface)
[1.29], serves as the interface to link the first-level DLL with different external programs.
A specific case: cross-platform simulation between MATLAB and PSSNETOMAC has been
addressed and analyzed since it is less involved in the existing literatures. Accordingly, the three
modes are specified and for generality, in each mode two modelling possibilities: MATLAB codes
and Simulink are both involved. At last, the structure flowcharts are also specified.
For the specified case, the three modes, the corresponding API call, and the created APIs have
been validated to be effective through the case study. In case study, different API (involving
addition model) is created based on each modelling possibility and mode, and is called by the
simulation in PSSNETOMAC to perform the additive operation successfully. As a conclusion,
with the APIs, the specified cross-platform simulations can be executed without remodeling work
in PSSNETOMAC environment.
2) Based on the API technology, a classic PSS model has been successfully implemented in an OMIB
system model for POD in a cross-platform simulation. The classic PSS is modelled in Simulink
and the OMIB system model is simulated in PSSNETOMAC. And the API used in this case is
created in the hybrid mode. To execute and analyze this cross-platform case, the case studyis
performed. In it, the POD performance of the API based PSS model is assessed by a comparison
with a PSS model which is modelled completely in PSSNETOMAC.
3) The contributions relating to the MPC based POD controller:
Based on the API technology, MPC based POD controller models have been successfully applied
in OMIB- and multi-machine system models for POD in cross-platform simulations. The two
types of power systems are modelled and linearized as discrete-time linear models by small-signal
method. Then, the power system models are simulated in PSSNETOMAC and the MPC based
controller is modelled by Model Predictive Control Toolbox in Simulink environment. And the
APIs used in this case are created in the hybrid mode. To execute and analyze this cross-platform
3
1 Introduction
case, the case study: :is performed. In it, the POD performance of the MPC based POD
controller is assessed by comparing with classic PSS.
State estimation issues of the MPC based POD controller for OMIB system model are analyzed
systematically. In this analysis, two estimation methods: pole-placement and Kalman Filter are
presented based on three aspects: estimator design, control robustness and control response. For
the last two aspects, both time domain and frequency domain analyses are performed. In the timedomain analysis, results of the time-domain simulations based on the two types of estimators are
respectively compared. For the frequency-domain, eigenvalue analyses of the closed-loop control
systems with and without estimator are compared respectively. In conclusion, an estimation
method can be selected according to its design feature and to the specified trade-off between fast
control response and high control robustness, for different requirements.
Parameter tuning issues of the MPC based POD controller are analyzed systematically. For the
OMIB case, the critical parameters of MPC: prediction horizon (PH), control horizon (CH),
control action weight ( 1 ) and control action rate weight ( 1 ) are tuned respectively to
analyze their effects on control response and robustness. Then, values of these MPC parameters
can be determined to achieve a specified trade-off between control response and robustness for
different control cases. For the multi-machine case, an auxiliary parameter: set-point (r) of system
output is also analyzed and tuned to achieve a superior control robustness.
1.3 Outline of This Thesis

The remaining chapters of this thesis are organized as follows:
Chapter 2 formulates a systematic survey of DLL technology.
Chapter 3 formulates the procedure of API creation and call. And the case studyis presented with:
its introduction, the creation procedure of the applied APIs (wrapping addition model), the call
procedure of the APIs, its simulation results and discussion.
Chapter 4 discusses the power oscillation problem and presents the case study with: the creation
procedure of the applied APIs (wrapping classic PSS model), the call procedure of the APIs, the
description of the OMIB model (power system model), its simulation results and discussion.
Chapter 5 introduces MPC-related theory and presents the case study::with: the creation procedure
of the applied APIs (wrapping MPC based POD controller model), the call procedure of the APIs,
the description of the OMIB- and multi-machine model, its simulation results, discussion of its state
estimation issues and parameter tuning issues, and a summarization of control response (robustness).
Chapter 6 presents the conclusions of the thesis and proposes some ideas for future work.
2 Dynamic Link Library (DLL)

Dynamic Link Library (DLL) is an executable program developed by Microsoft Company based on
the shared library concept in the Microsoft Windows. This chapter introduces and describes DLL and
its creation procedure by addressing the related issues of API that will be discussed later. Section 2.1
presents the advantages of DLL that accounts for why to choose DLL for building API. Section 2.2
describes program architecture of a general DLL. Section 3.3 presents the procedure of DLL creation,
which also indicates the basic procedure of API creation. Section 2.4 describes the linking work in
the external module (client executable). At last, section 2.5 discussed an interoperability issue
between 32-bit and 64-bit programs, which should be noted for the creation and use of the API later.
2.1 Advantages of DLL

In this section, three major advantages of DLL are introduced. These advantages account for the
reason why dynamic linking method rather than other linking method, e.g. statistic linking method,
is chosen for building the API. These advantages are listed as follows:
Supports multilanguage programs. Programs written in different programming languages can
call DLL functions as long as the programs follow the calling convention that the function uses
[2.2]. In this thesis, since DLL file need to be called both by PSSNETOMAC program and by
other DLL file whose programming languages are different, therefore this advantage is necessary.
Security. Based on DLL technology, the core algorithm provided by manufacturer is wrapped
into DLL file (black box). Since, it is theoretically difficult for crackers to disassemble and
decompile an executable file like DLL, therefore the intellectual property of the manufacturer is
protected. In this thesis, the model from MATLAB is wrapped into a DLL file and the specific
algorithm of the model cannot be abstracted from the DLL file generally.
Upgrades to the DLL are easier. When the functions in a DLL change, the applications, i.e.
PSSNETOMAC and other DLLs which use those functions, do not need to be recompiled or
relinked as long as the function arguments and return values do not change. In contrast, statically
linked object code requires that the application be relinked when the functions change [2.1].
2.2 DLL Program Architecture

DLL program is composed of different linked program files. Into each file, the programming codes
for establishing different program functions and program data (like a structure or an array) are
allocated correspondingly. Hence, in this section, DLL program architecture is introduced according
to a two-layer division: 1) program code layer; 2) program file layer. In subsection 2.2.1, program
function and data of DLL which are classified as: internal and exported, are introduced. In subsection
2.2.2, two types of program file: header- and source file, are introduced. In this thesis, C language is
the programming language of DLL and the following introduction is based on this language.
2.2.1 Program Code Layer

Underlying codes of a DLL program are written for establishing different program functions (data).
Hence program code layer defines the underlying components of a DLL program and it is the bottom
layer of DLL architecture. As mentioned before, there are two kinds of program functions (data): 1)
the exported functions (data) are intended to be called (accessed and assigned) by external modules
(.dll or .exe file), as well as by the DLL where the exported functions (data) are defined; 2) internal
functions (data) are intended to be called only by the DLL where they are defined [2.2]. The abovementioned function call relationship and data exchange are illustrated in Fig 2.1.
External Modules
(.dll or .exe file)
Linking
Technology
Exported
Internal
Function
Function
Exported
Internal
Data
Data
A DLL File
(Linked .h and .c program files)
: 1) Function call;
2) Data access; 3) Data assignment;
Note : two-direction arrow between functions and data blocks means both data access and assignment are feasible.
Figure 2.1: Function call relationship and data exchange of a DLL program.
In Fig 2.1, the linking technology is required for linking DLL program with external modules, and
either DLL file or external module should be accordingly modified for using linking technology.
Issues of linking technology will be introduced in detail in subsection 2.3.2. In addition, the four
program function and data blocks are included in a DLL file block which represents linked header
and source program files, since the codes are allocated into these files subsequently. These program
files representing the program file layer will be introduced in next subsection 2.2.2.
To export a program function (data), it should be declared as a global function (variable), since in C
language environment only global function (data) is enabled to be exported into other program file.
Referring to C language syntax, to declare a function (data) to be a global function (data), a prefixed
modifier extern is added before the declaration statement of that variable.
6
2.2.2 Program File Layer

As mentioned before, generally a DLL file is directly composed of a set of linked program files:
header file (.h file) and source file (.c file). Hence, program file layer defines the direct components
of a DLL and it is the upper layer of DLL architecture. As part of a DLL file, header file in this case
contains mainly extern declarations for declaring exported program function (data). In some cases,
declarations for some internal function (data) are also included in header file. On the other hand,
source file includes header file by using the pre-processor #include statement for copying the content
of header file. Furthermore, source file contains definition and initialization of exported as well as
internal program function (data). Last, some necessary macro definitions are also included in the
header and source files. The above-mentioned rule for allocating codes into different program files
is shown in Fig 2.2, where the function block and data block are combined as one block.
Header Files
(.h files)
Declaration
External
Modules
(.dll or
Linking
Technology
Exported
Internal
Part
Part
.exe file)
Definition & Initialization
Source Files
(.c files)
: Programming codes allocation.

: 1) Function call; 2) Data access; 3) Data assignment;
A DLL File
Figure 2.2: The allocation of programming statement and codes to DLL program files.
2.3 DLL Creation

In this section, a complete description of the procedures of DLL creation is given. At first, an
overview of DLL creation is given in subsection 2.3.1, where four creation methods are introduced
and additionally they are divided into two phases: coding and linking phase. Focusing on these phases,
expositions of procedures are given in subsection 2.3.2 and 2.3.3 respectively.
2.3.1 Overview
For creating a DLL, there are a variety of software environment and methods, however in this thesis
only four methods are implemented and discussed, whose procedures (workflow paths) are depicted
in Fig 2.3. Among these methods, the method 3 (red line) is mainly used in the API construction for
the following case studies, since by the method 3 a two-level architecture based DLL can be created
and this type of DLL is highlighted in this thesis. Then, the four methods are listed as follows:
7
The grey line (Method 1) represents a full-manual DLL creation procedure which means both
coding and linking work are performed manually in a selected development environment.
The blue line (Method 2) represents a semi-automatic (manual) DLL creation procedure, which
means the major coding work is performed automatically in a selected application software, and
the remaining coding and linking work are performed manually in development environment.
The red line (Method 3) represents a hybrid procedure for creating a two-level architecture based
DLL. Hybrid means the DLL of different level can be created by a combination of the other
methods. For example, the first-level DLL can be performed by the other three methods which
are performed in different environments, however, the second-level DLL is built in development
environment. After the first-level DLL is completed, it can be called by the call statements in
the program codes of the second-level DLL. In other words, when the second-level DLL is called
by some specific external module, the functionality or data of the first-level DLL can also be
requested. In this thesis, the two-level DLL is the major DLL type to be studied and used.
The violet line (Method 4) represents a full-automatic DLL creation procedure where the both
coding and linking work are performed automatically in application software.
Additionally, in Fig 2.3 these procedures are divided into two phases: coding phase and linking phase,
which will be detailed respectively in the next sections 2.3.2 and 2.3.3.
Development Environment
Application Software
(e.g. Visual Studio)
(e.g. MATLAB)
Coding Phase
Manual Coding
Automatic Coding
Linking Phase
Manual Linking
Automatic Linking
:Method 1
:Method 2
:Method 3
:Method 4
DLL File Creation

Figure 2.3: An overview of the procedures for creating DLL file.
Furthermore, application conditions (field of application) of these methods are classified as follows:
If the algorithm of DLL program is simple or its codes cannot be generated from application
software automatically, method 1 (full-manual) is adopted for DLL creation.
If the algorithm of DLL program is complex and its codes can be generated from application
8
software automatically, method 2 (semi-automatic) is adopted for simplifying DLL creation.

Another two considerations to use method 2 is that: 1) Adopting the automatically generated
codes as the code base of a DLL program, a specific code modification can be made manually.
Therefore, both advantages: simplifying DLL creation and custom-made creation, are taken
into consideration; 2) since in some case external modules can only identify a specific linking
method (format) and the automatic linking work by application software is not consistent with
the specified method (format), a specific manual liking is necessary.
There are four considerations to use method 3 (two-level DLL) instead of 2: 1) no need to modify
the auto-generated codes specifically; 2) calling the wrapped codes (a DLL program) instead of
the codes scattered in different files is more intuitive, especially for compiling an extremely
complex algorithm. Furthermore, in the coding phase, when using method 2, the auto-generated
header files (.h) should be linked accordingly to the main program files, which complicates the
DLL creation work; 3) core algorithm from third-party (e.g. a manufacturer) needs to be hidden
so that its intellectual property can be protected. For this reason, wrapping the codes into a DLL
file (like a black-box) is a wise choice; 4) the first-level DLL is only called by the second-level
DLL rather than a code copy into the second-level DLL. This reduces the size of the secondlevel DLL and save the system memory when the two-level DLL is called. In addition, the
consideration to use method 3 instead of 4 is that: the linking work of the first-level is not
consistent with the specified linking required by external modules. Therefore, a manual linking
work should be performed in the second-level DLL to meet the specified linking.
If the algorithm of DLL program is complex and application software can generate a DLL file
including that algorithm, method 4 (full-automatic) is adopted. A precondition for using method
4 is that the automatic linking of DLL is consistent with the specified linking of external modules.
2.3.2 Coding Phase

The procedures of coding phase are introduced respecting two blocks: manual coding and automatic
coding, which are illustrated in the Fig 2.4. The procedure in the manual coding block is based on
the order of two layers as mentioned in section 2.2: Firstly, in the program code layer the specific
algorithm (e.g. mathematical operation) is translated to C language by the declaration, definition and
initialization of different functions and data. In the declaration part, extern declaration declares
exported variable as global variable as mentioned in subsection 2.2.1. Furthermore there could be
other declarations (e.g. static or general declaration) required in the DLL program and these
declarations are allocated into different program files respectively. Secondly, in the program file layer
the codes are allocated into the header and source files respectively and then these program files are
linked together respectively. In the linking work of program files, there are two types of header file
including: 1) including a header file into a source file, which is shown by a bold arrow in Fig 2.4; 2)
including a header file into another header file. Additionally, there could be some macro definition
statements required in the DLL program, however they are not shown in Fig 2.4.
In the automatic coding block, the content of coding work is the same as manual coding, however
the corresponding procedures in Fig 2.4 are different. The reason is the coding work of automatic
coding block is implemented by automatic technology and cannot be shown respectively like manual
coding. Instead, the automatic procedures are: 1) the built model is automatically compiled into C
codes by C-code compiler which is installed in application software; 2) the codes are allocated into
different header and source files, and then these files are linked automatically by using toolchain or
template makefile approach. Additionally, by choosing different target file of toolchain or template
makefile approach, the final generated header and source files are different, even though the codes
in these files represent the same algorithm.
Finally, respecting the method 2 (blue line), the automatically generated program files should be
manually linked to the main program in the manual coding block, which could be an error-prone
process and also a drawback compared to method 3 (mentioned in subsection 2.3.1).
Automatic Coding
Manual Coding
Coding Phase
C-Code Compiler
Program Function and Program Data
extern
Declaration
Other
Declaration
Other
Declaration
Definition &
Initialization
Toolchain or
Template Makefile
Header
Source File
Header File
Linking Phase
Manual Linking
:Method 1
:Method 3
:Method 2
:Method 4
: Included into source file.
File
Automatic Linking
DLL File Creation
Figure 2.4: Procedures in the coding phase of DLL creation.
10
Source
File
:Workflow
dPath
2.3.3 Linking Phase

As mentioned before, the program function and data that are known to be exported are declared to
be global variables, however some specific linking works are still required so that these exported
function and data can be identified and called by external modules. As mentioned in subsection 2.2.1,
the linking work is divided into two parts: in the DLL file creation and in extern module. The first
part is introduced in this subsection and the second part will be introduced in the section 2.4.
There are generally two types of linking methods: implicit and explicit linking. Implicit linking is
sometimes referred to as load-time linking and explicit linking as run-time linking [2.1]. Different
reasons to choose implicit or explicit linking method have been introduced in [2.1], however they are
not primary considerations in this thesis and can be omitted. Hence, both linking methods are
introduced here and can be used in the following study cases.
The procedures of coding phase are introduced respecting two blocks: manual and automatic linking
blocks, which are illustrated in the Fig 2.5. In the manual coding block, for either implicit or explicit
linking, the first step is to define the DLLs exports table that refers to the exported functions and
data [2.3] so that external module can specify the exported content of a DLL. There are two methods
for building the exports table: 1) create a module-definition (.def) file and use it when building the
DLL. Module-Definition file is a text file containing one or more module statements that describe
various attributes of a DLL [2.4]. 2) Use an additional keyword _declspec(dllexport) in the
functions (datas) declaration and definition, where dllexport is an attribute as Microsoft-specific
extension to the C language and _declspec is the keyword in the extended attribute syntax [2.4].
Differences between the above two methods have been introduced in [2.1], however they are not
required to be considered in this thesis. Hence, both of the methods are introduced here and can be
used in the following study cases. Furthermore, when using implicit linking, an accessary import file
(.lib) is required since it supplies the system with the information needed to load the DLL and to
locate the exported DLL functions during load-time [2.2]. Respecting the explicit linking, external
module uses some specific functions to locate the exported DLL functions (data), which eliminates
the need for .lib file [2.2] and will be introduced in section 2.4. Hence, with explicit linking method
the procedures of linking phase can be reduced.
In the automatic linking block, the content of linking work is the same as manual linking, however
the corresponding procedures are different. The reason is the linking work of the automatic coding
block is implemented by toolchain or template makefile approach automatically and cannot be shown
11
respectively like manual linking. Additionally, either of the linking methods can be adopted in
automatic linking work, and then by modifying the corresponding template makefile as well as
automatically generated codes, the linking method can be changed [2.6].
Manual Coding
Automatic Coding
Coding Phase
Manual Linking
Linking
Phase
Implicit Linking
Automatic Linking
Explicit Linking
Implicit or
Explicit Linking
Export Method for Exported Function and Data

(e.g. + dllexport or + .def file)
Toolchain or
Template
Makefile
+ Import File ( .lib file )
:Method 1
:Method 2
:Method 3
:Method 4
DLL File Creation

:Workflow
dPath
+f: Additional modifier or file.
Figure 2.5: Procedures in the linking phase of DLL creation.
Finally, DLL creation work is accomplished. However if DLL is intended to be called by an external
module, the other part of linking work is still required in the external module, which is introduced in
section 2.4. In addition, respecting the third method, i.e. a two-level based DLL, the second-level
DLL is the so-called external module for the first-level DLL, so the linking work introduced in
section 2.4 is involved in the manual coding block of Fig 2.5.
2.4 Linking Work in External Module ( .dll or .exe File)

As mentioned in subsection 2.3.3, the second part of linking work needs to be performed in the
external module that is intended to call the created DLL program, and the content of the second part
work is related to a modification of the external module instead of DLL program. Therefore, the
second part is written in a separate section from the section 2.3, and the linking issues are discussed
based on implicit and explicit linking methods as illustrated in Fig 2.6.
At first, in implicit linking part, a header file containing the declaration of the exported functions
(data) should be included into the main source file that is intended to call the exported functions (data)
[2.1]. This type of header file has been created in the previous coding phase, and it can be directly
12
copied and reused here. Then, the modified external module is linked with the import library (.lib
file) created in the previous linking phase. Then, the exported functions (data) can be called by the
external module as if they were local functions (data) for that module [2.2].
Original External Module (.dll or .exe file)
Explicit Linking
Implicit Linking
The .h File created in the
Previous Coding Phase
The Main Source File of

External Module
Linked with the .lib File
Call
Type Declaration
( by typedef ) for
Exported Data
A Special .h File
LoadLibrary (FileName);
Return A Handle to External Module
Call
GetProcAdress (Handle, ProcName);
The Main Source File of External Module
:dIncludeddinto
d source file.
Figure 2.6: Procedures for linking an external module with the created DLL.
Linkable External Module
Secondly, for the explicit linking, more modifications are required. Since explicit linking eliminates
the need to link the external module with an import library [2.1], an alternative solution should be
implemented for locating the DLL and the exported functions (data). For that, two SDK functions:
LoadLibrary(FileName) and GetProcAdress(Handle, ProcName), are adopted. LoadLibrary function
loads the specified DLL into the address space of process. Alternatively, another similar function
LoadLibraryEx can also be used and can supply additional load options. And GetProcAdress function
retrieves the address of an exported function (data) from the specified DLL [2.8]. The exposition of
LoadLibrary and GetProcAdress functions are given in [2.8]:
To the parameter of LoadLibrary: FileName, if a string specifying a relative path or a DLL name
is assigned, the function uses a standard search strategy to find the DLL; if a full path is assigned,
the function searches only the path for the DLL. Then, if the function succeeds, a return value is
a handle to the external module, however, if fails, the return value is NULL. For GetProcAdress,
the first parameter Handle is the returned value from LoadLibrary and the second parameter
ProcName is the name of the exported function (data). If the function succeeds, the return value
is the address of the exported function (data); if fails, the return value if NULL.
After the addresses of the exported functions (data), are obtained, in order to accept them, some
specific function (data) pointers which can be pointed to the exported functions (data), need to be
13
defined [2.7]. For that purpose, typedef keyword is used to declare the same types as the ones of
the exported data in a specific header file. Then, after the header file is included into the main source
file of the external module, the required pointers can be defined. By the use of these pointers, the
exported functions (data) can be used as local functions (data) for the external module.
Finally, with the above-introduced linking work, the external module become linkable to DLL.
2.5 Interoperability Issue between 32-Bit and 64-Bit Programs

As the last section of this chapter, a compatibility issue of DLL file is discussed. Since the modern
operation system (OS) are mainly divided into two types: 32-bit and 64-bit for supporting different
computer processors, two versions of assorted programs (in this thesis, development environment,
application software and external modules) are developed for supporting different OSs respectively.
Then, interoperability issue between different versions should be considered.
The interoperability issues in this thesis mainly focuses on four cases: 1) between external executable
program and DLL; 2) between DLL and DLL; 3) between development environment and the DLL it
generates; 4) between application software and the DLL (or codes) it generates. For the first case,
32-bit (64-bit) executable program cannot load a 64-bit (32-bit) DLL [2.9] [2.10]. In the case of this
thesis, if the external module is 32-bit (64-bit) executable program, the DLL should be created based
on 32-bit (64-bit). However, as long as the external module and the DLL to be called are both 32-bit
programs, the external module including the calls to the DLL can run on either 32-bit or 64-bit OSs
[2.10]. For the second case, DLLs based on different bit are not interoperable, which means:
respecting a two-level architecture based DLL in this thesis, if the second-level DLL is 32-bit (64bit), the first-level DLL should also be 32-bit (64-bit). As long as both the DLLs have the same bit,
the second-level DLL can be called by arbitrary executable program running on the OS of arbitrary
bit. For the third case, in general development environment, by setting the configuration of DLL
project either 32-bit or 64-bit DLL program (file) can be created. For the fourth case, generally a 32bit (64-bit) application software can only generate a 32-bit (64-bit) DLL (codes). The reason is: the
bit of the generated DLL (codes) is determined by the bit of the compiler and toolchain (or template
makefile) that are integrated into the application software.
14
3 Application Programming Interface (API)
3 Application Programming Interface (API) and Case Study

This chapter describes DLL based API by addressing its creation and use procedure. For this purpose
and for validating effectiveness of the API, case study(involving an addition model) is performed.
In sections 3.1&3.2, general API and its specified mode between PSSNETOMAC and MATLAB
are introduced. Then, case studyis introduced in section 3.3. Next, from section 3.4 to 3.6, creation
procedure of the specified API for case study are described step by step. In section 3.7, the
preparatory work in PSSNETOMAC and the simulation result of case studyare presented.
3.1 Introduction to General API

In computer programming, application program interface (API) is a set of standardized functions or
routines whereby a requesting program (requestor) can request services from a requested program
[3.1] [3.2]. In this section, at first architecture of general API is introduced. Then, its creation work
is described. Based on this section, specified APIs for different applications can be discussed later.
The architecture of general API is illustrated in Fig 3.1. Here, general means that the modeling
environment, power system simulation software and API creation mode are unspecified. Their
different possibilities are enumerated in Fig 3.1. However, in this thesis, only the case that MATLAB
as modelling platform and PSSNETOMAC as power system simulation software is concentrated.
Model
Power System
Simulation
Software
Modelling
Platform
Codes
API
(PSSNETOMAC,
PSSE,
SimPowerSystems,
PowerFactory,
PSASP)
Compilation
Tool
Development
Environment
FirstLevel
DLL
(MATLAB,
Visual Studio,
Simplorer [3.3],
PowerFactory [3.4])
: Linking Technology
: Mode 1 (Full-Manual Mode)
: Mode 2 (Semi-Automatic Mode)
: Mode 3 (Hybrid Mode)
Figure 3.1: structural description of a general API based case.
Fig 3.1 contains mainly four parts: modelling platform, API creation blocks, API and power system
simulation software. Firstly, a time-domain model is modeled in the modelling platform. Then the
model is encapsulated into the API through different API creation blocks and modes that will be
described later. Since API in this thesis is based on DLL technology, API creation work are described
referring to the DLL creation work in chapter 2. In Fig 3.1, modelling platform and compilation tool
generally belong to the same application software that is mentioned in Fig 2.3. At last, the
simulation software can access the API by linking technology so that it can request internal data and
15
various simulation functionality from the model.

Then creation work of general API is illustrated in more detail in Fig 3.2 where the related work in
the two linked (interfaced) parts: modelling platform and simulation software are also described. On
the modelling platform, a time-domain model is built. And, in the simulation software a specific
power system is modelled. Also, in the program module of the linked power system node (e.g. a node
equipped with an external controller), some specific program statements of the power system
simulation software are added for API linking, which will be introduced in subsection 3.7.3. Further,
for simulation software, if the mechanism for handling interface issues works under user-defined
mode, some specific linking work similar to the ones introduced in section 2.4 should be manually
performed. However, in some cases, the programming language of simulation software (like
PSSNETOMAC) may not be C-code that is the most common programming language of DLL
program. Then the linking work in the simulation software is performed in non-C environment and
this leads to a more complex work. Therefore, one scenario is presented: linking work is completed
by simulation software for general use without considering the specific API to be linked. This
scenario is feasible provided that different APIs are constructed based on the same program structure
(template code) which is consistent with the linking work in the simulation software. In general, these
template codes are provided by the developer of the simulation software. Additionally, for creating a
fully-functional and needs-satisfying API program, various functions and data structures are also
added into these template codes. Finally, in simulation software, some ancillary work, like interface
macro file creation or subroutine call, are implemented if required.
Modelling
Work
System Model
Linking Work
for Using API
Power System
Simulation
Software
:Mode 1
: Mode 2
: Mode 3
:Workflow Path
API:
Template
Codes
Model Codes
1) OneLevel
DLL,
Manual
Coding
Automatic
Coding
Modelling
Work
2) TwoLevel
DLL
Manual
Linking
Automatic
Linking
Model
Development
Environment
: Workflow for PSSNETOMAC

: Codes Copy
Compilation
Tool
Modelling
Platform
First-Level
DLL
Figure 3.2: Procedures for creating and calling a general API.
Then, referring to the four methods for DLL creation work in chapter 2, three modes for API creation
16
can be summarized in Fig 3.2: 1) in mode 1 (full-manual mode), the model is manually programmed
in C-codes without compilation tool. Then in development environment, the user-defined codes and
template codes are assembled manually. Next, by manual linking API is established. In this process,
only one DLL is created. Thus the API architecture is based on one-level DLL; 2) in mode 2 (semiautomatic mode), the built model is coded into standardized model codes by compilation tool
automatically. Then the follow-up procedures are the same as the ones of mode 1. Thus the API
architecture is also based on one-level DLL; 3) here, method 3 and method 4 in chapter 2 are
combined as mode 3 (hybrid mode). Unlike the previous modes, the built model is not only coded
but also linked automatically by compilation tool to generate the first-level DLL. Then, in the manual
coding part, template codes are modified for calling the first-level DLL. Next, by manual linking the
modified template codes, the second-level DLL is created. Since two DLLs are created, the created
API architecture is based on two-level DLL.
3.2 Introduction to API between MATLAB and PSSNETOMAC

In this section, the two interfaced parts: modelling platform and simulation software are specified as
MATLAB and PSSNETOMAC. Then, the corresponding specified API is introduced at two aspects:
API architecture and procedures of API creation work.
First, API architecture is illustrated in Fig 3.3. In comparison with Fig 3.1, the differences are: 1)
modelling platform is MATLAB with two options: MATLAB code or Simulink; 2) compilation tools:
MATLAB Coder and Simulink Coder that are the toolboxes provided by MATLAB; 3) development
environment is Visual Studio; 4) mode 1 is not given here since its modelling work is performed with
C-codes instead of MATLAB; 5) simulation software is PSSNETOMAC.
Model
Codes
PSSNETOMAC
API
Compilation Tool:
1) MATLAB Coder;
2) Simulink Coder;
Visual Studio
MATLAB:
1) MATLAB Code;
2) Simulink;
FirstLevel
DLL
: Mode 2 (Semi-Automatic Mode)
: Mode 3 (Hybrid Mode)
Figure 3.3: Structural description of the case based on the API between PSSNETOMAC and MATLAB.
Then the creation work of the API is illustrated in Fig 3.4. Compared to the case of general API, the
blocks are specified: 1) for automatic coding, a C-Code compiler (e.g. Microsoft Visual C++)
provided by third party is required to be installed, which provides technical support to the compilation
17
tool of MATLAB [3.5]; 2) for automatic linking, toolchain approach is adopted. Available toolchains
that may include compiler, linker, archiver, and other prebuild or post-build tools [3.6], are installed
on the host computer platform. Therefore, respecting the method 4 given in chapter 2, the C-Code
compiler block may be one part of the toolchain block; 3) the template codes in this case are the
Extended Simulation Environment Interface (ESE-Interface), which was published in the IEC
(International Electro-technical Commission), for the use of one single model in different software
environments [3.7]. This software-interface will be revealed in subsection 3.6.2; 4) For the linking
work in PSSNETOMAC, only an interface macro file needs to be created, which will be introduced
in subsection 3.7.2. Thus API developer does not need to do the linking work that are described in
the section 2.4 manually. Finally, to summarize, there are four different API programs mentioned so
far: 1) one-level DLL based API with MATLAB Coder; 2) one-level DLL based API with Simulink
Coder; 3) two-level DLL based API with MATLAB Coder; 4) two-level DLL base API with Simulink
Coder. Then, the following sections will be organized based on the creation work of those APIs.
Modelling
Work
System Model
Interface
Macro File
PSSNETOMAC
Model Codes
API:
IEC ESEInterface
1) OneLevel
DLL
Manual
Coding
C-Code
Compiler
Modelling
Work
2) TwoLevel
DLL
Manual
Linking
Toolchain
Model
Visual Studio
1) MATLAB Coder;
2) Simulink Coder;
1) Matlab Code;
2) Simulink;
:Workflow for MATLAB

First-Level
:Workflow for PSSNETOMAC
DLL
: Codes Copy
Figure 3.4: Procedures for creating and calling the API between PSSNETOMAC and MATLAB.
: Mode 2
: Mode 3
Next, the execution mechanism of the API in time-domain simulation is introduced in Fig 3.5. Note
that, there are some differences between one-level based and two-level based APIs. For the former,
the model codes are copied into API whereas for the latter, the first-level DLL is only called by API
instead of code copy. Then, in time-domain simulation, at instant t0, some specific data from the
linked system node are assigned to the corresponding variables in the model codes (or first-level
DLL). The data are transmitted through the interface macro file and the exported part of API, which
are the exported functions defined in the IEC ESE-Interface template codes. Then, the exported part
of the model codes (or the first-level DLL), which are some exported functions or data, is assigned
18
by the data. After the algorithms of the model, namely some specific functions in the model codes
(or the first-level DLL), are called and executed, the updated model output is returned by the reverse
path to the linked system node, which has been mentioned in section 3.1. After a simulation step, the
simulation loop in PSSNETOMAC proceeds sequentially to next instant t1, which is illustrated by
the time axis in the bottom right corner of Fig 3.5.
: 1) Function Call or
Instant t0
PSSNETOMAC
Exported
Part
Data Access or
Data Assignment
: Execution Sequence
Power System
Model
Linked
System
Node
:d
:d
Model
Codes
API
Interface
Macro File
Exported First-Level
DLL
Part
Exported
Part
Time in API
Instant t1
Time in PSSNETOMAC
t0
t1
t2
t3
Figure 3.5: Execution mechanism of API in the time-domain simulation.
3.3 Introduction to Case Study: A Mathematical Model for API Study

In this section, the case studyof this thesis is introduced. The introduction is focused on two aspects:
a general description of case studyand the aims of this study case. Later, the specific process of
this study case, namely API creation procedures, are described respectively in section 3.4 to 3.7.
Here, a time-domain mathematical model is intended to be linked to PSSNETOMAC through a
specific API. To simplify the study, a simple addition operation of two variables is modelled in
MATLAB, and a simple system with two outputs and one input is modelled in PSSNETOMAC. A
specific API is intended to be created so that at each sampling instant in time-domain simulation, the
two system outputs can be assigned to the addition model through the API and the computed sum is
returned to the system input. If the API is valid, all the operation results during the whole simulation
can be accessed in PSSNETOMAC and they should be correct.
There are two aims of this case study: 1) by this case study, the API creation procedures and other
preparation work can be revealed in the following sections, whose surface is only scratched in the
sections 3.1&3.2; 2) since this case study involves only a simple addition model and input/output
system model, it is suitable for validating the API and debugging the basic program.
19
3.4 Modelling Work in MATLAB

In this chapter, first the modelling platform of case study: MATLAB is introduced, and then two
options for modelling the addition model: MATLAB code and Simulink, are introduced respectively.
3.4.1 Introduction to MATLAB

MATLAB (Matrix Laboratory) is a powerful software package developed by MathWorks Inc. The
original purpose in developing MATLAB is to overcome the limitations of other programming
languages when massive calculation, especially matrix operation emerged from scientific application
need to be performed in computer [3.8]. For that purpose, hundreds of built-in functions that facilitate
those mathematical problems are included in MATLAB. Furthermore, its module: Simulink provides
a powerful custom graphical interface, which enhances the visualization of system modelling and
simulation. However, the most important feature considered in this study is the functionality: code
generation. The aforementioned advantages make MATLAB a general purpose modeling platform
for power system engineers [3.9] [3.3]. Specifically, the MATLAB version in this thesis is chosen to
be 2013b 32-bit which is consistent with the 32-bit based PSSNETOMAC software. Thus, there
will be no interoperability issues that are mentioned in section 2.5.
3.4.2 Modelling Option 1: MATLAB Code

Due to the advantages of MATLAB code as mentioned before, it is widely used for modelling work
in various industrial projects. Thus it is necessary to consider MATLAB code as one modelling option
in the process of API creation. In this subsection, a modelling workflow of the addition model with
MATLAB code is introduced as follows:
1)
Build a new folder and create an M-file (.m file) whose type is: function.
2)
In the M-file, define the data and functions with various MATLAB built-in language features
(but not all). Note that, it is necessary to check the list of available language features listed in
[3.10] before building model in MATLAB code, since the compilation tool: MATLAB Coder
supports only a subset of core MATLAB language features (e.g. program control constructs,
functions and matrix operations) [3.10]. Here, for modelling the addition model, a MATLAB
function: Addition is defined in the M-file as shown in Fig 3.6. There are only two function
arguments input1 and input2 and one return value output1, which however may be
expanded into multiple arguments and return values if required. Furthermore, there could be
more functions and data to define in one or multiple M-files. In this case, data exchange between
model and PSSNETOMAC can be implemented with only argument assignment and return
value access of exported function Addition, since in the coding work, the compilation tool:
20
Figure 3.6: Modelling work with MATLAB code in M-file.
MATLAB Coder can explicitly export only function to external programs.

Later, the model will be coded (also linked) by MATLAB Coder, which is given in subsection 3.5.1.
3.4.3 Modelling Option 2: Simulink

Simulink is a block diagram environment for multi-domain simulation and model-based design [3.11].
With interactive graphical environment, Simulink offers a quick way for modelling work in contrast
to text-programming language. Furthermore, it has integrated solvers, which apply numerical method
to solve the set of ordinary differential equations that represent the model, however in text basedprogramming language solvers should be programmed manually [3.12]. Due to the above reasons,
Simulink is widely used for the modelling work related to control theory [3.12]. Hence, this
subsection gives a modelling workflow of the addition model in Simulink.
1)
Build a new folder and create a model file (.slx file).
2)
Open the model file, a window pops up as shown in Fig 3.7 which is however blank at first.
Then select and add the required graphic components from the Simulink library into the blank
area for building the addition model. As a result, the two ellipses Input1, Input2 are connected
to adder block, and the computed result is sent to the Output1.
3)
Further, click the button Model Configuration shown in Fig 3.7 to set up the configuration of
the Simulink model. Then a new window pops up as Fig 3.8, where in this case only two parts
of the solver configuration (marked with red boxes) need to be set. First, the simulation time is
set as: 0.0s to Inf (infinite)s. Specifying Inf time means the program coded from the model
can run until it is explicitly stopped [3.12], which ensures that the call to the addition model can
21
be persistent throughout the simulation in PSSNETOMAC. Next, in the Solver options,

select the type of solver as Fixed-step whose size is set to 0.001s. This means the compiled
model is intended to be called by external module at each 0.001s. In Simulink, Fixed-step
option is especially required for code generation purpose [3.12]. Then, Solver is selected as
discrete (no continuous states) since discrete solver applies for the model with no states or
discrete states only [3.12] and in this case the addition model has no state. If model has discrete
states, discrete solver computes the time of the next time step by adding a fixed step size to the
current time [3.12], which will be involved in study case.
Later, the model will be coded (also linked) by Simulink Coder, which is given in subsection 3.5.2.
Model
Simulink
Configuration
Library
Figure 3.7: Simulink window for modelling work.
Figure 3.8: Solver pane in Model Configuration Parameters window.
22
3.5 Model Codes or First-Level DLL Generation with Compilation Tools

Referring to preceding sections 3.1, there are three modes for API creation. In case study , the
second and third modes will be adopted. With mode 2, the built model from the preceding section is
coded as standardized model codes; with mode 3, the model is coded and linked as DLL program
(the first-level DLL). And, there are two compilation tools: MATLAB Coder and Simulink Coder.
Later, the compilation work is introduced respectively based on the two compilation tools.
3.5.1 Compilation Tool 1: MATLAB Coder

MATLAB Coder generates standalone C code from MATLAB codes [3.13]. The types of generated
codes may be standardized C-code, static-link library (.lib), DLL, executable program (.exe), etc. At
first, a general workflow of the compilation work for the both targets: model codes generation and
first-level DLL generation, is given as follows:
1)
In the same folder created in subsection 3.4.2, select the Apps tab and click MATLAB Coder
to create a new project (with a postfix: .prj). Then the project interface pops up in Fig 3.9(a).
2)
Add the created M-file into the new project by clicking Add files button. Then the arguments
of the user-defined function defined in the added M-file are automatically identified and listed
below the M-file name. In this case, they are input1, input2. Further, their data types and
dimensions should be selected so that in the compiled C-codes their data types are determined.
3)
Select the Build tab as shown in Fig 3.7(b). Set the Output type to C/C++ Dynamic
Library. If model codes are required (with mode 2), the check-box Generate code only is
checked whereas for first-level DLL generation (mode 3) the check-box is omitted.
4)
Click the Build button. If no code errors are reported, for the mode 2, only the corresponding
program files (the model codes) are generated in an auto-generated folder /codegen/
dll/Addition. And for mode 3, in addition to program file generation, linking work is also
automatically performed by MATLAB Coder to generate a DLL file (the first-level DLL).
Furthermore, by opening / codegen/dll/Addition folder or clicking the View Report button in

Fig 3.9(b), the generated program files can be examined. The file names are listed in table 3.1, and
they are concisely described as follows: 1) rtwtypes.h and Addition.h give necessary type-declaration
of the data that are used in the other program files; 2) the remainder of the files in the first and second
columns are generated for non-signaling initialization and they are requested by Addition_initialize.c;
3) the files in the third and fourth columns include the main functionality of the generated program
and thus their contents are specially listed in table 3.2. Additionally, it should be highlighted that the
generated program files of mode2 are the same as mode 3. In other words, the model codes and the
23
Figure 3.9 (a): Overview tab of project interface.
Header Files
rtwtypes.h
rtGetInf.h
rtGetNaN.h
rt_nonfinite.h
Figure 3.9 (b): Build tab of project interface.
Source Files
Header Files
Source Files
rtGetInf.c
rtGetNaN.c
rt_nonfinite.c
Addition_types.h
Addition_initialize.h
Addition.h
Addition_terminate.h
Addition_initialize.c
Addition.c
Addition_terminate.c
Table 3.1: File names of the generated program files (with MATLAB Coder).
first-level DLL are based on the same program architecture.

There are three different functions in table 3.2, which are declared and defined in the header and
source files respectively: 1) First, Addition_initialize can be called by external module for program
initialization. In its function body, another function rt_InitInfAndNaN(8U) is called for nonsignaling initialization, which is declared and defined by the files in the first and second columns of
table 3.1; 2) Addition contains the core algorithm of the addition model, namely a simple addition
operation. And, the data types of function augment and return value are double, which is consistent
with the previous type-selection in Fig 3.9 (a); 3) Addition_terminate is for program termination.
However, here no terminate code is required. Additionally, in the three .h files, extern declaration
is added for declaring global function so that it can be exported to external module. To summarize,
the architecture of the above-introduced program files is consistent with the description of chapter 2.
24
Addition_initialize.h
Addition_initialize.c
extern void Addition_initialize (void);
void Addition_initialize (void)

{ rt_InitInfAndNaN(8U); }
Addition.h
Addition.c
extern double Addition (double input1 ,
double Addition (double input1, double input2)
double input2);
{ return input1+input2;
Addition_terminate.h
Addition_terminate.c
extern void Addition_terminate (void);
void Addition_terminate (void)
}
{
Table 3.2: The main program files and their core codes (with MATLAB Coder).
3.5.2 Compilation Tool 2: Simulink Coder

Simulink Coder (formerly Real-Time Workshop) generates standalone C/C++ code from Simulink
model [3.14]. The types of the generated codes are similar to the ones of MATLAB Coder. Then at
first, a general workflow of the compilation work for the both targets: model codes generation and
first-level DLL generation, is given as follows:
1)
Open the previously-created Simulink model. Before generating codes, set up the configuration
of Simulink Coder by clicking the Model Configuration shown in Fig 3.7 and selecting the
Code Generation (on the left side of Fig 3.8). Then the pane pops up as shown in Fig 3.10.
Fig 3.10: Configuration window of Simulink Coder (Code Generation option).
2)
To generate different types of code, the system target file (in the red box) should be set. For
model codes, by clicking the Brows, the file ert.tlc with the description: Visual C/C++
solution file for Embedded Coder is selected. Alternatively, other target file, like solution
25
file for Simulink Coder, can also be selected, however the manual linking as subsequent work
is somewhat different. Here, only the first-mentioned target is considered. On the other hand,
for first-level DLL, the target ert_shrlib.tlc with the description host-based shared library
target is selected. Next, after a target file is determined, the Simulink Coder automatically
chooses the available toolchain (or template makefile and make command) [3.6]. Therefore, in
this thesis, the Makefile configuration or Toolchain settings is retained at the default setting.
Additionally, the Language is set as C-code for unifying program language.
3)
Click the Build button. If no error is reported, for mode 2, only the corresponding Visual C
solution files (the model codes) are generated in an auto-generated folder: /model_target_rtw
which is derived from the name of the model and the selected target [3.6]. And for mode 3, in
addition to program file generation, linking work is also automatically performed by Simulink
Coder and a DLL file ( in this case: the first-level DLL) is generated in the current folder.
Furthermore, by opening /model_target_rtw folder or reading the code generation report (if
report-generation is activated in the Report tab shown in Fig 3.10), the generated program files can
be examined and then listed in table 3.3, and they are concisely described as follows: 1) rtwtypes.h
and Addition_types.h have been introduced in subsection 3.5.1; 2) Addition_private.h defines the
required #include of some specific header files; 3) ert_main.c provides a static example to describe
the overall model code execution [3.15]. However, that can be omitted here, since the generated
codes are intended to be called by ESE-interface codes; 4) the remainder of the files include the main
functionality of the generated program and thus their contents are specially presented in table 3.4. In
addition, the program files of mode2 are the same as mode 3. In other words, the model codes and
the first-level DLL are based on the same program architecture.
Header Files
Header Files
Source Files
rtwtypes.h
Addition_private.h
Addition_types.h
Addition.h
ert_main.c
Addition.c
Table 3.3: File names of the generated program files (with Simulink Coder).
There are two data structures and three functions in table 3.4, which are declared and defined in the .h
and .c files respectively. First, two type-definitions of struct variable are performed in .h files. The
first one: ExtU_Addition_T, defines the inputs of the model; the second one: ExtY_Addition_T,
defines the output of the model. And, the data type real_T is defined in the rtwtypes.h as double
type by C-keyword typedef. Further, two struct: Addition_U and Addition_Y are defined as
the two previously-defined struct-type respectively. Note that in this case, the input/output of a
model is defined independently of function, which is different from the case of MATLAB Coder.
Then, basically the three functions include the same contents as the case of MATLAB Coder, except
26
that in the function Addition_initialize, a replacement function rtmSetErrorStatus is defined to

initialize error status and the input/output of model is initialized to 0. Additionally, similar to the case
of MATLAB Coder, extern declaration is also used in .h files to declare global functions and data.
At last, comparing the files in table 3.4 with table 3.2, although there is no difference of program
functionalities, the files and the manner of codes allocation are somewhat different. However, the
basic architecture of the program files in both cases are consistent with the description of chapter 2.
Addition.h
Addition.c
typedef struct {real_T Input1;
ExtU_Addition_T
Addition_U;
ExtY_Addition_T
Addition_Y;
real_T input2; } ExtU_Addition_T;

extern ExtU_Addition_T
Addition_U;
typedef struct {real_T Output1;

} ExtY_Addition_T;
extern ExtY_Addition_T
Addition_Y;
extern void Addition_initialize (void);
void Addition_initialize (void) {

rtmSetErrorStatus(Addition_M, (NULL));
(void)memset ((void*)&Addition_U,0,
sizeof(ExtU_Addition_T));
Addition_Y.Output1=0.0;
extern void Addition_step (void);
void Addition_step (void)
}
{
(Addition_Y.Output1=Addition_U.Input1+
Addition_U.Input2; }
extern void Addition_terminate (void);
void Addition_step (void) {
Table 3.4: The main program files and their core codes (with Simulink Coder).
Respecting the first-level DLL, it should be noted that the linking method is set to explicit linking in
the two compilation tools by default. Referring to chapter 2, after the DLL is automatically generated
by MATLAB, another part of linking work (here: explicitly) should be performed in external module
(the second-level DLL in this case), which will described in subsection 3.6.4.
3.6 API Program (One- or Two-Level DLL) Creation in Visual Studio

After model codes or first-level DLL is generated, it is intended to be called by the ESE-interface
codes for creating the one-level or two-level based API program, which is performed in the Visual
Studio as development environment. In this section, first the introduction of Visual Studio and the
ESE-interface are given. Then, the creation work of the two types of API are introduced respectively.
3.6.1 Introduction of Visual Studio

Visual Studio is a suite of component-based software development tools and other technologies for
27
building high-performance applications [3.16]. It also supports different programming languages and
allows the code editor and debugger to support nearly any programming language. Its built-in
languages include C, C++, VB.NET, C#, F# [3.17] etc. Therefore, the main programming work (with
C-code) of this thesis, namely the creation of the final API program, is performed in Visual Studio.
3.6.2 Introduction of the Extended Simulation Environment Interface (ESE-Interface)

ESE-interface is a generic software-interface allows the use of the same model (compiled form) in
different software environments [3.7]. There are mainly five reasons to adopt ESE-interface for
creating API program: 1) the codes of ESE-interface are written in C language since it is the most
common programming language [3.7], which is easy-to-use; 2) the ESE-interface is presented for
creating a DLL program. By this feature, ESE-interface can be used as a program framework of API
program; 3) the interface provides multiple functionalities and supports for the core requirements in
power system simulation. Then the corresponding API created for different cases can be readily
extended for any specific requirement supported by the ESE-interface; 4) the ESE-interface has been
adopted for creating different APIs that are used for several simulation software [3.3]. Therefore, by
the use of ESE-interface, the created API is portable to the other available simulation software; 5) in
the case that the simulation software is PSSNETOMAC, only the ESE-interface based API can be
linked, since the linking work in PSSNETOMAC is preprocessed according the program structure
of ESE-interface codes, which has been introduced in section 3.1.
Since the codes of ESE-interface are intended to constitute a DLL program, they are allocated into
different program files according to the illustration in Fig 2.4. Then, the program files are listed and
concisely described in table 3.5, where the source file is given in the appendix A. The other files in
table 3.5 are provided by [3.18]. It should be noted that the source file in appendix is only a template
and it should be modified accordingly for different simulation cases.
File Name
Description
ext_simenv_types.h
Macro definitions of data types for use in the ESE-interface codes.
ext_simenv_capi.h
Declaration of the data structures and functions.
ext_simenv_API.c
Definition of the data structures and functions as a template.

Table 3.5: The program files of ESE-interface.
Then, the components of ESE-interface are briefly described referring to [3.7] & [3.18] in table 3.6
where the blue (red) part is data structures (functions). All the functions are intended to be exported
to the external module: PSSNETOMAC, which is represented by the block exported part in Fig
3.6. However, the data structures are local data, and they can only be exported through the calls from
28
PSSNETOMAC to the exported functions. And, the called sequence of the exported functions is
given as the introduction order (top to bottom) of the functions in table 3.6.
Structures or Functions
Description
StaticESEInputSignal
Static input information of model.
StaticESEOutputSignal
Static output information of model.
StaticESEParameter
Static parameter information of model.
ESEExtension
Additional definitions for later extensions.
StaticExtSimEnvCapi
General and static information of the model.
InstanceExtSimEnvCapi
Instance specific model information.
Model_GetInfo
Provides general and static information about the model.
Model_Instance
Creates instance of the model and access specific data.
Model_CheckParameters Checks if the parameters are on the given range.

Model_Loadflow
Performs a load flow iteration.
Model_Initialize
Initializes the program.
Model_Outputs
Performs at each time step and recalculates the model-outputs.
Model_Update
Update state variables.
Model_Derivatives
Calculate derivatives of state variables.
Model_Terminate
Delete model instance and free the memory.
Table 3.6: The components (data structures and functions) of ESE-interface.
3.6.3 One-Level DLL Based API Creation (Mode 2)

Referring to Fig 3.4, when using mode 2 for API creation, the previously-generated model codes and
the ESE-interface codes are intended to be assembled in Visual Studio for creating a DLL. Since
there is only one DLL in the API architecture, the created API is the so-called one-level DLL based
API. And, to section 3.5, there is some difference between the model codes coded by Simulink and
MATLAB Coder. Thus, the both cases are involved in workflow description of this subsection:
1)
Open Visual Studio and create a Win32 project. Next, under the application type, select DLL.
Here, Win32means that the DLL to be generated is 32-bit, and that cannot be changed since
PSSNETOMAC can only call 32-bit DLL due to the interoperability as mentioned before.
2)
Add the program files of ESE-interface and the previously-generated model codes into the newly
-built project by right-clicks of Header Files and Source Files tabs in the Solution Explorer
window as shown in Fig 3.11. In the left figure (a), the model codes are generated by MATLAB
Coder and in right figure (b), the ones are generated by Simulink Coder.
3)
Into ext_simenv_API.c, the header files Addition.h and rtwtypes.h need to be included so
29
that the data and functions defined in the model codes can identified by the ESE-interface codes.
4)
Next, referring to tables 3.5 &3.6, only array variables with the types: StaticESEInputSignal
and StaticESEOutputSignal, and the functions Model_Initialize and Model_Outputs in
appendix A need to be modified correspondingly for different case studies in this thesis. For
case study, their codes are given in table 3.7. And, a struct of type StaticExtSimEnvCapi
may also be modified provided the static information of the API needs to be rewritten.
5)
Finally, choose Build, Build Solution on the menu bar, and then a DLL is generated, along
with an import library (.lib file) which can be used to implicitly link the generated DLL (API
program) with PSSNETOMAC. However, due to encapsulation of PSSNETOMAC, the
actual linking method between the API program and PSSNETOMAC is unknown in this thesis.
Fig 3.11(a): Program files for creating API program by using MATLAB Coder. Fig 3.11(b): Simulink Coder.
Referring to the codes in table 3.7, the first two arrays are defined to declare the input/output attribute
of API program. For example, the input-signal name: Input1, the block path (empty here), the
signal dimension: 1 and the number of input-signals (two braces here) can be accessed in static_
inputs[]. Next, the function Model_Initialize calls Addition_ initialize (defined in the model codes)
to initialize the API program. Here, a DLL_EXPORT (replaces the __declspec(dllexport) by macro
definition) is added for implicit linking, which is introduced in chapter 2. And pInstanceCapi is not
30
used and will be introduced later. On the other hand, even though the function contents of Addition_
initialize given in tables 3.2&3.4 are different, there is no difference between their called procedures
in Model_Initialize. Conversely, the called procedures of model codes from Simulink and MATLAB
Coder are different in the function Model_Outputs. Thus they are described in table 3.7 separately.
First, as the function argument: pointer pInstanceCapi points to a struct including arrays INPUT[]
and OUTPUT[] which correspond to the input/output of MATLAB model. And pInstanceCapi is
also passed into the interface-program of PSSNETOMAC. Thus, the INPUT[] ( OUTPUT[] ) can
be assigned (accessed) by PSSNETOMAC, which enables the data exchange between
PSSNETOMAC and model. Another argument IsMajorTimeStep will not be used in this thesis.
Next, in function bodies, on the right-hand chart, model input (output) is assigned (accessed) by
INPUT[] (OUTPUT[]) by intermediate variable e.g. Addition_U.Input1 defined in Addition.c
of model codes; whereas on the left-hand chart, that can be directly performed through the call of
Addition. Finally, referring to Fig 3.6, through the call to Model_Outputs at each time step,
PSSNETOMAC can update the input of the MATLAB model and achieves the computed result.
const
static_inputs[]
= { { "Input1", "", 1 }, { "Input2", "", 1 }, };
const
static_outputs[] =
{ { "Output1", "", 1 },
};
extern DLL_EXPORT const char* __cdecl Model_Initialize (InstanceExtSimEnvCapi *pInstanceCapi)

{ Addition_initialize( );
return NULL; }
extern DLL_EXPORT const char* __cdecl
extern DLL_EXPORT const char* __cdecl
Model_Outputs(InstanceExtSimEnvCapi
Model_Outputs(InstanceExtSimEnvCapi
*pInstanceCapi, uint32_T IsMajorTimeStep)
{
OUTPUT[0] = Addition(INPUT[0], INPUT[1]);
Addition_U.Input1= INPUT[0];
Addition_terminate();
Addition_U.Input2= INPUT[1];
return(NULL);
Addition_step();
} // MATLAB Coder is used as complication tool
OUTPUT[0] =Addition_Y.Output1;
Addition_terminate();
return(NULL);
} // Simulink Coder used as complication tool

Table 3.7: The modified arrays and functions in appendix A by using two different Coders.
3.6.4 Two-Level DLL Based API Creation (Mode 3)

Referring to Fig 3.4, when using mode 3 for API creation, the previously-generated first-level DLL
is intended to be called by specified ESE-interface codes to create a DLL. As there are two DLLs in
API architecture, the created API is the so-called two-level DLL based API. Since the program
architecture of the first-level DLL generated by Simulink and MATLAB Coder are slightly different,
the workflow of the API creation in Visual Studio involving the both cases are introduced as follows:
1)
Perform the same work as the first step given in subsection 3.6.3.
31
2)
Add only program files of ESE-interface (in the red boxes of Fig 3.11) into the newly-built
project without adding the files of the first-level DLL, since functions and data of the first-level
DLL can be requested by the ESE-interface codes through DLL call. Additionally, provided that
the first-level DLL is generated with Simulink Coder and intended to be explicitly linked to the
second-level DLL, a header file typedef_export.h is also required to be added, which has been
explained in section 2.5. And template codes of this file are provided in appendix B.
3)
Into the source file ext_simenv_API.c, some macro definitions to explicitly link the first-level
DLL with the API program are activated from the program comment in appendix A.
4)
Next, the same array variables and functions as given in table 3.7 also need to be modified in
this case. If typedef_export.h is required, the appendix B also needs to be modified. Then the
modified codes are presented in Fig 3.8(a)&(b) for the cases with different Coders.
5)
Finally, choose Build, Build Solution, and then a DLL is generated with a .lib file attached.
extern DLL_EXPORT const char* __cdecl Model_Initialize(InstanceExtSimEnvCapi *pInstanceCapi)

{
void* handleLib;
// pointer to accept the handle of DLL file
void(*Dll_initialize_ptr)();
// pointer to accept the address of initialization function
handleLib = LOADLIB(TEXT("D:\\MATLAB_Coder\\Addition_DLL\\Addition_win32.dll"));
Dll_initialize_ptr = (void(*)())GETSYMBOLADDR(handleLib, "Addition_initialize");
Dll_initialize_ptr();
return (NULL);
}
extern DLL_EXPORT const char* __cdecl Model_Outputs(InstanceExtSimEnvCapi *pInstanceCapi,
uint32_T IsMajorTimeStep)
{
void* handleLib;
real64_T((*Dll_step_ptr) (real64_T, real64_T); // pointer to accept the address of step function

void(*Dll_terminate_ptr)(void); // pointer to accept the address of termination function
handleLib = LOADLIB(TEXT("D:\\MATLAB_Coder\\Addition_DLL\\Addition_win32.dll"));
Dll_step_ptr = (real64_T(*)(real64_T, real64_T))GETSYMBOLADDR(handleLib, "Addition");
Dll_terminate_ptr = (void(*)(void))GETSYMBOLADDR(handleLib, "Addition_terminate");
OUTPUT[0] = Dll_step_ptr(INPUT[0], INPUT[1],);
Dll_terminate_ptr();
return (NULL);
}
Table 3.8(a): The functions to be modified in appendix A when using MATLAB Coder.
32
typedef struct
{ real64_T Input1; real64_T Input2;} typedef_export_Inputs;
typedef struct
{ real64_T Output1;
typedef_export_Outputs;

{
void* handleLib;
void(*Dll_step-ptr)(void); // pointer to accept the address of step function

typedef_export_Inputs(*Dll_Input_ptr); // pointer to accept the address of the linked DLL input
typedef_export_Outputs(*Dll_Output_ptr); // to accept the address of the linked DLL output
handleLib = LOADLIB(TEXT("D:\\Simulink_Coder\\Addition_DLL\\Addition_win32.dll"));
Dll_step_ptr = (void (*)(void))GETSYMBOLADDR(handleLib, "Addition_step");
Dll_terminate_ptr = (void(*)(void))GETSYMBOLADDR(handleLib, "Addition_terminate");
Dll_Input_ptr = (typedef_export_Inputs*)GETSYMBOLADDR(handleLib, "Addition_U");
Dll_Output_ptr = (typedef_export_Outputs*)GETSYMBOLADDR(handleLib, "Addition_Y");
Dll_Input_ptr->Input1 = INPUT[0];
Dll_Input_ptr->Input2 = INPUT[1];
DLL_step_ptr();
OUTPUT[0]=Dll_Output_ptr->Output1;
return (NULL);
}
Table 3.8(b): The modified functions in appendix A and appendix B when using Simulink Coder.
At last, referring to table 3.8, since the linking method of the first-level DLL is set to explicit linking
by default in MATLAB software, the key words: LOADLIB and GETSYMBOLADDR (replace the
attributes LoadLibrary and GetProcAddress by macro definition) are used to retrieve the addresses
of exported array variables and functions in the first-level DLL. Then, some specific pointers, like
Dll_step_ptr and Dll_Input_ptr that match the prototypes (e.g. parameter and type) of the exported
functions or variables [2.7], are defined to store the retrieved addresses. Later, with those pointers,
the exported part of the first-level DLL program can be used as local codes of the API program (the
second-level DLL). Additionally, the two declaration statements typedef_export_Inputs(Outputs)in
typedef_export.h are modified accordingly for case study. Finally, the remainder of table 3.8 is
similar to the discussion in subsection 3.6.3, which will not be repeated here.
3.7 Power System Simulation Software: PSSNETOMAC

Discussions in this section are related to the software: PSSNETOMAC. At first, an introduction to
33
PSSNETOMAC is given. Next, referring to Fig 3.5, the specific work, i.e. modelling and linking
work in PSSNETOMAC are described. After the simulation of case studyis successfully run in
PSSNETOMAC, the simulation results are presented in the last subsection.
3.7.1 Introduction to PSSNETOMAC

PSSNETOMAC (Network Torsion Machine Control) is a program for simulation, optimization and
design of the dynamic performance in electrical systems that consist of network, machines, and
closed-loop and open-loop control equipment [3.19]. Specifically, the program modules for read-in
and usage of manufacturer DLLs [3.20] are provided, whereby the API program can be invoked by
PSSNETOMAC. On the other hand, in PSSNETOMAC, two modes of time-domain simulation,
instantaneous value mode (EMT) and stability mode (RMS), can be used [3.19]. Then, with the RMS
mode, different case studies of this thesis are simulated in real time.
3.7.2 Modelling and Linking Work in PSSNETOMAC

In this section, the procedures of the modelling and linking work in PSSNETOMAC are described.
Referring to Fig 3.5, the modelling work of a PSSNETOMAC model that is to be linked with the
API is needed, and for the linking work, only an interface macro file is required to be created.
Generally, in PSSNETOMAC a specific power system is modelled. However, for case study ,
only a simple dynamic system is required, which excludes any specific electric power component.
For modelling that, some program files of PSSNETOMAC are created in an operating system folder.
One of them is the main program file (.net file) that defines the major features of the dynamic system.
Another program file (.mac) is created to define a built-in controller (also a user-defined module) of
PSSNETOMAC: EVALUATE. This controller is intended to be the linked system node (given in
Fig 3.5). Further, the codes of EVALUATE are shown in Fig 3.12. In the codes, a specific built-in
module (marked with red boxes) for DLL linking is called and contains two parts: 1) For parameter
definition, #DT is the sample time step at which PSSNETOMAC calls the linked DLL program
once, and #DT should be consistent with a similar time parameter of the model in the DLL program,
like the fixed step size of Simulink configuration (here, #DT is set to 1ms referring to Fig 3.8), or
the step size used for the discretization of a continuous system (related to case study &). The
second parameter #P1 is not used in this thesis. 2) As the main part, u1, u2 and y, which
correspond to the I/O of the model wrapped in DLL, are accessed or assigned by an interface macro
file (AddMod_1Dll_MATCoder). Additionally, there are four interface macro files to be loaded in this
case. These macro files contains links to different DLLs (API programs), which are summarized in
34
section 3.2. Thus, by loading them in simulation, different API programs can be validated. Then, in
the remainder of EVALUATE, the input u1 is set to the value of simulation run-time by calling
time function TIME and u2 is set to a constant. Finally, by the call from the main program file to
EVALUATE, all the variables defined in EVALUATE can be accessed as the simulation results.
Fig 3.12: EVALUATE controller codes.
Next, the procedures to create the aforementioned interface macro file are described as follows:
1)
In the folder that contains the aforementioned program files, create a subfolder DLL and copy
the previously-created DLL file (API program) into it.
2)
Open the main window of PSSNETOMAC and click Tools, Conversion and Others.
3)
In the pop-up window: Conversion, select Manufacturer DLL ->Macro. Then, a select file
window pops up. Next, find the DLL folder and select the DLL file.
4)
Providing the program architecture of the DLL file is based on the ESE-interface and 32-bit, the
DLL file can be identified by PSSNETOMAC and the corresponding interface macro file, e.g.
AddMod_1Dll_MATCoder will be generated in the subfolder DLL, along with a successful
prompt in the status bar of the main window. Then, the content of this file is given in Fig 3.13.
35
Fig 3.13: Content of interface macro file: AddMod_1Dll_MATCoder.mac.
In this file, the Version gives the static information of the linked model and it can be changed by
the modification of the StaticExtSimEnvCapi variable in API program codes, which is mentioned in
subsection 3.6.3. Next, in Link part, the I/O ports for data exchange between PSSNETOMAC
and linked DLL (API program) are listed. Then, in Data, the default values of the model parameters
are given, which are defined in the API program codes. In the bottom, the name of the DLL file to be
linked and the parameters to be assigned by EVALUATE, are listed. Finally, by the file call as shown
in Fig 3.12, the API program is completely linked with the PSSNETOMAC project.
3.7.3 Simulation Result of Case Study

In the end, after all the related work shown in Fig 3.4 is completed, the time-domain simulation can
be executed in PSSNETOMAC. Then, simulation results of the four cases where different APIs are
employed by the calls of the four macro files in Fig 3.12, are consistent with each other. Therefore,
only the result of the first case is given in Fig 3.14. The values of inputs u1 and u2 as set in
36
subsection 3.7.2 are equal to the simulation time and constant 1. Referring to the algorithm included
in the linked model, the sum of u1 and u2 is exactly equal to the output y, namely y = u1+u2.
And the simulated results y of the cases employing different APIs are equal. In conclusion, the API
program can be applied to link the addition model built in MATLAB with the dynamic system model
built in PSSNETOMAC. Furthermore, all the APIs introduced in this chapter, which are based on
different compilation tools and program architectures, are validated. Subsequently, in the following
chapters, the API technology will be employed in the case studies for power oscillation damping.
7.0
Case Study : Addition Model "y=u1+u2"
6.0
u1
Value (no unit)
5.0
u2
4.0
3.0
2.0
1.0
0.0
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
Fig 3.14: Simulation results of case study.
37
4.0
4.5 t (s) 5.0
4 Case Study: Excitation System with Power System Stabilizer (PSS)
4 Case Study: Power System Stabilizer (PSS)

In case study, PSS is employed in one-machine infinite-bus (OMIB) system for power oscillation
damping (POD). To study that case, the OMIB system including a three-phase fault is modeled in
PSSNETOMAC, and PSS is modeled and wrapped into an API program. Next, by calling the API
in time-domain simulation of the OMIB model, functionalities of PSS can be requested for POD. In
section 4.1, power oscillation problem is introduced. Then, the excitation system with and without
PSS and their effects on power oscillation are introduced in section 4.2. Section 4.3 presents the API
creation and OMIB system modelling work to simulate case study. At last, section 4.4 compares
two simulation tests with and without API to validate effectiveness of the API program.
4.1 Introduction to the Power Oscillation Problem

First a general description of power oscillation problem is given by the rotational inertia equations
of machine. Then, an OMIB model is introduced. Based on it, power oscillation problem is further
exposed at two aspects: frequency- and time-domain in this section. Additionally, the OMIB model
will be used in case studies&. At last, oscillation problems are classified into local and inter-area
modes, which will be involved in case study related to multi-machine model.
The essential of the power oscillation problem is a rotor angle related stability problem. Stability is
a condition of equilibrium between the input mechanical torque ( ) and the output electrical torque
( ) of each synchronous machines in an interconnected power system [4.1]. If a perturbation or
disturbance occurs in power system, the equilibrium may be upset, which results in power oscillation.
To clarify that process, the rotational inertia equation describing the effect of unbalance between
and of individual machines [4.1] are introduced in (4.1).
2 2
(4.1)
=
2
0
where the quantities are in per unit form: inertia constant; 0 the rated value of angular velocity;
the angular position of the rotor in electrical radians with respect to a rotating reference
[4.1]; damping torque coefficient; = 0 speed deviation; damping
torque which is induced by the mechanical and electrical damping in the generating set [4.2].
This equation indicates that the unbalanced torque at the right side of equal sign accelerates the
combined inertia of the generator and prime mover [4.1] at the left side.
Then, the OMIB system under a small-disturbance is illustrated in Figure 4.1, where Bus_03 can
be referred to as an infinite bus due to the large size of supplied power system and its voltage 03 is
38
the rotating reference of the OMIB system. In this section, a classic generator model described in
[4.1] is employed. Thus, voltage 1 is the transient voltage behind the transient reactance 1. In
this case, the effect of excitation system is not considered. Hence, the electrical torque in per
unit (= : air-gap power [4.1]) can be expressed in equation (4.2).
01 01
1
XG1
03 0
02 02
X12
Three-Pha se
Transformer
Bus_01
Bus_02
G1
Large
Power
Sys tem
X23
Fault
Line 01
Bus_03 (Infinite Bus)
Figure 4.1: The OMIB system under a small-disturbance.
= =
1 03
sin
1 + 12 + 23
(4.2)
which is substituted into (4.1). Since the disturbance is small, equation (4.1) can be linearized about
an equilibrium point = 0 by small-signal linearized method. The subscript 0 represents
the pre-disturbance state variable. The linearized result of (4.1) is given in (4.3) [4.1].
2 2
(4.3)
=
0
where represents the deviation from the pre-disturbance variable. And = where
is the synchronizing torque coefficient defined in [4.1]. Next, to analyze oscillation problem
in frequency-domain, the characteristic equation of (4.3) is given in equation (4.4).
2 +
0
+
=0
2
2
(4.4)
by which the eigenvalues of the dynamic OMIB system are given in expression (4.5).
1,2 =
1
2 80 = 1 2
4
4
(4.5)
wheree 1 2 is defined as damped frequency and is defined as damping ratio. Then,

by analyzing the two eigenvalues, summaries can be given as below:
1) If < 0, there is always a positive root and the system will lose stability in aperiodic.
2) If > 0, when > 0, the system is stable and after a small disturbance oscillates
damply; when < 0, the system is unstable and oscillates divergently.
To address the oscillation phenomenon in time-domain, when > 0 the free motion time
response of the OMIB system in terms of the eigenvalues of (4.5) is given in (4.6) [4.1].
= (4) cos( )
39
(4.6)
where the parameter and the phase are based on the eigenvectors of the OMIB system
and the initial value of angle deviation: 0 . Analyzing (4.6), the value of determines the
characteristic of the exponential function, namely the amplitude of oscillation, and gives
the frequency of the oscillation. Then based on signs of , (4.6) is depicted in Fig 4.2.
At last, local and inter-area modes of power oscillation problem are introduced in this section:
1) as local mode, the oscillations are localized at one station or a small part of the power
system [4.1]. The typical damped frequency range is 1-2Hz; 2) inter-area mode is associated
with the swinging of the machines in one part of the power system against the machines in
other part [4.1]. The typical damped frequency range is 0.1-1Hz.
As the conclusion of this section, the damping torque coefficient has a significant effect
on oscillation problem. Therefore, for power oscillation damping, a sufficient is required.
Damped Oscillation
> 0, > 0
Divergent Oscillation
> 0, < 0
Figure 4.2: Free motion time response of OMIB system under small-disturbance ( > 0) or ( < 0).
4.2 Introduction to the Excitation System with PSS

In this section, an excitation system with PSS is included into the previous OMIB system. First, the
excitation system with PSS is introduced by block diagrams. Furthermore, the effect of excitation
system (with or without PSS) on the stability problem in the OMIB system is examined.
The performance requirements of excitation system are considered mainly in two viewpoints [4.1]:
1) supply and automatically adjust the field current of synchronous generator to maintain the terminal
voltage of generator; 2) in the viewpoint of power system, excitation system is required to enhance
transient stability of system. And, an ancillary PSS is added for enhancing power oscillation damping.
Then the block diagram of the excitation system with PSS is illustrated in Fig 4.3. U1, U2 and Us are
the intermediate state variables defined for building the state space of the dynamic equations
of the OMIB system. Uref is set-point voltage to be set to a specific value so that the desired
40
terminal voltage Ut of generator can be achieved. Ut, namely the bus voltage 01 in Fig 4.1,
is the input of the excitation system and the field voltage Efd (related to field current) is the
output. Next, the speed deviation is the input of the PSS and Us is the output for
adjusting the sum of U1 and Ut. The blocks of Fig 4.3, as the simplified models of excitation
system ST1A, are described in [4.1] with their functionalities.
Terminal Voltage
Transducer
: Input of PSS
: Output of PSS
Uref
+
U1
Ut
TGR
Exciter
KA
Efd
+
US
Gain
r
(p.u)
Washout
Phase
Phase
Compensation 1 Compensation 2
U2
Power System
Stabilizer (PSS)
Figure 4.3: Functional-block diagram of excitation system with PSS [4.1].
Then, to analyze the effect of the excitation system on system stability, the electrical torque should
be addressed, since the eigenvalues of the OMIB system depends on . Compared to the preceding
section, in this case depends on an added variable: field flux linkage . Then referring to [4.1],
the expression of can still be linearized by small-signal method and given in (4.7) .
= 1 + 2
(4.7)
where 1 and 2 are parameters given in [4.1]. Further, to analyze the effect of excitation system
on , the second term of (4.7) should be addressed , since excitation system influences primarily
the . Then that term can be equivalently transformed into expression (4.8) based on [4.1].
2 = | = | + |
(4.8)
Referring to the discussion in [4.1], when no PSS is added into excitation system, generally the of
(4.8) is positive and the is negative. That means the effect of the excitation system without PSS
is to increase the synchronizing torque component and decrease the damping torque component. Thus,
the power oscillation damping deteriorates. On the other hand, when PSS is added, the contribution
from the PSS to the electrical torque specified in (4.8) can be expressed in (4.9) based on [4.1].
| () = | () + | ()
(4.9)
where the (due to PSS) is intended to be positive to increase damping torque component.
In other words, the transfer function between the PSS-input and the electrical torque
(due to PSS) given in (4.9), should be a pure positive gain, which can be performed by tuning
41
parameters of the phase compensation blocks in Fig 4.3. However, r eferring to the discussion
in [4.1], generally the (due to PSS) in (4.9) is negative, which means the effect of PSS is to
decrease the synchronizing torque component. As a result, with an auxiliary PSS, the power
oscillation damping is enhanced and the non-oscillatory stability slightly deteriorates.
4.3 API Program Creation and OMIB System Modelling

To wrap PSS model, a two-level DLL based API program (mode 3) is adopted. In this section, first,
the creation procedure of the first-level DLL containing the PSS model is described. Then, the
process of API (the second-level DLL) creation is given. At last, the modelling work of OMIB system
and API program call in PSSNETOMAC are presented.
4.3.1 The First-Level DLL Generation in Simulink

Referring to the introduction of chapter 3, when mode 3 of API creation is selected, PSS is modelled
in Simulink and the model is compiled into the first-level DLL by Simulink Coder. First, as modelling
work of PSS, a file (.slx) is created and the respective graphic blocks are added as shown in Fig 4.4.
PSS Parameters:
KSTAB=20
T1=0.05
T3=3.00
Tw=10
T2=0.02
T4=5.40
Limiter: 0.1
u2
Figure 4.4: Simulink window of the PSS model.
The configuration of this Simulink model is set referring to the preceding subsection 3.4.3. Compared
to Fig 4.3, the blocks Washout, Phase Compensation are modelled by controller type: discretetime PD, whose other configuration can be set according to the help document. Furthermore, a limiter
is added into the Phase Compensation 2. And, the input of PSS is represented by the sum of two
blocks: rotor speed and rated value. Next, referring to the procedures of DLL creation described in
subsection 3.5.2, the first-level DLL can be generated.
42
4.3.2 API Program (the Second-Level DLL) Creation in Visual Studio

After the first-level DLL is created, referring to the subsection 3.6.4, the second-level DLL can be
created in Visual Studio environment by modifying the ESE-interface codes (appendixes A&B). The
modified codes are given in appendix C, where the blue part contains the declaration statements of
the API input-output and the red part contains the arrays & functions of the API program. At last, the
other procedures to create the API (the second-level DLL) can be referred to the subsection 3.6.4.
4.3.3 OMIB System Modelling and API Call in PSSNETOMAC

In this section, in the PSSNETOMAC environment, the modelling work of the OMIB system (Fig
4.1) and the linking work to call the previously-created API are described.
First, the parameters of the OMIB system are listed in table 4.1. Then, a .net file as the main program
file and a .mac file defining the components of the OMIB system are programmed. Next, another
program file (.mac) is programmed to define a built-in controller of PSSNETOMAC: EXCITER.
It is used for modelling excitation system of synchronous machine and in this case is also intended
to be the linked system node (given in Fig 3.5). Then, the codes of EXCITER are shown in Fig
4.5. At first, the related parameters are defined in Fig 4.5(a) where the PSS PARAMETERS part
is omitted when API based cross-platform simulation is executed.
G1 : Sr = 900MVA cosr= 0.85 EG1=20kV
U01=20kV U02=400kV U03=400kV
Transformer : SN=400kV UN=400/20kV Uk=15%

Line1 (PI-model) : l=250km
R=0.0278/km
C=14.127nF/km
L=0.255/km
Table 4.1: Parameters of the OMIB system.
In the main part of EXCITER codes, the DLL module to link the second-level DLL (API program)
is programmed according to the introduction given in subsection 3.7.2. Further, a module defining
the pre-disturbance quantities of OMIB model is written for calculating the set-point voltage Uref. In
that module, Efd represents the excitation voltage on d-axis and DE blocks with time constant
1E+6 is used to fix the pre-disturbance quantity.
At last, according to the procedures for creating the interface macro file, which is presented in the
subsection 3.7.2, the API program containing the PSS model can be linked with the OMIB model.
Additionally, to validate the above-mentioned work, a reference test should be performed. For this
purpose, a PSS is modelled with built-in modules of PSSNETOMAC. Thus, the only difference
compared with Fig 4.5 is that the PSS Block in DLL is substituted by the codes given in Fig 4.6.
43
Figure 4.5(a): Parameter definition part of EXCITER controller codes including API module.
Figure 4.5(b): The main part of EXCITER controller codes including API module.
44
Figure 4.6: The PSS model in PSSNETOMAC codes.
4.4 Comparison between Simulation Tests with the PSS Models Included
in API Program and in PSSNETOMAC Program
In the end, after all the related work illustrated in Fig 3.4 is completed, the time-domain simulation
can be executed in PSSNETOMAC. Then, two simulation cases where PSS models are included
in API program and PSSNETOMAC program are performed, and the respective results are given
in Fig 4.7. Here, rotor angle of generator is chosen to be displayed. Next, by analyzing the results,
first it is apparent that power oscillation can be effectively damped in the both cases. Furthermore,
the curves of the two cases coincides. As the relevant conclusions, firstly two-level DLL based API
program is an effective manner for the call by the time-domain simulation of PSSNETOMAC.
Secondly, the PSS model wrapped into that API program possesses the same capability of POD in
the OMIB model by comparison with the PSS model built in PSSNETOMAC.
120
Case Study : PSS Models Included in API Program

and PSSNETOMAC Program
110
1 (degree)
100
90
80
70
60
PSS Modelled in MATLAB
50
PSS Modelled in NETOMAC
40
0.0
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
Figure 4.7: Simulation results of case study(angle of generator 1).
45
9.0 t (s) 10.0
5 Case Study : MPC Based POD Controller
5 Case Study:: Model Predictive Control (MPC) Based Power

Oscillation Damping (POD) Controller
In case study:, MPC based POD controller is employed in one-machine infinite-bus (OMIB) and
multi-machine system respectively. To simulate that, first power system involving three-phase fault
is modeled in PSSNETOMAC, and POD controller is modeled and wrapped into API program.
Next, by calling the API in time-domain simulations of the power system models, functionalities of
the controller can be requested for POD. Section 5.1 introduces general MPC. Section 5.2 describes
the state-space model based MPC and its related state estimation. In section 5.3, MPC based POD
controllers are designed for the state-space models of OMIB and multi-machine system. Then, API
creation and power system modelling work to simulate case study::are presented in section 5.4. At
last, different simulation tests are performed in sections 5.5&5.6 to analyze parameter-tuning issues
of the MPC based controller on two aspects: control performance and robustness.
5.1 Introduction to Model Predictive Control

MPC, also known as Moving Horizon Control (MHC) is a special state feedback control strategy and
is considered as one of the most influencing modern control techniques nowadays [5.1]. On-line
solving of open-loop optimization problem is the major characteristic of MPC [5.2].
To introduce MPC, first a simple case where a general MPC controller is used in a discrete singleinput single-output (SISO) system for set-point tracing, is illustrated in Fig.5.1.
Past
Future
Set Point Sequence (Rp) :

Predicted Output Sequence ( Yp ) :
Computed Control Sequence (Uk) :
Known System Outputs:
Known Control Actions :
y(k)
u(k)
+1
+2
+3
+4
+5
+6
+7
+8
+9
+10
+11
+12
+13
Sampling Instants
__Control Horizon: M __
__Prediction Horizon: P __
Figure 5.1: MPC controller state at kth sampling instant (the current instant).
where filled (hollow) dots denote known (predictive) system information. u(k) and y(k) are the
input-output of the controlled system at kth instant. Rp contains the set-points corresponding to each
46
element of Yp, namely output of the controlled system at each instant of the future P sampling instants
(prediction horizon). Uk contains the control actions on the controlled system over prediction horizon
for set-point tracking. Then, Rp, Uk, and Yp are defined in expressions (5.1a-c), where (k+1|k)
denotes the predicted value of k+1th instant based on the available information at kth instant [5.1].
{( + 1),( + 2), ( + )}=13
(5.1a)
{ ( + 1| ), ( + 2|), ( + | )}=13
(5.1b)
{( | ),( + 1| ), ( + 1| )}=13
(5.1c)
Next, referring to Fig 5.1, set-point tracking can be understood as minimization of the shaded area.
Thus, the control objective of MPC is to minimize an optimization objective function J (Uk) in (5.2).
+
min( ) = (() (|))
(5.2)
=+1
where the sum term represents that shaded area. At last, by combining (5.2) with the mathematical
model in MPC controller and concerning the previous system information (filled dots), Yp and Uk can
be predicted (or computed). Especially, u(k)= u(k|k) is also included in that Uk, which is the reason
to use subscript k. Additionally, to reduce MPC computation, control horizon M is introduced. By
default, M<P and the control moves after k+M are unchanged. Thus, only the first M instead of P
control moves, namely the first M elements of Uk, should be calculated at each sampling instant.
Supposing a solution of (5.2) exists, only the first element of Uk, namely u(k|k), is adopted as control
move of kth instant for the controlled system. At next instant k+1, based on an updated measurement
y(k+1), the above-introduced prediction steps are repeated. And, as the current instant moves
forward (kk+1), the prediction horizon also moves, which accounts for the MHC in Table 5.1:
Sampling
Instant
Horizon Axis
+1
+2 +3 +4 +5
+6 +7 +8 +9
+10
+11
+12
+13 +14
+ 15
k
k+1
Table 5.1 Illustration of Moving Horizon Control (MHC)
The reason why the MPC controller takes only the first control move of Uk :u(k|k), can be explained:
if all the control moves are adopted, the actual control actions from k+1th to k+P:th instant will
only depend on the acquired information at the kth instant. Thus, the external disturbances and modelplant mismatch information, which may be updated after kth instant, are lost [5.2].
Then, the basic procedure of MPC algorithm can be summarized as three steps:
47
1) Update the output of controlled system: y(k) at kth sampling instant;

2) Solve the optimization problem min J (Uk) and obtain the corresponding sequence Uk.
Then, adopt the first element of Uk for controlling the objective system;
3) At k+1th sampling instant, repeat the above steps.
At last, some basic features of MPC can be summarized as below:
Model based prediction: Explicit use of the controlled system model accounts for Model word
in MPC. Since the model can possess a multivariable system framework, interaction issues in
multivariable system can be handled systematically [5.3].
Moving horizon optimization (on-line optimization): Compared to conventional off-line
control strategy, MPC is proceeded on-line repeatedly. Thus, the optimization solution includes
updated information at each sampling instant. Hence, the control action computed with MPC will
be the actual optimal one (not only the theoretical one).
Feedforward-feedback structure: For simplicity, supposing the MPC model is linear system,
an analytical solution of the problem (5.2) can be obtained. Then, feedforward-feedback structure
can be found in that solution. It is one reason that MPC possesses good control performance [5.2].
Well-understood parameter-tuning and easy maintenance: parameters like prediction horizon,
are readily understood for MPC parameter-tuning; furthermore, if the model of the controlled
system is changed, redesign work may be unnecessary for MPC [5.4].
These features may also demonstrate advantages of MPC compared with other control strategies.
5.2 State-Space Model Based MPC

In this subsection, MPC model is specified as state-space. Thus, prediction equations of MPC are
also given based on state-space model. Next, corresponding to the basic procedure of MPC algorithm
as summarized in section 5.1, open-loop optimization and moving horizon control are explained. At
last, since not all the state variables are measured in the subsequent case studies, state estimator is
required and some related estimation issues are discussed in subsection 5.2.3.
5.2.1 State-Space Model and Prediction equations

Mathematical model selection is the primary consideration in MPC. In case study:, the controlled
object is modelled as discrete-time linear system. Thus, the corresponding state-space model should
be selected for MPC and its prediction equations are described in this subsection.
First, the state-space model is given in (5.3) where X(k)nx is state vector; U(k)nu is input vector;
48
Y(k)ny is the output vector. k denotes the current sampling instant and nu or ny is the number of
input or output variables. Compared to the SISO case in section 5.1, form (5.3) is written in bold
letter for MIMO system. For simplicity, neither noise effect nor disturbance are involved in (5.3).
( + 1) = () + ()
(5.3a)
() = ()
(5.3b)
For building prediction equations, increment model of input vector denoted as U(k)= U(k)-U(k-1)
is used. By using that increment model, an integral action is achieved in MPC algorithm. The added
benefit is the simplified implementation procedure, where less steady-state plant information is
required [5.2]. However, integral action is usually not achieved in standard MPC algorithms and is
not necessarily optimal [5.3]. Assuming at the moment k, both X(k) and the previous input vector
U(k-1) (the actual control action on the controlled system) are available. Then, based on the statespace model (5.3a-b), the prediction equations at instant k+1 can be given in (5.4a).
( + 1|) = () + () + ( 1)
( + 1|) = ( + 1|)
(5.4a)
where U(k) is substituted by U(k)+U(k -1). Next, equations at instant k+2 are predicted in (5.4b).
( + 2|) = ( + 1|) + ( + 1) + ()
( + 2|) = ( + 2|)
= 2 () + ( + )() + ( + 1) + ( + )( 1)
(5.4b)
Further, to continue the prediction process until P th instant, all the predicted output vector Y(i|k)
can be included in a global output vector Yp ( ). And it can be expressed in (5.4c).
|
|
( + 1|)
()
|
|
|
( + 2 )
( + 1)
[
]
= () + [
]
+ ( 1)
|
|
( + |) ( )
( + 1) ( )
where
= [
]
=0
=0
(5.4d)

=0
(5.4e)
]

(5.4f)
]
where small index p denotes the prediction horizon value and Uk :is .
5.2.2 Open-Loop Optimization and Moving Horizon Control

49
(5.4c)
In this subsection, first, corresponding to the first two steps of the basic MPC algorithm: open-loop
optimization is introduced. Then to the third step: moving horizon control is introduced.
To solve optimization problem, first, the objective function J (Uk) in (5.2) is recalled. Since it is given
for SISO system and for only one objective: set-point tracking, in the case study:, it should be
expanded into the form (5.5) considering MIMO system, three objectives and weight factor.
() =
=+1
|,
=1
( () (|))| + |,
( ( 1))|
=1
+ |,
( ( 1) ( 1))|
=1
(5.5)
}
The first term as Set-point Tracking is the primary control objective of MPC. ny and j are the
number and order of system output. rj(i)-yj(i|k) is the jth deviation between output and set-point at
sampling instant i. In addition to (5.2), each deviation is multiplied by a weight factor , . Increasing
the factor provides more control energy to the output yj(i|k) for set-point tracking. The second term
is Control Move Rate Suppression. With it, the change rate of control move (action) can be adjusted.
nu is the number of controller output. uj(i-1) is the jth controller output at sampling instant i-1,
and it is multiplied by a weight factor

, . Increasing , leads to a smaller uj(i-1), namely a
smoother change of uj(i-1). The third term of (5.5) is Set-point Tracking of Controller Output.
With it, the controller output can track set-point within prediction horizon [5.5]. ujtarget(i-1) is the
set-point for the jth controller output at instant i-1. Then, increasing , leads to more control energy
for the input uj(i-1). To summarize, the above-mentioned three weight factors and set-points: rj&
ujtarget constitute MPC parameter. By tuning them, different control performance can be achieved.
With the expressions (5.4a-c), objective function (5.5) can be rewritten as a standard form (5.6) [5.5]:
where R(i) and Utarget(i) are set-point vectors contain rj(i) and ujtarget(i-1) given in (5.5). And (5.6
b-d) are diagonal matrices containing the weight factors introduced in (5.5).
( + 1|)
( + 1)
( + 1|)
( + 1)
|
|
( + 2 )
( + 2)
( + 2 )
( + 2)
( ) = ([
][
]) 2 ([
][
]) +
( + |)
( + )
( + |)
( + )
(
()
()
()
()
(
( + 1)
( + 1)
( + 1)
( + 1)
[
] 2 [
]+ [
]
2
(
( + 1)
( + 1)
( + 1)
(
[ ( + 1)])
(
([
50
()
()
( + 1)
( + 1)
[
]
( + 1)
(
[ + 1)]
=
(5.6a)
)
diag(+1,1 +1, , +2,1 +2, , ++1,1 ++1, )
(5.6b)
= diag(,1
,
, +1,1
+1,
, +,1
+,
)
(5.6c)
= diag(,1
,
, +1,1
+1,
, +,1
+,
)
(5.6d)
Finally, substituting the Yp and Uk given in (5.4c) into (5.6), then (5.6) is transformed into (5.7).
() = () + 2( )
(5.7a)
= + +
(5.7b)
= (( 1) + () ) + (( 1) )
(5.7c)
where
=[
(5.7d)
= [
(5.7e)
In (5.7c), Rk=[R(k+1)T, R(k+2)T,, R(k+P)T] T and and Utgt_k=[ Utarget (k)T, Utarget (k+1)T,, Utarget
(k+P-1)T] T are global set-point vectors over the whole prediction horizon. The expressions (5.7a-c)
are derived from [5.5] and [5.6], however effects of noise and disturbance are not considered in this
case. Equation (5.7a) is also of the general quadratic program (QP) form. In (5.7), the matrix H is the
Hessian matrix which is constant during MPC computation whereas is a time-varying vector.
If concerning MPC, the optimization problem of MPC, namely to minimize J(Uk) can be computed
analytically by solving the equation (5.8) where first derivative of J(Uk) equal to zero.
()
=0
(5.8)
whereby the optimal solution with respect to Uk can be given in (5.9) referring to [5.5].
= 1 { + () + ( 1) ( + ) _ }
(5.9)
Each term of the control sequence (5.9) can be explained [5.2]: 1) as Rk contains future set-points for
controlled system, feedforward compensation is included in (5.9); 2) X(k) and U(k-1) provide state
and input feedback compensation which are not only based on the current state variable but also the
previous plant input values. Therefore, the feedforward-feedback structure which is mentioned as
one merit of MPC in the chapter 5.1, can be demonstrated by the above-given simple analysis.
After obtaining the optimal control sequence Uk*, only the first element of this sequence U(k) is
adopted and the rest of Uk are discarded, which is shown by (5.10): (here : nu nu identity matrix)
51
() = [
(5.10)
Prediction Horizon
Then, to analyze the closed-loop dynamic characteristic of MPC control system, (5.10) is substituted
into (5.4a) to achieve (5.11) whereby the eigenvalues of MPC closed-loop control system can be
computed. In (5.11), terms in ( ) have no effect on the eigenvalue analysis so they are not given.
( + 1|) = () + ( )( 1) + ( )_ + ( )
=
(5.11)
Finally, block diagram for illustrating control mechanism of MPC is given in Fig 5.2 where 1 =
[
]1 , 2 = [
]1 are parameter matrix.
Two notes for Fig 5.2 are: 1) if not all the state variables are measurable, namely Y(k)X(k), state
(|) will substitute X(k) in (5.4c) for the following
estimator is needed. Then, the estimated state
optimization computation; 2) similar to generalized predictive control (GPC) and dynamic matrix
control (DMC), an integral component Z/Z-1 is also involved in MPC algorithm.
Plant
Y (k)
X (k +1 )= AX (k )+ BU (k )
Y (k )= CX (k )
U (k)
Z
U(k 1 )
Estimator
Z
Z/Z-1
Iu
U(k 1 )
Su1
U(k)
KMPC1
KMPC2
MPC
Controller
Utgt_k
Sx
X (k | k )
Rk
Figure 5.2: Block diagram of unconstrained MPC
Next, at k+1th sampling instant, information of the controlled system, like Y(k), is updated. Then,
based on the updated information, the open-loop optimization is proceeded over another P prediction
horizon. And, that loop procedure accounts for the moving horizon control.
5.2.3 State Estimation

In this subsection, estimator in Fig 5.2 will be introduced in detail. With estimator, state variable can
be estimated based on the only measured information from controlled system. Concerning different
52
estimator models and design methods, in this thesis, current estimator model [5.7] and two methods
for estimator gain design: pole-placement and Kalman filter are adopted and discussed.
Before introducing current estimator, two terms: current- and predictive estimation should be defined:
1) the estimation that is performed at the current instant for estimating state variable of current instant;
2) the estimation that is performed at the current instant for estimating state variable of next instant.
Then, assuming at the current instant k, the real output of controlled system is Y(k). When white noise
(V(k)) is added on the measuring-channel of Y(k), the real measured plant output is Yv(k) in (5.12a).
() = () + ()
(5.12a)
(| 1), the current

Next, based on (5.12a) and the predictive estimation at the k-1th instant:
(|), which is used in Fig 5.2&5.3, can be given in (5.12b).
estimation at kth instant:
(|) =
(| 1) + ( ()
(| 1))
(5.12b)
where C is system input matrix and M is estimator gain which can be designed by pole-placement
(|) is dependent on the current measurement (), it provides
and Kalman method. Because
fast response to unmodeled disturbances or measurement errors [5.8] and it accounts for the name
Current Estimator. Finally, the predictive estimation at the kth instant is given in (5.12c):
( + 1|) =
(|) + ()
(5.12c)
where U(k) is the control action at the kth instant. And B is system input matrix. U(k) is updated
instantly from MPC controller. If there is difference between the U(k) computed by MPC and the real
control action on the controlled plant, the estimator adopts the real control signal for estimation.
Finally, the block diagram of estimation process is highlighted in Fig 5.3.
To analyze dynamic characteristic of estimation system, first, the actual state variable X(k+1) is given:
( + 1) = () + ()
(5.13a)
Then, estimation error between actual- and estimated state variable is defined as ( + 1) =
( + 1|). Next, subtracting (5.12c) from (5.13a) and substituting ( + 1) into it:
( + 1)
(|))
( + 1) = (()
(5.13b)
Next, substituting (5.12b) into (5.13b), finally the state-space equation of estimation error is given:
( + 1) = ( )() ()
(5.13c)
which assumes Y(k)=CX(k). Expression (5.13c) demonstrates that by choosing different matrix M,
the eigenvalues of A(I-MC) are different. Therefore the convergence rate of estimation error to zero
can be manipulated. If the eigenvalues are mainly located close to the origin of complex plane, the
estimation error system possesses a good dynamic characteristic. Additionally, M also determines
the effect of the output noise V(k) on the estimation error system. Hence, M (also named as estimator
gain) is a critical parameter in estimator design and the design methods of M are various. A proper
53
(|)
M is critical for the estimator based MPC, since referring to (5.7a-c), whether the estimated
can track the real X(k) accurately and fast, determines the validity of the MPC optimization solution.
Plant
U (k)
Y (k)
X (k +1 )= AX (k )+ BU (k )
Y (k )= CX (k )
U (k)
X (k + 1 | k )
X (k | k 1 )
Z
V (k)
Yv (k)
A
MPC
Controller
Rk
X (k | k )
Current Estimator
Utgt_k
Figure 5.3: Block diagram of current estimator
At first, pole-placement method is introduced for estimator gain design. There are three prerequisites
to use pole-placement: 1) The plant system to be estimated contains no noise effect (e.g. no V(k) in
the form (5.12a)) [5.8] [5.9]; 2) If arbitrary pole placement is required, the plant system should be
observable [5.10][5.11]. In [5.10], example 1.8 demonstrates that the unobservable pole cannot be
affected by estimator, which leads to a degradation of estimation performance; 3) the poles of the
plant system should be well-known [5.12] so that the new poles can be designed correspondingly.
Three notes for using pole-placement referring to [5.8] are given: 1) Avoid placing multiple poles at
the same location; 2) Moving the poles that are weakly controllable or observable, will result in high
estimator gain. The estimator with high gain is sensitive to disturbance or uncertainty, as a result it
can reduce robustness of the corresponding MPC controller; 3) in high-order problem, some choices
of pole locations result in very large gains. These notes restrict the use of pole-placement method.
Kalman filter technique, also known as optimal estimation [5.8], provides an alternative to design
estimator gain. Three notes to use Kalman filter method: 1) generally, the system to be estimated
should contain noise effect for constructing Kalman filter equations. If the noise effect is neglected,
to ease the solvability of the Kalman filter design, a mathematical trick that additional unmeasured
white noise is added on each output channel (V(k) in 5.14a), is adopted [5.5]. 2) The condition that
the system is observable is weakened in Kalman filter design, and the system only needs to be
detectable. 3) The Kalman filter is also a pole-placement method, but these poles are selected
54
through rigorous use of known statistical properties of the process and measurement noise [5.12].
Unlike pole-placement method, new poles of the estimation error system are not required to be
determined manually. In other words, the design procedure of Kalman filter is constructive: given a
system model, an estimator gain is automatically computed by the optimal procedure. The optimality
of the optimal procedure represents the best ratio of signal power to noise power [5.13] and the
procedure can be referred to [5.7]. Firstly, the measurement noise covariance matrix R is defined by:
E{V(k)V(k)T}=R, where E{} represents expectation calculation. Then, the covariance matrix of
estimation error is minimized and the minimized value is defined as P:
(5.14)
= lim {()() }
Finally, the estimator gain M is derived by solving a Riccati equation:

= ( + )
(5.15)
One thing to note if using Kalman filter method is that: the matrix R should be a nyny (ny: number
of measured plant outputs) diagonal positive-define matrix. Namely, the measurement noise term R
in the estimator model cannot be empty, which has been mentioned in the beginning of this subsection.
5.3 Introduction to the MPC Based POD Controller

In this section, the cases in which MPC based POD controller is used in the OMIB or multi-machine
system, are introduced respectively in two subsections. First, the state-space models of the two cases
are given, along with the functional-block diagrams of controllers. Then, their eigenvalues are given
and analyzed. At last, MPC parameters for those two cases are specified.
5.3.1 MPC Based POD Controller in OMIB System

In chapter 4, differential equations describing dynamic characteristic of power system is linearized
by small-signal method. Further, by defining state variables from differential equation, a state-space
model can be built. Here, based on the OMIB system illustrated in Fig 4.1, the classical generator
model in section 4.1 is extended to a seven-order state-space model referring to [4.1], which is of the
form (5.3), including the effects of excitation system and amortisseur. Next, that continuous model
is discretized with sample time 1ms to a discrete model, whose state variables are given in (5.16)
() = [1 () 1 ()
1 ()
11 ()
11 ()
21 () 1 ()]
(5.16)
Further, the control matrix and the output matrix in form (5.3) are determined by selecting ()
and () shown in Fig 5.2 &5.3. In this case, the MPC based POD controller is intended to operate
in a similar manner to the PSS (Fig 4.3), so the PSS output Us1 is still adopted as the (). For (),
in addition to the original PSS input: 1 (), rotor angle deviation 1 () is also accessed from
55
the OMIB model for improving state estimation. Then, the block diagram of the POD controller as a
replacement for PSS in excitation system is given in Fig 5.4. However, compared with Fig 4.3, a
(|) contains the
block TGR (transient gain reduction) is added in this case study. Then,
estimated state variables of (). And recalling Fig 5.2, Rk is set-point vector to the (), which
may be assigned in real-time. However, Utgt_k is held at constant value, so it is not shown in Fig 5.4.
: Input of POD Controller
: Output of POD Controller
Terminal Voltage U1
Transducer
(Discrete-Time)
Ut
():
r1
(p.u)
1
(degree)
Uref
(|)
TGR
Exciter
Efd
KA
+
(): US1
MPC
Estimator
MPC Based
Rk
POD Controller
Controller
Figure 5.4: Functional-block diagram of excitation system with MPC based POD controller.
Then, the eigenvalues of the OMIB model are listed in table 5.2, where Freq. is damped frequency
and Damp. is damping ratio defined in section 4.1. Here , , and are oscillation
eigenvalues (oscillatory modes) and the mode of , with zero damping ratios is the dominant
oscillatory mode that should be addressed in the following simulation tests.
Eigenvalues
Freq.(Hz) Damp. (%)
Eigenvalues
Freq.(Hz)
Damp. (%)
1 = 0.9476
0.0
100
, = 0.9 8 0.0060
1.561
86
2 = 0.9602
0.0
100
, = 0.9833 0.0096
0.962
= 0.9963
0.0
100
Table 5.2: Eigenvalues of the OMIB system model.
Furthermore, observability measures of those eigenvalues and participation factors of state variables:
1 ()& 1 () (also output () of the OMIB model) in each eigenvalue are given in table 5.3.
Eigenvalues
1
Observability
1
1
2.8e-04
0.0016
Participation
1
1
0
0
0.0014
0.0106
0.0048
0.4049
0.05
0.05
Eigenvalues
,
Observability
1
1
0.0036 0.0574
Participation
1
1
0.02
0
0.0185
0.5
0.9622
0.5
Table 5.3: Observability measures and participation factors relating to the eigenvalues.
Here, observability measure (OM) is used to indicate the pole-placement range of those eigenvalues
when using pole-placement method for estimator design, which will be involved in the subsection
5.5.1. And to calculate the OM, the geometric approach is adopted, which can be referenced in [5.14].
And, participation factor (PF) is a measure of the relative participation of the state variable in some
56
mode, whose concept and calculation approach are detailed in [4.1]. In this case, when some specific
mode(s), like & , needs to be addressed in control process, 1 () or 1 () which possesses
a higher PF in that mode should be offered with more priority of control. For the control priority, the
MPC parameters in form (5.5) relating to 1 ()&1 () will be set specifically later.
At last, the MPC parameters of form (5.5) are specified for this OMIB case and summarized in table
5.4 where & means different values will be set in the following simulation tests. Then, the primary
objective of the MPC based POD controller is to minimize the deviation variable of () whose
participation in oscillatory modes is relatively active. And referring to table 5.3, the PFs of
1 () and 1 () in the dominant oscillator mode & are both equal to 0.5. Thus, r1 & r2
may be both held at zero and & at 1 during simulation. However, since the OMIB model has
two outputs and only one input, the degree of freedom to keep all the outputs at set-points is not
insufficient. Hence, it is proposed to specify different priorities for the two outputs [5.15] [5.16].
Thus, in this case is set to 0.05 as low priority and set to 1 as high priority. Additionally,
0 guarantees a positive-definite Hessian matrix, which will be proposed and exposed in subsection
5.5.4 referring to [5.15]. At last, one thing to note is that those weighting parameters are kept at
constant during simulation. Therefore, their subscripts specifying some specific sampling instant,
namely i in form (5.5), are not shown here anymore.
Parameter
Control Horizon (CH)
Value
5&20&80
Parameter
Prediction Horizon (PH)
Value
200&500&800
Reference of 1 (): r1
Weight of 1 ():
0.05
Weight of 1 ():
Weight of control Us1:
0.1&0.5&1 Weight of control rate Us1:

0.1&0.5&1
(Model.Nominal)
Table 5.4: Parameters in the simulation case of OMIB system.
5.3.2 MPC Based POD Controller in Multi-Machine System

In this subsection, MPC based POD controller is used in a multi-machine system as shown in Fig 5.5,
where the multi-machine system and its related parameters are given in the example 12.6 of [4.1].
Similar to the case of subsection 5.3.2, the MPC based POD controller is intended to operate in a
similar manner to the classic PSS, namely adopting similar controller input/output. Here, the control
scheme of this MPC based POD controller is designed to be a centralized agent [5.17]: a control
entity whose data acquisition and control range can be throughout the whole power system. Therefore,
the centralized MPC module accesses the global signals: angle and speed of each generator (red lines)
at every 5ms (sample time) and then it computes four instantaneous control actions to the excitation
57
system of each generator (blue lines). Furthermore, it can access the model information of the multimachine system, i.e. the system configuration that can be represented by a set of nonlinear equations.
Next, based on the model information at every sample time, a discrete state-space model of the multimachine system can be achieved by small-signal theory as the model of MPC. One thing to note is
that the system state equations are formulated based on absolute changes in generator speed and a
reference generator angle of G2. Therefore, the state variable of the generator angle of G2 as
well as its state equation is canceled. Furthermore, the system state space will have a zero eigenvalue
due to the redundant generator speed, i.e. all the generator torques are assumed to be independent of
speed deviations [1.10]. As a result, this model contains 31 state variables, part of which are similar
to (5.16) however respecting the dynamics of all the four generators, and the remainder of them are
four defined auxiliary state variables for building the state space. Furthermore, similar to the previous
(|) are the estimated state variables and Rk is the set-point vector to the
description in 5.3.1,
outputs of the power system (or to the inputs of the MPC controller).
r1
1
r3
3
r2
2
MPC Based
POD Controller
r4
4
Estimator
(|)
US1
US4
US2
MPC Controller
US3
: Input of POD Controller

: Output of POD Controller
Rk
Figure 5.5: Multi-Machine System with MPC based POD controller.
Then, the dominant oscillatory mode of the multi-machine system are listed in table 5.5, where Freq.
is the damped frequency and Damp. is the damping ratio (in percent) defined in section
4.1. Dominant means the mode has the least damping compared to the other modes. In this case,
it even has a negative damping ratio, which can lead to the oscillatory instability of power system.
Therefore, this mode should be addressed for POD controller design. Furthermore, it is shown that
all the dominant state variables (3 , 3 , 4 , 2 ) of this mode are measurable. Hence, three
conclusions can be drawn: 1) the system is ensured to be at least detectable. Then, the precondition
to use Kalman filter for state estimation is satisfied; 2) tracking the set-points of those dominant state
58
variables will be adequate to mitigate the dominant oscillation in this case; 3) the participation factors
and also the mode shape analysis [1.10] show that this mode is inter-area mode.
Modes (Eigenvalues)
1.0002 0.0178
Freq.(Hz) Damp.(%)
Dominant States with Participation Factors
0.590
-2.3
3 {0.33}, 3 {0.21}, 4 {0.19} , 2 {0.12}
Table 5.5: Dominant oscillatory mode and the related participation factors.
Then, the MPC parameters specified for this multi-machine case are listed in table 5.6.
Parameter
Value
20
Parameter
Weight of 2 ():
Weight of 1 ():
Value
500
Reference of 1 () : r3
degressive r3(k) Weight of 1 () :
degressive r5(k) Weight of 3 () :
Weight of 4 ():
Weight of 4 () :
Weight of control Us1:
(Model.Nominal)
Us2:
Us3:
Us1:
(Model.Nominal)
(Model.Nominal)
(Model.Nominal)
Weight of control
Weight of control
Weight of control
Weight of 3 ():
0.03
1
1
1
0.04
1
Weight of control rate Us1:
1
1
1
Table 5.6: Parameters in the simulation case of the multi-machine system.
And recalling the form (5.5), the primary objective is still to minimize the deviation variables of the
vector (). By reviewing the discussion in subsection 5.3.1, theoretically, all the reference, namely
the set-points to (), can be set to zeros, and since the multi-machine model has eight outputs
(elements of ()) and only four inputs (elements of ()), the weights are proposed to be set
at different values according to their priorities [5.15]. Generally, the priority allocation is based on
the participation factors of system outputs in the mode of interest [1.28]. However, in this multimachine case, concerning the control robustness issue which is maybe caused by model mismatch
issue (between the model used in MPC and the real multi-machine system model), two adjustment
schemes are tested: 1) the set-points r3 and r5 are set to time-varying values, namely r3(k) and r5(k),
as some specific percentage of the instantaneous values of 1 () and 3 (). The percentage can
be adjusted for a trade-off between control response and robustness. Thus, the set-point tracking of
these two outputs are suppressed (provided with less control energy). 2) Weights and are set
to extremely small values to suppress the set-point tracking of the two outputs: 1 () and 4 ().
59
As a result, by the suppression of set-point tracking, the robustness problems probably caused by the
aggressive control energy for some specific output(s) can be eliminated. Furthermore, although the
two adjusting methods have similar effects on suppression of set-point tracking referring to the form
(5.5), practically, for this simulation case a well-defined rule to tune the parameters for enhancing
robustness has not emerged. The reason could be the model mismatch or complex parameter coupling
in this multi-machine system. In addition, the target of control action and its related weight
are kept at default: 0, since the freedom degree of the multi-machine model is not enough
(eight system outputs and only four inputs) [5.15]. At last, the other parameters are kept at
the values in table 5.6 without extra analysis.
5.4 API Program Creation and Power System Modelling

In this section, two MPC based POD controllers for the OMIB and multi-machine cases, which are
described in subsection 5.3.1&5.3.2 respectively, are wrapped into the API by the hybrid mode.
Firstly, the creation procedure of the first-level DLL which contains the controller model is described.
Secondly, the process of the API (the second-level DLL) creation is presented. Thirdly, the modelling
work of the OMIB and multi-machine system, and the API call in PSSNETOMAC are presented.
5.4.1 The First-Level DLL Generation in Simulink

Referring to chapter 3, when using the hybrid mode for API creation, the MPC based controller is
modelled in Simulink with the integrated module (block) provided by Model Predictive Control
Toolbox and the built model is compiled into the first-level DLL by Simulink Coder.
First, the MPC based POD controller for the OMIB case, is modeled with the integrated block MPC
Controller and respective graphic blocks in Fig 5.6 (a). The configuration of this Simulink model is
set referring to the preceding subsection 3.4.3. DSp1 and Dag1 are 1 () and 1 (). DSp1r
and Dag1r are their set-points. POD1 is the controller output, namely control action Us1 to the
excitation system. Furthermore, a digital clock block is added to output the call time of the controller
model. Then, by compared to the simulation time of the power system model in PSSNETOMAC,
the synchronism between MATLAB and PSSNETOMAC can be detected.
Next, the MPC based controller for the multi-machine case, is modeled in Fig 5.6 (b). There are seven
controller inputs as well as their set-points and four control actions to the excitation system of each
generator. The other configurations are similar to the case of Fig 5.6 (a). Finally, the first-level DLLs
of the two models in Fig 5.6 can be generated referring to the subsection 3.5.2.
60
Figure 5.6: Simulink model of the MPC based POD controller for (a) OMIB; (b) multi-machine case.
61
5.4.2 API Program (the Second-Level DLL) Creation in Visual Studio

After the two first-level DLLs are created, referring to the subsection 3.6.4, two second-level DLLs
can be created accordingly in Visual Studio environment by modifying the ESE-interface codes in
the appendixes A&B. The modified part of appendixes are given in appendixes D&E, where the blue
part contains the modified declaration of the API input-output and the red part contains the modified
arrays & functions of the API program. Furthermore, the other procedures to create the API program
(the second-level DLL) can be referred to the preceding subsection 3.6.4.
5.4.3 OMIB & Multi-Machine System Modelling and API Call in PSSNETOMAC
In this section, in PSSNETOMAC environment, the OMIB and multi-machine system as illustrated
in Fig 4.1&5.5 are modelled and the respective linking work to call the previously-created APIs is
described. The relevant parameters of the OMIB system are listed in table 4.1 and the ones of the
multi-machine system are given in the example 12.6 of [4.1].
First, a .net file as the main program file and a .mac file defining the components of the OMIB and
multi-machine system, are programmed for modelling the power system. Since the control action of
the MPC based POD controller is employed by excitation system of each generator, another program
file (.mac) is required to define the built-in controller of PSSNETOMAC: EXCITER, which is also
the linked system node (in Fig 3.5). The codes of EXCITER for the multi-machine case are given
in Fig 5.7, and the parts in red boxes can also applied for modelling the OMIB system.
First, the required parameters are defined in Fig 5.7 (a) which is similar to Fig 4.5(a) except for the
addition of the equilibrium points of generator angle. Next, the generator angles and speeds are
measured in real time from the multi-machine model in Fig 5.7(b). Then the set-points to these angles
and speeds are defined in Fig 5.7(c) based on table 5.6. Further, the DLL module for the OMIB and
multi-machine cases are presented in Fig 5.7 (d)&(e). For multi-machine case, EXCITERs for the
other three generators adopt the control moves computed in Fig 5.7(e), which is described in Fig 5.7
(f). At last, the codes in Fig 4.5(b), which define the pre-disturbance quantities and the AVR module,
are invoked for this case study. And, a TGR module (shown in Fig 5.4) is also modeled (Fig 5.7 (g)).
At last, according to the procedures for creating the interface macro file (in the subsection 3.7.2), the
API programs containing the MPC based POD controller model can be linked with the power system
models. Additionally, to validate the above-mentioned work, reference simulation tests involving a
classic PSS should be performed, which has been presented in subsection 4.3.3 with an additional
TGR block (transient gain reduction).
62
Figure 5.7(a): Parameter definition part of the EXCITER codes for multi-machine case.
Figure 5.7(b): EXCITER codes defining the outputs of the multi-machine system.
63
Figure 5.7 (c): EXCITER codes defining the set-points to the outputs of the multi-machine system.
Figure 5.7 (d): The DLL module of the EXCITER codes (for the OMIB case).
Figure 5.7 (e): The DLL module of the EXCITER codes (for the multi-machine case).
Figure 5.7(f): Control signal access in the EXCITER codes of G2.
Figure 5.7(g): The TGR module of the EXCITER codes.
64
5.5 Simulation Tests for Analyzing Different MPC Based POD Controller
in OMIB System
In 5.5.1, state estimator as an integrated part of MPC module is analyzed. From subsection 5.5.2 to
5.5.4, some kernel parameters of MPC aforementioned in section 5.4 are analyzed respectively by
different simulation tests. Finally, a conclusion of this section is given in 5.5.5.
5.5.1 Test 1: Different State Estimator Based POD Controllers

As introduced in subsection 5.2.3, two methods for estimator gain design: Kalman filter and poleplacement are studied and compared based on three aspects: 1) closed-loop eigenvalues of estimation
error system; 2) estimator gain; 3) time-domain simulation results. For the 3), two simulation cases
are performed: firstly, the POD performances between the MPC controllers based on the different
estimation methods are compared. Secondly, an unmodeled disturbance is added into the simulation
for comparing the effects of different estimation methods on the control response and robustness.
As described in subsection 5.2.3, the prerequisites and notes for using pole-placement are checked
before estimator gain computation. First, noise effect is neglected in simulation tests. Next, based on
the analysis of table 5.2&5.3 in subsection 5.3.1, the OMIB model is proven to be detectable and
some notes respecting the pole-placement are obtained: 1) 1 & 2 should not be moved since their
dominant state variables are not measurable. In other words, they are unobservable; 2) 3 & 4 can
be moved much closer to the origin since system outputs: 1 ()&1 () have high participation
factors (PF) in 3 & 4 . In other words, they have strong observable measures; 3) 5 & 6 & 7 can be
moved weakly towards the origin since 1 ()&1 () have low PF in them. Concerning these
notes, the proposed eigenvalues (new poles) of estimation error state-space are given in table 5.7.
1 = 0.9476
2 = 0.9602
, = 0.6500 0.0060
= 0.9750
, = 0.9650 0.0096
Table 5.7: Eigenvalues of estimation error state-space based on pole-placement method.
Then, these eigenvalues are illustrated in Fig 5.8 by green circles. Referring to the expression (5.13c),
first, assuming that the gain matrix M is omitted in the expression, the eigenvalues (in table 5.3) of
are only determined by the matrix A and they are represented by red diamonds in Fig 5.8. Then, since
the third and fourth eigenvalues locate on unit circle, the estimation error system is unstable, which
means the estimated state variables will deviate from the actual state variables gradually. Hence, by
using pole-placement, the eigenvalues of table 5.3 (red diamonds) are shifted to the table 5.6 (green
circles). Thus, the estimation error system is stabilized. Furthermore, the estimation error system of
65
which eigenvalues closer to the origin, possesses a better dynamic characteristic.

0.08
No Estimator
Pole-placement
0.06
Unit Circle
Kalman Filter
Imaginary Axis
0.04
0.02
Real Axis
0
0.9
0.92
0.94
0.96
0.98
1.02
-0.02
-0.04
0.02
0
0.5
-0.06
0.6
0.7
-0.02
-0.08
Figure 5.8: Eigenvalues of estimation error system based on different estimators.
By using the function place provided by Control System Toolbox in MATLAB, referring to the
desired eigenvalues in table 5.7, the pole-placement based gain MPP is computed and given in (5.14):
70.438 0.261 225.910 106.000 337.447 177.521 57.249
PP = [
]
0.256 0.176 748.177 745.722 731.488 715.839 14.319
(5.14)
Based on the calculating procedure of Kalman filter gain in subsection 5.2.3, MKF is automatically
computed in (5.15) by using Kalman filtering provided by Control System Toolbox.
KF = [
0.016
0.038
0.038 11.710 4.710 0.008 0.059 2.003

]
0.143 18.917 9.342 0.020 0.121 4.095
(5.15)
In comparison with MPP, the values of Kalman filter gain is much smaller.
Then, the eigenvalues of estimation error state-space (5.13c) using Kalman filter are given as below:
1 , 2 = 0.9600 0.0702
3 = 0.9958
= 0.9509
, = 0.9359 0.0121
= 0.9606
Table 5.8: Eigenvalues of estimation error state-space respecting Kalman filter.
These eigenvalues are represented by the violet pluses in Fig 5.8 and are located inside the unit circle,
which means that the estimation error system is stable. The order of closed-loop eigenvalues of A(IMC) matrix in table 5.8 do not match the original eigenvalue order of A matrix in table 5.3. In other
words, by using Kalman filter method, the estimation error state-space are reconfigured compared to
the original state-space (5.13a). It implies that the kernel algorithm of Kalman filter is different from
pole-placement method. Additionally, compared to table 5.7, overall the eigenvalues in table 5.8 are
further from the origin, i.e. the pole-placement based estimator has a better dynamic characteristic.
66
As the MPC parameter: prediction horizon (PH) shows significant impact on the control performance,
which will be revealed in subsection 5.5.2, in the simulation case 1 two PH are tested respectively.
And the other MPC parameters can be referred to table 5.4. Furthermore, the simulation result of the
comparison test in section 4, which includes a classic power system stabilizer (PSS) modelled in
PSSNETOMAC, is also compared to the cases including the MPC based POD controller.
The simulation results of case 1 are given in Fig 5.9 and they show that power oscillation in all
simulation cases can be damped effectively. MPC with a higher prediction horizon possesses a better
damping performance, which will be detailed in subsection 5.5.2. In Fig 5.9 when using the same
PH, there is only a subtle difference of damping performance between the different estimation based
MPC controllers. Strictly speaking, the pole-placement based controller has a slightly better damping
performance than Kalman filter. One reason could be that pole-placement based estimator has a better
dynamic characteristic in estimation error system, which has be demonstrated by table 5.7. In some
specific case, better dynamic characteristic can enhance a faster actual value tracking, namely a better
estimation. Hereby, the corresponding MPC controller can provide better control action for POD.
110
Case 1: Estimator Comparison
1 (degree)
100
90
80
3ph-150msfault
70
Kalman filter method

Pole-placement method
Kalman filter method
Pole-placement method
Classical PSS
60
50
0
PH=200
PH=200
PH=800
PH=800
t (s)
Figure 5.9: MPC using two types of estimators (angle of generator 1).
As mentioned in subsection 5.2.3, the value of the estimator gain can affect the robustness of the
corresponding MPC controller. For testing robustness of MPC controller, an unmodeled disturbance
is added to the closed-loop system, and reviewing the form (5.12b), the actual controller input ()
is affected by the unmodeled disturbance. Because the disturbance is unknown, the information of
disturbed () cannot be obtained or anticipated anymore based on the existent model used in the
estimator, and as a result the estimation is ineffective. Even neither of two types of estimators are
effective, compared to lower gain, the high gain based estimator computes a more deviated estimation
67
(|) which will be used in the optimization computation of MPC. The reason is that the high gain
based estimator is more seriously affected by the disturbed () due to product term ( ()
(| 1)). Based on a deviated estimation
(|), the MPC controller computes an ineffective
control action under which the dynamic performance of OMIB system deteriorates, and in some
cases, based on a severely deviated estimation, MPC controller may even provide an error control
action under which the OMIB system may collapse. As a conclusion, when an unmodeled disturbance
occurs in the closed-loop system, using high gain based estimator is more likely to make the whole
system unstable, in other words it provides less robustness than using low gain based estimator.
For verifying the relation between estimator gain and MPC controller robustness, simulation case 2
is designed and performed. The parameters of this case are identical to the simulation case 1 except
for an unmodeled disturbance, which is added in the OMIB model at 1.20s and lasts 5ms for modeling
an uncertainty. For simplicity of exposition, this disturbance is designed as a data sequence which
increases proportion to time and this sequence is used as the input signal of the MPC controller to
replace the real-time measurement from the OMIB plant. Corresponding to an actual case, this
unmodeled disturbance may be a measuring error or an interference problem in data transmission.
Rotor angles as the simulation results of case 2 are illustrated in Fig 5.10. The MPC closed-loop
system using a pole-placement based estimator and 800 prediction horizon (red line in Fig 5.10)
collapses at around 1.53s. At the collapse instant, the rotor angle is over 180 degree, namely loss of
synchronism. However, when employing Kalman filter based estimator (green line), system is finally
stabilized. Then, compared to Fig 5.9, the MPC controller with pole-placement estimator cannot keep
the closed-loop system stable concerning the unmodeled disturbance, whereas the one with Kalman
filter based estimator still keep the system stable, despite worse POD performance than the case in
Fig 5.9. Hence, in this case, the Kalman filter based controller is more capable of sustaining an
unmodeled disturbance and keeps the system stable. Respecting lower PH 200, the overall control
performance of Kalman filter based controller is still better than the one based on pole-placement
estimation method. As a conclusion, the Kalman filter based estimator, whose estimator gain is
smaller than the pole-placement based estimator, provides more robustness to the MPC controller.
Since the control action directly affects the MPC closed-loop system dynamics, the control action
u1 round the disturbance time are addressed and given in Fig 5.11. During the disturbance, since
the pole-placement based estimator has a larger estimator gain than the Kalman filter based estimator,
it generates a more deviated estimation. With the same PH, due to a more deviated estimation, the
control action of the pole-placement estimation based MPC controller is more aggressive than the
68
one using Kalman filter method. With the same estimation method, the control action of higher PH
based controller is more aggressive than the lower PH based controller, which will be expounded in
subsection 5.5.2. In this simulation case, when a more aggressive control action is applied, the POD
performance of the closed-loop system is worse. Further, provided that the control aggressiveness is
beyond a specific critical level, the closed-loop system is unstable. The reason is: when the control
action is computed based on a deviated estimation, a more aggressive control action introduces more
ineffective and unstable factors into the closed-loop system.
In the case 1 without disturbance, there is only a subtle difference between different MPC controllers.
When an unmodeled disturbance is added in the case 2, the MPC controller using Kalman filter based
estimator has more robustness. Therefore, for the reason of stability and robustness, Kalman filter
method is proposed as the estimation method for the remaining simulation tests.
180
Case 2: Estimator Comparison

under Unmodeled Disturbance
5ms unmodeled
150
120
1 (degree)
90
60
3ph-150ms-fault
30
0
-30
-60
Kalman Filter PH:200
-90
Pole-placement PH:200
-120
Kalman Filter PH:800
-150
Pole-placement PH:800
-180
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0 t (s) 4.5
Figure 5.10: Case under unmodeled disturbance (angle of generator 1).

540
Case 2: Estimation Comparison

420
Control Action (p.u)
300
180
60
-60
Kalman Filter
PH:200
Pole-placement
PH:200
Kalman Filter
PH:800
Pole-placement
PH:800
5ms unmodeled
disturbance
-180
-300
-420
-540
1.1
1.2
1.3
1.4
1.5
Figure 5.11: Case under unmodeled disturbance (control action of the MPC controller).
69
t (s) 1.6
5.5.2 Test 2: Different Prediction Horizon (PH) Based POD Controllers

In this subsection, the OMIB systems with different PH based MPC controllers are analyzed based
on three aspects: 1) influence of different PH on MPC control performance; 2) influence of different
PH on the robustness of MPC controller; 3) influence of extra-high or -low PH on stability issue of
MPC. Respectively, two simulation cases are performed: Firstly, for analyzing the first aspect the
OMIB system with different PH based MPC controller is simulated; secondly, for analyzing the third
aspect, the OMIB system with an extra-low PH based MPC controller is simulated.
In this subsection, the MPC parameters are identical to the ones in table 5.4 except that the different
PH. As the proposal given in the subsection 5.5.1, Kalman filter is adopted as the estimation method.
First, simulation result: rotor angle of the case 1 is given in Fig 5.12. It is shown that MPC based
controller is more effective in damping power oscillation compared with the PSS controller. Focusing
on the MPC controllers, the high PH based controller has a better damping performance. The reason
may be explained by analyzing the control actions in Fig 5.13. However, with high PH more time for
computing the optimization problem is needed, which should be noticed in the controller design.
120
Case 1: Comparison of MPC Using Different PH

110
1 (degree)
100
90
80
70
MPC PH:200
60
MPC PH:500
3ph-150ms-fault
MPC PH:800
50
Classical PSS
40
0.0
1.0
2.0
3.0
4.0
5.0
6.0
7.0
t(s) 8.0
Figure 5.12: MPC controllers using different PH (angle of generator 1).
In Fig 5.13, all the control actions of MPC controllers have lager amplitudes and faster response to
the fault than the classical PSS. Focusing on the MPC controllers, the control action of high PH based
MPC controller changes more substantially and rapidly than the one with low PH based controller.
Its reason can be explained by reviewing the objective function (5.5): the three targets, namely the
three quadratic sum terms, constitute the optimization objective and the ratios of the three targets in
the objective change dependent on MPC parameters. In this case where the other MPC parameters
70
are unchanged, high PH implies that more sum terms of the deviation terms between controller inputs
and set-points are involved in the first term of (5.5). Therefore the ratio of the first target, namely setpoint tracking of controller input, in the objective increases. And in the higher PH case, less factors
of control suppression are involved in the final optimization solution. As a result, a larger and more
rapidly changed control action is possible. In other words, higher PH based MPC controller is capable
of giving more adequate and faster response to the fault, which may account for the simulation results
in Fig 5.12. Next, recalling the controllers with the same estimation method in Fig 5.11, high PH
based controller also has substantially-changed control action. However, contrary to the Fig 5.9 or
5.12, higher PH leads to a worse POD performance, namely less robustness under an unmodeled
disturbance. The reason has been explained in subsection 5.5.1. As a conclusion, when an unmodeled
disturbance is added, the adequate response may become an aggressive response.
Except the robustness issues, if the PH is extra-high, the condition number of the Hessian matrix H
in (5.7b) will be large and a numerical sensitivity can occur in the simulation, which means that the
optimization process of MPC is sensitive to small numerical perturbation [5.10]. As a result, the
corresponding MPC system is called ill-conditioned. However, this topic is beyond the scope of this
thesis, and it can be simulated and studied in the future work.
3.0
Case 1: Comparison of MPC Using Different PH
2.0
1.0
0.0
3ph150msfault
-1.0
MPC PH:200
MPC PH:500
-2.0
MPC PH:800
Classical PSS
-3.0
0.8
1.0
1.2
1.4
1.6
1.8
2.0
2.2
2.4
2.6 t(s) 2.8
Figure 5.13: MPC using different PH (control action of the MPC controller).
In the simulation case 2, the case of extra-low PH=50 is studied. Provided that constraint issue is not
involved, by the use of the function review in the MPC toolbox, the stability of the closed-loop
system can be tested and reported automatically. Referring to expression (5.11), the review function
extracts the matrix Aclosed of the closed-loop MPC control system and calculates its eigenvalues.
If the absolute value of each eigenvalue is less than 1, the unconstrained closed-loop system is stable
71
[5.7]. In this case, after calling the review, the absolute value of the maximum eigenvalue exceeds
1 by 8.9152e-05, which means the closed-loop system is unstable. By recalling the eigenvalues of
the OMIB system without any POD controller in table 5.2, the MPC controller with extra-low PH
even worsens the dynamic characteristic of the OMIB system.
The results of the simulation case 2 are given in Fig 5.14. Recalling the previous paragraph, here two
similar conclusions can be drawn: 1) the closed-loop OMIB system with MPC controller is unstable
and loss of synchronism occurs; 2) the dynamic performance of the OMIB system equipped with the
extra-low PH based MPC controller even deteriorates compared to the case where no POD controller
is used. Referring to the Fig 5.14(b), the MPC controller does not give an adequate control action
soon after the fault. And because the open-loop OMIB system is unstable, without adequate control
the running state of the OMIB system gradually becomes severe. Subsequently, due to the loss of
synchronism, abrupt change of rotor angle occurs in the simulation at 1.5th second in Fig 5.14(a) and
1 (degree)
meanwhile it leads to an abrupt change of MPC control action in Fig 5.14(b).

350
250
150
50
-50
-150
-250
-350
OMIB without POD
Case 2 :
MPC using Extra-low PH
0.0
MPC PH:50
3ph-150ms-fault
2.0
0.5
1.0
1.5
2.0
3ph-150ms-fault
2.5
3.0
MPC PH:50
3.5
t(s) 4.0
OMIB without POD
1.0
0.0
Case 2 :
MPC using Extra-low PH
-1.0
-2.0
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
t(s) 4.0
Figure 5.14: MPC using extra-low PH: (a) angle of generator 1; (b) control action of the MPC controller.
As a conclusion of this subsection, respecting the prediction horizon (PH) selection, extra-low and high PH need to be avoided according to the specific controlled plant characteristic, and respecting
the value of PH, an overall trade-off among factors, like optimization computation time, controller
robustness and control performance, needs to be analyzed in advance in the controller design.
5.5.3 Test 3: Different Control Horizon (CH) Based POD Controllers

In this subsection, different CH based MPC controllers are simulated in the OMIB system and the
72
simulation results are compared respecting two aspects: 1) the influence of different CH on MPC
control performance; 2) the effect of different CH on the robustness of MPC controller. Respectively,
two simulation cases are performed: for analyzing the first aspect, the OMIB system with different
CH based MPC controller is simulated; for analyzing the second aspect, the unmodeled disturbance
(used in subsection 5.5.1) is also added into the simulation as the second case.
In this subsection, the MPC parameters are identical to the parameters given in table 5.4 except that
the PH is fixed at 200 and different CH are tested. Kalman filter is adopted as the estimation method.
First, the simulation result of case1 is given in Fig 5.15. It is shown that in general, there is only a
subtle difference of damping performance between the different CH based MPC controllers. Strictly
speaking, the lower CH based MPC has a slightly better damping performance. As the CH increases,
the corresponding MPC controller has a worse control performance. One reason could be that as the
CH increases, the optimal control energy is distributed over a longer control horizon [5.10] and the
average value of control action at each sampling instant decreases. Then, controller using lower CH
has a bit more adequate response to the fault compared to the one using higher CH. Concluding from
the simulation case 1, parameter CH tuning almost does not affect the MPC control performance.
110
Case 1:Comparison of MPC Using Different CH
105
100
1 (degree)
95
90
85
80
3ph-150ms-fault
75
70
MPC CH:5
MPC CH:20
MPC CH:80
65
60
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
t(s) 4.0
Figure 5.15: MPC using different CH (angle of generator 1).
Then, the simulation case 2 is performed and the respective results are illustrated in Fig 5.16. The
only difference among the simulation cases appears between 1.35s and 2.35s. The first main wave
hollow is delayed slightly when a lower CH is adopted, however, the settling time of all the three
cases are approximately at 2.5th second. Strictly, lower CH leads to only a minor deterioration in
control performance. As a conclusion, CH tuning has no notable effect on the controller robustness.
73
As the conclusion of this subsection, compared to the simulation case for analyzing PH, parameter
CH tuning has less influence on MPC. Furthermore, high CH requires more computation time. If the
robustness of MPC controller is not fulfilled, CH tuning is not proposed for robustness improvement.
Finally, as a proposal, a moderate CH is chosen in advance in the control design and kept as constant.
110
105
Case 2: Comparison of MPC Using Different CH

5ms unmodeled
1 (degree)
100
95
90
85
80
MPC CH:5
3ph-150ms-fault
MPC CH:20
75
MPC CH:80
70
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
t(s)
4.0
Figure 5.16: MPC using different CH under unmodeled disturbance (angle of generator 1).
5.5.4 Test 4: Different Control Action Weights ( ) and Control Action Rate Weights
(
) Based POD Controllers
This subsection is the last part of this chapter for analyzing MPC parameter tuning. Here, two
parameters, weights on control action

and weights on control action rate are tuned and the
simulation cases are designed respecting three aspects: 1) the influence of different
and on
MPC control performance; 2) the influence of different

and on the robustness of MPC
controller; 3) the issue of zero setting of both

and . The first case: the OMIB system with
different
and based MPC controller is simulated for analyzing the first aspect. The second
case: two different degree of unmodeled disturbance similar to the one used in subsection 5.5.1 are
added into the simulation for analyzing the second aspect. Finally, a detection of a MPC object is
performed and reported in MATLAB for analyzing the third aspect.
The parameter PH is fixed at 200, and

and are tuned. The remaining MPC parameters
and estimation method are identical to the ones given in table 5.4. The subscript 1 means that the
weight is applied to the first and also the unique controller output u1 (or increment u1). The
simulation case 1 is divided into two parts:

is set to zero and is tuned, and vice versa.
74
First, the simulation result of the part 1 is given in Fig 5.17. There is only a subtle change in the result
as
changed. Strictly, the lower based MPC has a slightly better damping performance. This
can be explained by referring to the definition of

in subsection 5.2.2: as the weight decreases, a
higher control action rate is achieved. Thus, the MPC controller can provide a more rapid response
to a disturbance. For this case, it can be concluded that parameter
almost does not affect the
MPC control performance. However, this conclusion is inconsistent with the simulation results in the
example 1.2 of [5.10], where tuning significantly affects the control performance. Thus, it can
be concluded that respecting different control plant and MPC configuration, the effect of parameter
tuning can be extremely different on control performance.

110
Case 1 (Part 1):

Comparison of MPC Using Different w1u
105
100
1 (degree)
95
90
85
80
3ph-150ms-fault
75
70
Weight on u1 : 0.1
Weight on u1 : 0.5
Weight on u1 : 1.0
65
60
0.0
1.0
2.0
3.0
4.0
5.0
Figure 5.17: MPC using different w1 u and w1u=0 (Part 1) (angle of generator 1).
t(s) 6.0
Then, the simulation part 2 is performed and analyzed through Fig 5.18. In the figure (a), when a low
is set, the corresponding MPC controller has a better damping performance. Correspondingly,
the control action u1 is given in the bottom (b). The control action of high
based controller
changes more substantially and rapidly than the low based one. This results of Fig 5.18(a)&(b)
can be explained by reviewing the definition of
in subsection 5.2.2: as the weight decreases, more
degree of freedom is given to u1 so that u1 can move away from its target, namely zero in this
simulation, temporarily to improve the Set-point tracking, namely the first term of the form (5.5).
In other words, since the target of u1 is zero, tuning the weight
affects the magnitude of u1
and a large value of
will force the control action to approach zero which may lead to inadequate
control. Furthermore, the control performances of the cases where = 0.1&0.5 in Fig 5.18(a) are
better than all the results of Fig 5.17. Therefore, when fast response is the main control task, setting
a nonzero and moderate value of weight

instead of activating the is proposed.
75
1(degree)
110
Case 1 (Part 2) :
MPC Using Different
90
70
Weight on u1 : 0.1
Weight on u1 : 0.5
Weight on u1 : 1.0
3ph-150msfault
50
0.0
w1u
1.0
2.0
3.0
4.0
5.0
6.0
7.0
t (s) 8.0
Case 1 (Part 2) :
MPC Using Different
w1u
-1
-5
Weight on u1 : 0.1
Weight on u1 : 0.5
Weight on u1 : 1.0
3ph-150msfault
-8
0.8
1.0
1.2
1.4
1.6
1.8
2.0
2.2
2.4
2.6 t(s) 2.8
Figure 5.18: MPC using different w1u and w1u=0 (Part 2):
(a) angle of generator 1; (b) control action of the MPC controller.
Fig 5.19- 5.22 show the results of the simulation case 2, which consists of four main simulation parts
for studying different influence of

and on the MPC robustness. In the first part, is tuned
and
is kept at 0 for checking the independent influence from on the controller robustness.
In the second part,

is enabled so that the case where the both weighting parameters are enabled
can be analyzed and compared to the first simulation part. In the third and fourth part,
is tuned
and
is kept at 0. However, in the third part, a smaller unmodeled disturbance is added. Then, by
a comparison of the simulation results of the third and fourth parts, which include different degrees
of unmodeled disturbances, generally, the effect of
on the controller robustness can be analyzed.
First, the simulation results of part 1 are given in Fig 5.19. In (a)&(b), there are only subtle differences
between different cases. As a conclusion, the response of different
based MPC controllers to the
unmodeled disturbance are approximately the same. In other words, tuning
does not affects the
controller robustness significantly when the
is set to zero. However, compared to the studies in
[5.10], this conclusion is not ensured for other control cases and MPC configurations.
Then, the simulation results of part 2 are given in Fig 5.20, where
is kept at 0.1 and three trials
using different
are performed. In (a), the trials with = 0.1&0.5 are unstable, which is a rather
counter-intuitive result, since in Fig 5.19(a), when the weight

= 0.1, the respective system is
stable. According to the effect of parameter , no matter which value is, it can be presumed that
adding the weight into objective function may lead to a more conservative control move. In other
words, since suppresses the value of the computed control action, even during the disturbance
76
time the control is intuitively supposed to be nonaggressive. However, the control actions in Fig
5.20(b) are much more aggressive than the case where

= 0.1& = 0 in Fig 5.19(b). This
counter-intuitive behavior may be explained by reviewing the objective function J(Uk) in form (5.5).
Before adding the weight on control action, the third term in (5.5) is omitted and the computed
optimization solution is only optimal concerning the first two terms. Then adding a weight
redistributes the optimization energy and changes the ratio of different targets in the optimization
problem, the previous computed control action may be not the optimal solution for this simulation
part 2 anymore. In Fig 5.20(b), these new solutions based on = 0.1&0.5 make the closed-loop
system unstable. Even if the case of = 1.0 is stable, the corresponding POD performance is still
worse than the case:

= 0.1 in Fig 5.19(b). Hence, adding the into the optimization objective
reduces the robustness of the controller when only the is tuned.

110
5ms large
unmodeled
disturbance
1 (degree)
100
90
Case 2 (Part 1) : Dfifferent w1u

80
Weight on u1 : 0.1
Weight on u1 : 0.5
Weight on u1 : 1.0
70
60
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
t (s) 4.0
10
8
Case 2 (Part 1) : Different w1u

5ms large
unknown disturbance
5
3
0
Weight on u1 : 0.1
Weight on u1 : 1.0
-3
Weight on u1 : 0.5
-5
0.8
1.0
1.2
1.4
1.6
1.8
2.0
t (s)
2.2
Figure 5.19: MPC using different w1u and w1u =0 under unmodeled disturbance (Part 1):
Finally, the simulation parts 3&4 are performed and the results are given in Fig 5.21&5.22. Since the
parameter setting of parts 3&4 are identical except the degree of unmodeled disturbance, they are
analyzed and compared together. Firstly, referring to the Fig 5.21(a), only the case where =0.1 is
unstable, however in the Fig 5.22(a), under a severer unmodeled disturbance, another case: =0.5
is also unstable. However, the cases using =1.0 in the part3&4 are always stable. Hence, it can be
concluded, when
= , the MPC controller with a higher can sustain a severer unmodeled
disturbance. In other words, increasing may improve the controller robustness. This conclusion
can also be demonstrated by the respective control actions in Fig 5.21(b)&5.22(b): lower based
controller gives more aggressive control action. This results can be explained based on the effect
77
of , which has been mentioned in the case 1 (part 2). However, the advantage of lower , namely
fast response to fault in the previous case, becomes a drawback: aggressive response to unmodeled
disturbance in this case, i.e. the OMIB system under unmodeled disturbance.
In some control cases, neither implicit nor explicit constraint on control action needs to be concerned.
Therefore, a discussion of zero setting issue of both weight parameters and is necessary. For
this discussion, the aforementioned function review in the MPC toolbox for checking MPC design
error is called again and a report: the validity of QP Hessian Matrix fails is generated in MATLAB.
The report means that the Hessian matrix H of the objective function (5.7a) is not positive-definite,
and as a result the corresponding objective function is not a strict convex function. Based on a nonstrict convex objective function, the computed optimization solution is not the unique minimum. In
other words, the solution may be not the optimal solution. Thus, the corresponding MPC controller
may be ineffective. The reason why =0 &
=0 leads to non-positive definite H can be explained
by reviewing the expression (5.7b). When =0 &
=0, the matrix and are removed
from (5.7b), and then the positive definiteness of H is only determined by the term .
However, if = 0 or = 0, the case that =0, namely H=0 may occur, which indicates H
is not positive-definite. As a conclusion, even though no penalty for the control action is required, it
is proposed that at least one weight is non-zero. In addition, it is desired that 0 and 0 to
guarantee >0 so that H is ensured to be positive-definite.
180
1 (degree)
120
60
0
Weight on u1 : 0.1
Weight on u1 : 1.0
5ms large unmodeled

disturbance
-60
Weight on u1 : 0.5
Case 2 (Part 2) (a): w1u=0.1 &Different w1u

under Large Unmodeled Disturbance
-120
-180
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0 t (s)
4.5
550
350
Case 2 (Part 2) (b): w1u=0.1 &Different w1u

under Large Unmodeled Disturbance
5ms large
unknown
disturbance
Weight on u1 : 0.1
Weight on u1 : 1.0
150
Weight on u1 : 0.5
-50
-250
t (s) 1.8
1.1
1.2
1.3
1.4
1.5
1.6
1.7
u
u
Figure 5.20: MPC using w1 =0.1 and different w1 under large unmodeled disturbance (Part 2):
78
1 (degree)
190
Case 2 (Part 3) : MPC Using Different w1u

under Small Unmodeled Disturbance
5ms small
unknown disturbance
155
Weight on u1 : 0.1
Weight on u1 : 1.0
120
Weight on u1 : 0.5
85
50
0.0
1.0
2.0
3.0
4.0
t (s)
5.0
6.0
300
5ms small
unmodeled
disturfbance
Control Action
(p.u)
200
100
Case 2 (Part 3) : MPC Using Different w1u

under Small Unmodeled Disturbance
0
Weight on u1 : 0.1
Weight on u1 : 1.0
-100
Weight on u1 : 0.5
-200
1.1
1.2
1.2
1.3
1.3
1.4
1.4
1.5
1.6 t (s) 1.6
1.5
Figure 5.21: MPC using different w1u and w1u=0 under small unmodeled disturbance (Part 3):
1 (degree)
180
120
60
0
5ms large
unmodeled
disturbance
-60
-120
Weight on u1 : 0.1
Case 2 (Part 4) : MPC Using

Different w1u under
Unmodeled Disturbance
Weight on u1 : 0.5
Weight on u1 : 1.0
-180
600
0.4
0.9
1.4
1.9
5ms large
unmodeled
disturbance
450
300
150
2.4
2.9
3.4
3.9
t (s) 4.4
Weight on u1 : 0.1
Weight on u1 : 0.5
Weight on u1 : 1.0
Case 2 (Part 4) : MPC Using

Different w1u under
Unmodeled Distrubance
-150
-300
1.1
1.2
1.3
1.4
1.5
1.6
1.7
t (s)
1.8
Figure 5.22: MPC using different w1u and w1u=0 under unmodeled disturbance (Part 4):
5.5.5 Summary
In this section, different case studies and tests are performed for analyzing the kernel parameters in
the MPC design, which are: state estimation method, prediction horizon (PH), control horizon (CH),
weight on control action 1 and weight on control action rate 1 . Among these case studies and
tests, the main part are performed through the cross-platform time-domain simulations with the APIs
in PSSNETOMAC environment. The remaining part: the frequency-domain analysis of estimation
error system and the checks on MPC design error, is performed by MATLAB software. Conclusions
of these case studies and tests are addressed on the three aspects: 1) the response of the MPC based
79
POD controller to the fault; 2) robustness of MPC based POD controller; 3) notes for MPC parameter
tuning. First, the conclusions respecting the first two aspects are summarized in the table 5.9.
MPC Parameter Selection
More Robustness
Faster Response
Estimation Method
Kalman Filter
Pole-placement
Weight on Control Action Or
Tuning
and
Tuning and
Weight on Control Action Rate
setting = 0
setting
=0
MPC Parameter Tuning
More Robustness
Faster Response
Lower PH
Higher PH
Higher CH
Lower CH
Tuning
Tuning 1
Higher
Higher 1
Lower 1
Lower 1
Red font: significant effect on controller robustness or response.

Blue font: weak effect on controller robustness or response.
Table 5.9: A summary of the conclusions respecting controller robustness and response from section 5.5.
Finally, two notes for MPC parameter tuning of are highlighted: 1) extra-low PH needs to be avoided;
2) zero setting of both weight parameters 1 and 1 need to be avoided.
5.6 Simulation Test for Analyzing MPC Based POD Controller in MultiMachine System
In this chapter, the simulation of the multi-machine system with a centralized MPC strategy, which
has been introduced in subsection 5.3.2, is investigated. The time-domain behavior of the power
system subject to a 50ms three-phase short-circuit fault is given in Fig 23 (a-c), where angle of each
generator is shown except for the generator 2, since its angle is chosen as the reference.
It is shown that MPC based POD controller mitigates the power oscillation faster. However, for
generator 1, the amplitude of the oscillation of the MPC case is somewhat higher than the PSS case
in the beginning after the fault. Nevertheless, the settling time of the MPC case is earlier. As a
conclusion, the MPC based POD controller is more effective in power oscillation damping by
comparing with the classic PSSs in this case.
80
18
1 (degree)
16
Rotor Angle of G1
14
12
10
Classic PSS
8
MPC based POD Controller
6
0.0
5.0
10.0
15.0
20.0
25.0
t (s)
30.0
-5
Rotor Angle of G3
3 (degree)
-10
-15
-20
-25
Classic PSS
-30
-35
0.0
5.0
10.0
15.0
20.0
25.0
t (s)
30.0
-15
Rotor Angle of G4
4 (degree)
-20
-25
-30
Classic PSS
-35

-40
0.0
5.0
10.0
15.0
20.0
25.0
t (s)
30.0
Figure 5.23: POD performance comparison between classic PSS and MPC based POD controller in multimachine system (rotor angle): (a) G1, (b) G3, (c) G4.
81
6 Conclusion and Future Work

This chapter recapitulates the main results obtained in this thesis by providing the key conclusions.
It also suggests possible extensions of the work reported in this thesis.
6.1 Conclusions
This thesis has addressed on four main aspects and the following conclusions can be drawn:
1) Surveys of DLL and API technology:
A survey of DLL technology is formulated on three aspects: 1) two-layer division of DLL program
architecture; 2) two-phase division of DLL creation work; 3) calling issues of DLL. This survey
has been proven to enhance the understanding and the creation work of the DLL based APIs.
Three modes of the API creation work: 1) full-manual mode; 2) semi-automatic mode; 3) hybrid
mode, and the API-related calling work are formulated. In addition, the features and applied
ranges of each mode are expounded for the mode selection.
An API architecture: two-level DLL, is adopted for underlying the hybrid mode. The first-level
DLL wraps the compiled model. And the second-level DLL serves as the interface to link the firstlevel DLL with different power system simulation programs.
2) Validation of the three API creation modes and the created APIs in the case study:
The three modes of API creation are validated to be applicable for the specific cross-platform case
between MATLAB and PSSNETOMAC. Only the two platforms are used in this thesis. And,
for generality, in each mode two modelling manners: MATLAB codes and Simulink are analyzed.
The formulation of the API-related calling work is proven to be applicable, and especially in the
hybrid mode (two-level DLL), it is also applied to call the first-level DLL
All the APIs created in different modes are proven to be effective according to the simulation
results. And the functionality of the model, which is wrapped into the APIs, can be directly
requested in the cross-platform simulations without extra remodeling work.
3) Based on the proposed API approach, a classic PSS model has been successfully employed in an
OMIB system model for POD in cross-platform simulation manner. This simulation is performed
in the case study.And, the APIs used in the case study&::are created in the hybrid mode,
mainly due to one of its outstanding features: more intuitive program structure of API. And with
respect to its other features, the hybrid mode is proposed as the priority selection for API creation.
4) Investigation of the MPC based POD controller by the case study::
82
For the OMIB- and multi-machine system under small-disturbance, MPC based POD controllers
are designed and applied for POD problem. Especially for the multi-machine power system, the
dominant inter-area oscillatory mode is addressed. The two types of power systems are modelled
and linearized as discrete-time linear models by the small-signal method. Further, their control
performances are evaluated in the API based cross-platform simulations between MATLAB and
PSSNETOMAC and are proven to be superior by the comparison with classic PSS controller.
State estimation issues of the MPC based POD controller are systematically analyzed in the OMIB
model. Two estimator methods: pole-placement and Kalman filter are presented by addressing
control response and robustness. High estimator gain severely reduces the control robustness. To
avoid this problem, when using pole-placement, observability measures of the eigenvalues of the
OMIB model are presented to define the rational placement range. However, when using Kalman
filter, the estimator gain is uniquely determined by solving a Riccati equation without manual
setting. Finally, by the time-domain simulations with and without an unmodeled disturbance, it is
shown the control robustness is sensitive and control response is insensitive to the estimation gain.
Parameter tuning issues of the MPC based POD controller are analyzed systematically. In the
OMIB case, four critical MPC parameters: prediction horizon (PH), control horizon (CH), control
action weight ( 1 ) and control action rate weight ( 1 ) are tuned respectively to analyze their
effects on the control response and robustness. By this analysis, these parameters can be tuned to
achieve a specified trade-off between control response and robustness for different requirements.
In the multi-machine case, the MPC parameters are tuned based on the participation factors of
each system output in the dominant oscillatory modes. The output with more participation in the
dominant modes obtains more weight in the control objective. Furthermore, to enhance robustness,
set-points (r) to the outputs of the controlled system as an auxiliary parameter are also tuned.
6.2 Future Work

The following is a list of ideas and suggestions for the future work:
1) The DLL based API is only validated in the cross-platform case between PSSNETOMAC and
MATLAB. To verify the generality of the DLL- and API-related surveys, which are presented in
this thesis, more cross-platform cases could be studied in future.
2) MATLAB as the modelling environment provides a variety of modules for supporting the APIrelated functions. In this thesis, only the basic module is applied. However, a module Custom
Code will be of interest to the API creation optimization. The template codes for underlying the
API program can be transplanted into Custom Code. Thus, all the API creating work can be
performed in MATLAB without using extra development software.
83
3) In this thesis, the MPC based POD controller is designed with the easy-to-use Model Predictive
Control Toolbox, where the MPC-related algorithms and data structures are wrapped into
different object-oriented modules. Namely, this toolbox is of high integration (not open source).
However, for debugging the MPC based controller, separate invocation or modification of part of
the module is needed. Thus, it is proposed to adopt other open source program or flexible codes,
like MATLAB codes, to design the controller in future.
4) In power system simulations, only the disturbance: three-phase short fault is studied. The POD
performances of the MPC based controller in other small-disturbance cases can be analyzed.
5) This thesis only presents a simplified analysis of control robustness, since only an unmodeled
disturbance is added for validating the controller robustness. Later, more systematic and generic
methods can be performed for robustness analysis.
6) The effects of mismatch model on the MPC design can be analyzed further. Especially for the
three-phase fault case, during the fault, the real system configuration has changed. However, the
power system model information included in the MPC controller is still the original system.
7) Parameter tuning of the MPC controller is still based on empiricism, the mechanism of coupling
effect of different MPC parameters is still not clear. A further investigation is necessary.
8) Issues of the steady-state errors of the MPC control system can be discussed further.
9) In the multi-machine case, classic PSSs are separately equipped with generators in decentralized
manner. In other words, they only utilize the local information. However, as the comparison, the
MPC based POD operates in centralized manner and utilize the global information. It is of interest
to a comparison between the improved PSS, which utilizes global information of power system,
and this MPC based controller.
10) In the multi-machine case, the communication delay associated with the measurements of the
power system outputs can be considered in future.
84
Appendix A
Appendix A: ext_simenv_API.c File

/*
* File: ext_simenv_API.c
*
* C source code generated on: 6 Jun 2015
*
* This file is a source-file template as one part of ESE-interface and in general,
* it is employed in combination with " ext_simenv_types.h" and "ext_simenv_capi.h".
*/
#define DLL_EXPORT __declspec(dllexport) // makes codes more readable
#include "ext_simenv_capi.h" // Declaration of the data structures and functions.
/*
The corresponding header files as part of the model codes generated by Simulink or
MATLAB Coder need to be included when the one-level DLL based API is intended to be
created. Thus, the external functions and data defined in model codes can be used.
*/
#include
#include
#include
#include
<stdlib.h>
<math.h>
<stdio.h> // for _snprintf
<string.h> // for memset
/* Macro Definitions for general use of ESE-interface */

#define INT_MEM ((internal_memory *)pInstanceCapi->MiscStates)
#define INPUT ((real64_T *) pInstanceCapi->ExternalInputs)
#define OUTPUT ((real64_T *) pInstanceCapi->ExternalOutputs)
#define PARAMETER ((real64_T *) pInstanceCapi->Parameters)
/* Macro Definitions to explicitly link the first-level DLL with the API program.
#include "typedef_export.h" // Type declarations for the model's I/O.
#if (defined(_WIN32)||defined(_WIN64)) // WINDOWS.
#include <windows.h>
#define GETSYMBOLADDR GetProcAddress
#define LOADLIB LoadLibrary
#define CLOSELIB FreeLibrary
#endif
*/
///************ definitions of data structures of ESE-interface************///
typedef struct {
real64_T dT;
real64_T x;
real64_T rst_prev;
char_T last_error_message[255];
} internal_memory; // internal storage
const StaticESEInputSignal static_inputs[] = {
{ "Input", "", 1 },
}; //static struct with input signal description
const StaticESEOutputSignal static_outputs[] = {
{ "Output", "", 1 },
}; //static struct with output signal description
85
Appendix A
const StaticESEParameter static_parameters[] = {

{ "K", "Gain ", "p.u.", 1., 0., 1000. },
}; //static struct with parameter description, presently not used.
StaticExtSimEnvCapi static_model_info = {
{ 0, 0, 0, 1 }, // Release number of the API used during code generation
"Template",
// ModelName: Model name
"1",
// ModelVersion: Model version
"Code Template for Further Work", // ModelDescription: Model description
"",
// VersionControlInfo: Version control information
"C Source", // GeneralInformation: General info - here some RTW info
"", // ModelCreated: Model created on
"", // ModelCreator: Model created by
"2015-06-06",
// ModelLastModifiedDate: Model last modified on
"Jiachen Bai", // ModelLastModifiedBy: Model last modified by
"Simplified as a template for general use",// Model modified comment
"",
// ModelModifiedHistory: Model modified history
"",
// CodeGeneratedOn: Code generated on
"",
// Solver name (can be empty)
1e-3,
// FixedStepBaseSampleTime: Base sample time
sizeof(static_inputs) / sizeof(static_inputs[0]),// Number of inputs
&static_inputs[0], // Pointer to input signal description array
sizeof(static_outputs) / sizeof(static_inputs[0]), // Number of outputs
&static_outputs[0], // Pointer to output signal description array
sizeof(static_parameters) / sizeof(static_parameters[0]),//NumParameters
&static_parameters[0], // Pointer to parameter description array
0,
// Number of continuous states, not used in this version
sizeof(internal_memory), // Size of work variables / misc states
{ 0, 0, 0, 0 }, // Simulink model checksum
NULL,
// Error string pointer
3,
// Mode: EMT = 1, RMS = 2, EMT & RMS = 3, otherwise: 0
0,
// Model contains a loadflow function: 0 = no, 1 = yes
0,
// ESEExtension Extension: Provided for extensions
}; // static struct with model info
///************ definitions of functions of ESE-interface************///
char * my_initialization(InstanceExtSimEnvCapi *pInstanceCapi)
{ return NULL; } // custom initialization code if required
extern DLL_EXPORT const StaticExtSimEnvCapi* __cdecl Model_GetInfo(void)
{ return &static_model_info; } // Model_GetInfo
extern DLL_EXPORT InstanceExtSimEnvCapi* __cdecl Model_Instance(uint32_T
UseSolverInDLL, real64_T Ta)
{
uint8_T i, w;
InstanceExtSimEnvCapi * pInstanceCapi;
pInstanceCapi = (InstanceExtSimEnvCapi *)malloc(sizeof(InstanceExtSimEnvCapi));
if (pInstanceCapi == NULL) { return NULL; }
/****** allocate internal memory ******/
/* ExternalInputs, taking into account width of vectorized signals */
w = 0;
for (i = 0; i < static_model_info.NumInputPorts; i++) {
w = w + (&static_model_info)->InputPortsInfo[i].Width;}
86
Appendix A
pInstanceCapi->ExternalInputs = (real64_T *)malloc(w*sizeof(real64_T));

/* ExternalOutputs, taking into account width of vectorized signals */
w = 0;
for (i = 0; i < static_model_info.NumOutputPorts; i++) {
w = w + (&static_model_info)->OutputPortsInfo[i].Width;}
pInstanceCapi->ExternalOutputs = (real64_T *)malloc(w*sizeof(real64_T));
pInstanceCapi->Parameters = (real64_T *)malloc(
static_model_info.NumParameters*sizeof(real64_T)); // Parameters, only scalar.
pInstanceCapi->ContinuousStates = NULL; // ContinuousStates,presently not used
pInstanceCapi->StateDerivatives = NULL; //StateDerivatives, presently not used
pInstanceCapi->MiscStates =
(uint8_T *)malloc(static_model_info.SizeofMiscStates); // MiscStates, not used.
/* LastErrorMessage, initialize to blank */
pInstanceCapi->LastErrorMessage = NULL;
memset(&(INT_MEM->last_error_message), 0, sizeof(INT_MEM->last_error_message));
pInstanceCapi->LastGeneralMessage = NULL; // LastGeneralMessage, not used.
pInstanceCapi->VerboseLevel = 0; // VerboseLevel, presently not used.
pInstanceCapi->Extension.UserVoidPtr = NULL; ///Extension, presently not used.
/* set the integration time-step size */
if (Ta > 0) {INT_MEM->dT = Ta;}
else {INT_MEM->dT = static_model_info.FixedStepBaseSampleTime;}
return pInstanceCapi;
} // Model_Instance
extern DLL_EXPORT const char* __cdecl Model_CheckParameters(InstanceExtSimEnvCapi
*pInstanceCapi)
{ return NULL; } // Model_Check_Parameters, presently not used.
extern DLL_EXPORT const char* __cdecl Model_Loadflow(InstanceExtSimEnvCapi
*pInstanceCapi)
{ return NULL;
} // Model_Loadflow, presently not used.
extern DLL_EXPORT const char* __cdecl Model_Initialize(InstanceExtSimEnvCapi
*pInstanceCapi)
{ return NULL; } // Model_Initialize
extern DLL_EXPORT const char* __cdecl Model_Outputs(InstanceExtSimEnvCapi
{ return NULL; } // Model_Outputs
extern DLL_EXPORT const char* __cdecl Model_Update(InstanceExtSimEnvCapi
*pInstanceCapi)
{ return NULL; } // Model_Update, presently not used.
extern DLL_EXPORT const char* __cdecl Model_Derivatives(InstanceExtSimEnvCapi
*pInstanceCapi)
{ return NULL; } // Model_Derivatives, presently not used.
87
Appendix A
extern DLL_EXPORT const char* __cdecl Model_Terminate(InstanceExtSimEnvCapi

*pInstanceCapi)
{
free(pInstanceCapi->ExternalInputs); // free ExternalInputs
pInstanceCapi->ExternalInputs = NULL;
free(pInstanceCapi->ExternalOutputs); // free ExternalOutputs
pInstanceCapi->ExternalOutputs = NULL;
free(pInstanceCapi->Parameters); // free Parameters
pInstanceCapi->Parameters = NULL;
free(pInstanceCapi->ContinuousStates); // free ContinuousStates
pInstanceCapi->ContinuousStates = NULL;
free(pInstanceCapi->StateDerivatives); // free StateDerivatives
pInstanceCapi->StateDerivatives = NULL;
free(pInstanceCapi->MiscStates); // free MiscStates
pInstanceCapi->MiscStates = NULL;
free(pInstanceCapi); // free model instance
pInstanceCapi = NULL;
return NULL;
} // Model_Terminate
88
Appendix B
Appendix B: typedef_export.h File

/* File: typedef_export.h
*
* C source code generated on: 9 Jun 2015
*
* Abstract:
* The header file typedef_export.h contains type declarations for the model's input
* and output that are intended to be exported to external modules.
*
* Reference: Copyright 2006-2007 The MathWorks, Inc.
* This .h file is created mainly based on an example given in the documentation
* center: Embedded Coder in MATLAB.
*
* This file is a header-file template, it is employed when explicit linking method
* is used to link the DLL with external modules.
*/
#ifndef _typedef_export_H_
#define _typedef_export_H_
typedef struct {
real64_T Input;
} typedef_export_Inputs;
typedef struct {
real64_T Output;
} typedef_export_Outputs;
#endif /*_typedef_export_H_*/
/*End of file */
89
Appendix C
Appendix C: Modified Appendixes A & B for the Case Study

typedef struct
{ real64_T wr; } typedef_export_Inputs;
typedef struct
{ real64_T Us; } typedef_export_Outputs;
const
static_inputs[] =
{ { "wr", "", 1 }, }; // rotor speed
const
static_outputs[] =
{ { "Us", "", 1 }, }; // intermediate state variable

{
void* handleLib;
handleLib = LOADLIB(TEXT("D:\\Simulink_Coder\\ PSS_DLL\\PSS_win32.dll"));

Dll_initialize_ptr = (void(*)())GETSYMBOLADDR(handleLib, "PSS_initialize");
return (NULL);
}
{
void* handleLib;

handleLib = LOADLIB(TEXT("D:\\Simulink_Coder\\PSS_DLL\\PSS_win32.dll"));
Dll_step_ptr = (void (*)(void))GETSYMBOLADDR(handleLib, "PSS_step");
Dll_terminate_ptr = (void(*)(void))GETSYMBOLADDR(handleLib, "PSS_terminate");
Dll_Input_ptr = (typedef_export_Inputs*)GETSYMBOLADDR(handleLib, "PSS_U");
Dll_Output_ptr = (typedef_export_Outputs*)GETSYMBOLADDR(handleLib, "PSS_Y");
Dll_Input_ptr->wr = INPUT[0];
DLL_step_ptr();
OUTPUT[0]=Dll_Output_ptr->Us;
return (NULL);
}
Notes: the blue tables present the modified codes of the appendix B (typedef_export.h file); the red
tables present the modified codes of appendix A (ext_simenv_API.c).
90
Appendix D
Appendix D: Modified Appendixes A & B for the Case Study:

(for the OMIB Case)
typedef struct
{ real64_T wr1; real64_T ag1; } typedef_export_Inputs;
typedef struct
{ real64_T Us1; real64_T cl;
} typedef_export_Outputs; // POD1 and call time
const StaticESEInputSignal static_inputs[] = { { "wr1", "", 1 },{ "ag1", "", 1 }, }; // rotor speed & angle
const StaticESEOutputSignal static_outputs[] = { { "Us1", "", 1 }, { "cl", "", 1 }, };
// control action "Us" , call time of the API program (the second-level DLL) cl.
{
void* handleLib;
handleLib = LOADLIB(TEXT("D:\\Simulink_Coder\\ MPC_DLL\\MPC_OMIB_win32.dll"));

Dll_initialize_ptr = (void(*)())GETSYMBOLADDR(handleLib, "MPC_OMIB_initialize");
return (NULL);
}
{
void* handleLib;

handleLib = LOADLIB(TEXT("D:\\Simulink_Coder\\ MPC_DLL\\MPC_OMIB_win32.dll"));
Dll_step_ptr = (void (*)(void))GETSYMBOLADDR(handleLib, " MPC_OMIB_step");
Dll_terminate_ptr = (void(*)(void))GETSYMBOLADDR(handleLib, " MPC_OMIB_terminate");
Dll_Input_ptr = (typedef_export_Inputs*)GETSYMBOLADDR(handleLib, " MPC_OMIB_U");
Dll_Output_ptr = (typedef_export_Outputs*)GETSYMBOLADDR(handleLib, " MPC_OMIB_Y");
Dll_Input_ptr->wr1 = INPUT[0];
Dll_Input_ptr->ag 1= INPUT[1];
DLL_step_ptr();
OUTPUT[0]=Dll_Output_ptr->Us1;
OUTPUT[1]=Dll_Output_ptr->cl;
return (NULL);
}
Notes:
the blue tables present the modified codes of the appendix B (typedef_export.h file); the red
91
Appendix E
Appendix E: Modified Appendixes A & B for the Case Study:

(for the Multi-Machine Case)
typedef struct
{ real64_T wr2; real64_T wr1; real64_T ag1; real64_T wr3; real64_T ag3;
real64_T wr4; real64_T ag4; } typedef_export_Inputs;

typedef struct
{ real64_T Us2; real64_T Us1;
typedef_export_Outputs;
real64_T Us3; real64_T Us4;
real64_T cl;
// POD2, POD1, POD3, POD4, call time of the API program.
const StaticESEInputSignal static_inputs[] = { { "wr2", "", 1 }, { "wr1", "", 1 }, { "ag1", "", 1 },

{ "wr3", "", 1 }, { "ag3", "", 1 }, { "wr4", "", 1 }, { "ag4", "", 1 }, }; // rotor speed & angle
const StaticESEOutputSignal static_outputs[] = { { "Us2", "", 1 }, { "Us1", "", 1 }, { "Us3", "", 1 },
{ "Us4", "", 1 }, { "cl", "", 1 }, }; // control action "Us" , call time of the API program cl.
{
void* handleLib;
handleLib = LOADLIB(TEXT("D:\\Simulink_Coder\\ MPC_DLL\\MPC_4G_win32.dll"));

Dll_initialize_ptr = (void(*)())GETSYMBOLADDR(handleLib, "MPC_4G_initialize");
return (NULL);
}
{
void* handleLib;

handleLib = LOADLIB(TEXT("D:\\Simulink_Coder\\ MPC_DLL\\MPC_4G_win32.dll"));
Dll_step_ptr = (void (*)(void))GETSYMBOLADDR(handleLib, " MPC_4G_step");
Dll_terminate_ptr = (void(*)(void))GETSYMBOLADDR(handleLib, " MPC_4G _terminate");
Dll_Input_ptr = (typedef_export_Inputs*)GETSYMBOLADDR(handleLib, " MPC_4G _U");
Dll_Output_ptr = (typedef_export_Outputs*)GETSYMBOLADDR(handleLib, " MPC_4G _Y");
Dll_Input_ptr->ag1 = INPUT[2];
DLL_step_ptr();
92
Appendix E
OUTPUT[1]=Dll_Output_ptr->cl;
return (NULL);
}
Notes: the blue tables present the modified codes of the appendix B (typedef_export.h file); the red
93
References
References
[1.1] Guang-kai Li and Geng-yin Li, The summary of power system simulation software, Journal
of EEE, vol. 27, no. 3, pp.6265, 2005.
[1.2] S Chaoyue, Discussing on Selection of Power System Simulation Softwares, 2015. [Online].
Available: http://www.paper.edu.cn/en. [Accessed 5 7 2015].
[1.3] Matthias Stifter, Roman Schwalbe, Filip Andren,and Thomas Strasser,Steady-State CoSimulation with PowerFactory, 2013 Workshop on Modeling and Simulation of Cyber-Physical
Energy Systems (MSCPES), Berkeley, CA, May. 2013.
[1.4] R. L. Hendriks, J. Fortmann, M. Bley, L. Cai, O. Ruhle, B. Kulicke, Towards a Cross-Platform
Binary Interface for Time-Domain Simulation Models, 10th International Workshop on Large-Scale
Integration of Wind Power into Power System as well as on Transmission Networks for Offshore
Wind Farms, Aarhus, Denmark 2011.
[1.5] Shuangxi Wu, Wenchuan Wu,, Boming Zhang, A Validation Method for Power System
Dynamic Simulation Software Based on Hybrid Simulation, Power and Energy Engineering
Conference (APPEEC), 2012 Asia-Pacific, Shanghai, March. 2012.
[1.6] LI Ya-lou and WU Zhong-xi, An Approach to Interface Matlab Model with PSASP Transient
Stability Module, Power System Technology, vol. 32, no. 19, Oct. 2008.
[1.7] Thomas Strasser, Matthias Stifter, Filip Andrn, and Peter Palensky, Co-Simulation Training
Platform for Smart Grids, IEEE Transactions on Power Systems, vol. 29, no. 4, July 2014.
[1.8] Wang Yong, Li Feng, Pan Lingling, Liu Jun, Xu Peng, Dynamic process simulation system
based on power flow API of PSS/E, Power System Protection and Control, vol.42, no.15, Aug. 2014.
[1.9] Wang Yong, Li Feng, Pan Lingling, Liu Jun, Xu Peng, Research and Application of Secondary
Development Using API of PSS/E, 2014 China International Conference on Electricity Distribution
(CICED 2014), Shenzhen, Sep. 2014.
[1.10] P. Kundur, Power System Stability and Control, McGraw-Hill: New York, 1994.
[1.11] I. Erlich, A. Hashmani, F. Shewareg, Selective Damping of Inter Area Oscillations Using
Phasor Measurement Unit (PMU) Signals, the 2011 IEEE Trondheim PowerTech, 2011.
[1.12] A.A. Hashmani, I. Erlich, Mode selective damping of power system electromechanical
oscillations using supplementary remote signals, IET Generation, Transmission & Distribution, Vol.
4, Iss. 10, pp. 1127-1138, 2010.
[1.13] Konrad KuBner, Istvan Erlich, and Hans-Helmut Wilfert, Design of Inter-Area Oscillation
Damping Controllers using Global Measurements, 2001 IEEE Porto Power Tech Conference, Porto,
Portugal, Sep. 2001.
94
References
[1.14] Imperial College London Robust damping of interarea oscillations in power systems using
facts controllers [Online]. Available: http://www3.imperial.ac.uk/controlandpower/research/
portfoliopartnership /projects.
[1.15] Hecotr F. Latorre S, Modeling and Control of VSC-HVDC Transmissions, Royal Institute
of Technology, School of Electrical Engineering, Electric Power Systems, Stockholm, Sweden, 2011.
[1.16] F. L.Gyugyi, C.D. Schauder. S.L. Torgenon and A. Edris,The Unified Power Flow Controller:
A new approach to Power Transmission Control, IEEE Trans. On Power Delivery, Vol. 10, No. 2,
pp.1088-1097, 1995.
[1.17] Z. Huaang, Y.X. Ni, C. M. She, F. F. Wu, S. Chen, and B.Zhang, Application of Unified
Power Flaw controller in interconnected Power Systems modeling, interface, control, strategy, and
case study, IEEE Trans. On Power Systems. Vol.15, No.2, pp. 817-824, May 2000.
[1.18] L.J. Cai and I. Erlich, Simultaneous Coordinated Tuning of PSS and FACTS Controller for
Damping Power System Oscillations in Multi-Machine Systems, 2003 IEEE Bologna PowerTech
Conference, Bologna, Italy, June, 2003.
[1.19] H.U.B, A.Luna, P.Rodriguez, A.Cabrera, H.Ghorbani, S.Ying, Performance Analysis of Conventional PSS and Fuzzy Controller for Damping Power System Oscillations, 2003 IEEE Bologna
PowerTech Conference, Bologna, Italy, June, 2003.
[1.20] D.Wang, M. Glavic, and L.Wehenkel, A new MPC scheme for damping wide-area electromechanical oscillations in power systems, the 2011 IEEE Trondheim PowerTech.
[1.21] D.Wang M. Glavic L.Wehenkel, Distributed MPC of wide-area electromechanical oscillations of large-scale power systems, Intelligent System Application to Power Systems (ISAP), 2011
16th International Conference, Hersonissos, 25-28 Sept. 2011.
[1.22] T.T. Nguyen and S. R. Wagh, Model Predictive Control of FACTS Devices for Power System
Transient Stability, IEEE T&D Asia 2009.
[1.23] Md. S.S, Md. A.A, M.I.R, A.I. Khan, Comparison of MPC and conventional control methods
for the stability enhancement of UPFC connected SMIB system, 2nd International Conference on
Advances in Electrical Engineering (ICAEE 2013), Dhaka, Bangladesh, Dec, 2013.
[1.24] A.N. Fuchs, S. Mariethoz, M. Larsson, and M. Morari, Constrained optimal control of VSCHVDC for power system enhancement In IEEE Powercon, Power System Technology, Hangzhou,
China, October 2010.
[1.25] A.N. Fuchs, S.Mariethoz, M. Larsson, and M. Morari, Grid stabilization through VSC-HVDC
using wide area measurements, the 2011 IEEE Trondheim PowerTech.
[1.26] A.N. Fuchs, M.Imhof, T.Demiray, and M.Morari, Stabilization of Large Power Systems
Using VSCHVDC and Model Predictive Control, IEEE Transactions on Power Delivery, vol.29,
95
References
No.1, Feb 2014.

[1.27] Paul Mc Namara, Rudy R. Negenborn, Bart De Schutter, and Gordon Lightbody, Optimal
Coordination of a Multiple HVDC Link System Using Centralized and Distributed Control, IEEE
Transactions on Control Systems Technology, vol.21, No.2, Mar. 2013.
[1.28] Sahar Pirooz Azad, Reza Iravani, Joseph Euzebe Tate, Damping Inter-Area Oscillations
Based on a Model Predictive Contro (MPC) HVDC Supplementary Controller, IEEE Transactions
on Power System, Vol.28, No.3, August 2013.
[1.29] International ElectroTechnical Commission (IEC), "IEC 61400-27-1:2015: Generic Software
Interface for Use of Models in Different Software Environments," in International Electrotechnical
Commission, 2015.
[2.1] Microsoft Developer Network Library. "Visual C++: DLLs in Visual C++", 2015. [Online].
Available: https://msdn.microsoft.com/en-us/library/1ez7dh12.aspx. [Accessed 7 5 2015].
[2.2] Microsoft Developer Network Library. "Dynamic-Link Libraries", 2015. [Online]. Available:
https://msdn.microsoft.com/en-us/library/ms682589 (v=vs.85).aspx. [Accessed 7 5 2015].
[2.3] Microsoft Developer Network Library. "__declspec", 2015. [Online]. Available: https://
msdn.microsoft.com/en-us/library/y4h7bcy6.aspx. [Accessed 14 5 2015].
[2.4] Microsoft Developer Network Library. "Importing and Exporting", 2015. [Online]. Available:
https://msdn.microsoft.com/en-us/library/z4zxe9k8.aspx. [Accessed 15 5 2015].
[2.5] Microsoft Developer Network Library. "LIB Reference", 2015. [Online]. Available:
https://msdn.microsoft.com/en-us/library/f0z8kac4.aspx. [Accessed 16 5 2015].
[2.6] The MathWorks, Inc., "Documentation Center: Embedded Coder, " 1994-2013 The
MathWorks, Inc, 2013.
[2.7] National Instruments, "Calling a DLL in CVI: Explicit Linking vs. Implicit Linking (Dynamic
vs. Static) ", 2009. [Online]. Available: http://www.ni.com/tutorial/8503/en/. [Accessed 16 5 2015].
[2.8] Microsoft Developer Network Library. "Dynamic-Link Library Reference", 2015. [Online].
Available: https://msdn.microsoft.com/en-us/library/ms684175(v=vs.85).aspx.[Accessed 16 5 2015].
[2.9] Microsoft Windows Dev Center. "Process Interoperability", 2015. [Online]. Available: https://
msdn.microsoft.com/en-us/library/windows/desktop/aa384231%28v=vs.85%29.aspx. [Accessed 18
5 2015]
[2.10] Reflections on IT. "Accessing 32-bit DLLs from 64-bit code", 2007. [Online]. Available:
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/ [Accessed 18 5 2015]
[3.1] WIKIPEDIA. "Application programming interface", 2015. [Online]. Available: http://en.
96
References
wikipedia.org/wiki/Application_programming_interface#cite_note-1. [Accessed 20 5 2015].

[3.2] David Orenstein. "COMPUTERWORLD: Application programming interface", 2000. [Online].
Available: http://www.computerworld.com/article/2593623/app-development/ applicationprogramming-interface.html. [Accessed 20 5 2015].
[3.3] R.L.Hendriks, J.Fortmann, M.Bley, L.Cai, O.Ruhle, B.Kulicke, Towards a Cross-Platform
Binary Interface for Time-Domain Simulation Models, 10th international workshop on Large-Scale
Integration of Wind Power into Power Systems as well as on Transmission Networks for Offshore
Wind Farms, Aarhus, Denmark 2011.
[3.4] DIgSILENT, PowerFactory Interfaces, 2015. [Online]. Available: http://www.digsilent.de/
index.php/products-powerfactory-interfaces.html#bottom. [Accessed 21 5 2015]
[3.5] MathWorks, Supported and Compatible Compilers Release 2015a, 2015. [Online].
Available: http://www.mathworks.com/support/compilers/R2015a/index.html [Accessed 24 5 2015]
[3.6] The MathWorks, Inc., "Documentation Center: Simulink Coder, " 1994-2013 The MathWorks, Inc, 2013.
[3.7] International ElectroTechnical Commission (IEC), "IEC 61400-27-1:2015: Generic Software
Interface for Use of Models in Different Software Environments," in International Electrotechnical
Commission, 2015.
[3.8] Zhongli W, Huida D, Yufeng G, Matlab Application in Electrical Engineering and Automation, Tsinghua University Press, 2007
[3.9] D.P.Kothari, I.J.Nagrath, Power System Engineering, New Delhi: Tata McGraw-Hill, 2008.
[3.10] The MathWorks, Inc., "Documentation Center: MATLAB Coder, " 1994-2013 The MathWorks, Inc, 2013.
[3.11] MathWorks, SIMULINK, 2015. [Online]. Available: http://www.mathworks.com/products/
simulink/index.html
[Accessed 26 5 2015]
[3.12] The MathWorks, Inc., "Documentation Center: Simulink, " 1994-2013 The Math-Works,
Inc, 2013.
[3.13] MathWorks, MATLAB Coder, 2015. [Online]. Available: http://www.mathworks.com/
products/matlab-coder/.
[Accessed 26 5 2015]
[3.14] MathWorks, Simulink Coder, 2015. [Online]. Available: http://www.mathworks.com/

products/simulink-coder/.
[Accessed 2 6 2015]
[3.15] The MathWorks, Inc., "Documentation Center: Embedded Coder, " 1994-2013 The MathWorks, Inc, 2013.
[3.16] Microsoft, Visual Studio, 2015. [Online]. Available: https://msdn.microsoft.com/engb/vstudio.
[Accessed 4 6 2015]
97
References
[3.17] WIKIPEDIA. "Microsoft Visual Studio", 2015. [Online]. Available: http://en.wikipedia.org/

wiki/Microsoft_Visual_Studio. [Accessed 4 6 2015].
[3.18] Ralph Hendriks, PSSNETOMAC DLL-model: Application Notes, Siemens AG, Power
Technologies International, 2012.
[3.19] Energy Sector, Siemens AG, PSSProduct Suite Overview, Erlangen, 2009.
[3.20] Olaf Ruhle, Read-In and Usage of Manufacturer DLLs in PSSNETOMAC and
NETDRAW, Erlangen, 2012.
[4.1] P. Kundur, Power System Stability and Control, McGraw-Hill: New York, 1994.
[4.2] Guangqi. Liu, Power System Transient Analysis, China Electric Power Press, 2007.
[5.1] S. J. Qin and T. A. Badgwell, A survey of industrial model predictivecontrol technology,

Control Engineering Practice, vol. 11, no. 7, pp.733764, 2003.
[5.2] Hong Chen, Model Predictive Control, Science Press, 2007
[5.3] David Di Ruscio, Model Predictive Control with Integral Action: A simple MPC algorithm,
Modelling, Identification and Control, Vol. 34 No.3, 2013, pp.119-129, ISSN 1890-1328
[5.4] Dimitry Gorinevsky, Lecture14- Model Predictive Control Part1: The Concept, Seminar
Course of Stanford University, Spring, 2005.
[5.5] Alberto Bemporad, Manfred Morari, N. Lawrence Ricker, Model Predictive Control
Toolbox Users Guide 2014a, The MathWorks,Inc, 2014.
[5.6] Sahar Pirooz Azad, Reza Iravani, Joseph Euzebe Tate, Damping Inter-Area Oscillations Based
on a Model Predictive Contro (MPC) HVDC Supplementary Controller, IEEE Transactions on
Power System, Vol.28, No.3, August 2013.
[5.7] The MathWorks,Inc, Control System Toolbox Users Guide R2014b, 2014.
[5.8] D.Rowell, Discrete Time Observers and LQG Control, Massachusetts Institute of Technology,
Department of
Mechanical Engineering, 2.151 Advanced System Dynamics and Control.
[5.9] Elbert Hendricks, Ole Jannerup, Paul Haase Srensen, Linear Systems Control: Deterministic
and Stochastic Methods, Springer ISBN: 978-3-540-78486-9 (Online), pp.476-477, 2008.
[5.10] Liuping Wang, Model Predictive Control System Design and Implementation Using
MATLAB, Springer, 2008.
[5.11] Shousong Hu, Automatic Control Theory, Science Press ISBN:978-7-03-018955-4, pp. 506,
2007.
[5.12] John L. Crassidis, John L. Junkins, Optimal Estimation of Dynamic Systems, CRC Press,
Second Edition, pp.202, October 26, 2011
98
References
[5.13] Elbert Hendricks, Ole Jannerup, Paul Hasse Sorensen, Linear Systems Control: Deterministic
and Stochastic Methods, Springer, ISBN: 978-3-540-78485-2, pp.477, 2008.
[5.14] H.M.A.Hamdan, A.M.A.Hamdan On the coupling measures between modes and state
variables and sub synchronous resonance, Electric Power System Research, pp.165-171, 1987.
[5.15] Alberto Bemporad, Manfred Morari, N. Lawrence Ricker, Model Predictive Control
Toolbox Users Guide 2014b, The MathWorks,Inc, 2014.
[5.16] Jixin Qian, Jun Zhao, Zuhua Xu, Predictive Control, Chemical Industry Press, 2007.
[5.17] P. M. Namara, R. R. Negenborn, B.D.Schutter, G.Lightbody, Optimal Coordination of a
Multiple HVDC Link System Using Centralized and Distributed Control, IEEE Transactions on
Control System Technology, Vol.21, No.2, March 2013.
99

Master Thesis Bai Jiachen

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Master Thesis Bai Jiachen

Hochgeladen von

Copyright:

Verfügbare Formate

Master Thesis

A thesis submitted to the University Duisburg-Essen

A Study of Cross-Platform Interface Based on Dynamic Link

3.4.2 Modelling Option 1: MATLAB Code ............................................................................ 20

5.3.1 MPC Based POD Controller in OMIB System ............................................................... 55

1.2 Objectives and Contributions of This Thesis

1.3 Outline of This Thesis

2 Dynamic Link Library (DLL)

2 Dynamic Link Library (DLL)

2.1 Advantages of DLL

2.2 DLL Program Architecture

2 Dynamic Link Library (DLL)

2.2.1 Program Code Layer

2 Dynamic Link Library (DLL)

2.2.2 Program File Layer

: Programming codes allocation.

2.3 DLL Creation

2 Dynamic Link Library (DLL)

(e.g. Visual Studio)

DLL File Creation

2 Dynamic Link Library (DLL)

software automatically, method 2 (semi-automatic) is adopted for simplifying DLL creation.

2.3.2 Coding Phase

2 Dynamic Link Library (DLL)

Program Function and Program Data

DLL File Creation

Figure 2.4: Procedures in the coding phase of DLL creation.

2 Dynamic Link Library (DLL)

2.3.3 Linking Phase

2 Dynamic Link Library (DLL)

Export Method for Exported Function and Data

+ Import File ( .lib file )

DLL File Creation

+f: Additional modifier or file.

Figure 2.5: Procedures in the linking phase of DLL creation.

2.4 Linking Work in External Module ( .dll or .exe File)

2 Dynamic Link Library (DLL)

Original External Module (.dll or .exe file)

The Main Source File of

Linked with the .lib File

Return A Handle to External Module

GetProcAdress (Handle, ProcName);

The Main Source File of External Module

Linkable External Module

2 Dynamic Link Library (DLL)

2.5 Interoperability Issue between 32-Bit and 64-Bit Programs

3 Application Programming Interface (API)

3 Application Programming Interface (API) and Case Study

3.1 Introduction to General API

: Mode 2 (Semi-Automatic Mode)

: Mode 3 (Hybrid Mode)

Figure 3.1: structural description of a general API based case.

3 Application Programming Interface (API)

various simulation functionality from the model.

: Workflow for PSSNETOMAC

Figure 3.2: Procedures for creating and calling a general API.

3 Application Programming Interface (API)

3.2 Introduction to API between MATLAB and PSSNETOMAC

3 Application Programming Interface (API)

:Workflow for MATLAB

3 Application Programming Interface (API)

Figure 3.5: Execution mechanism of API in the time-domain simulation.

3.3 Introduction to Case Study: A Mathematical Model for API Study

3 Application Programming Interface (API)