A NEW APPROACH TO CZJSTOMIZESECONDARY DEVICE
MODELS IN A DISPATCHER TRAINING SIMULATOR (DTS)
Pan Zhelong,
Sun Hongbin,
Wu Wenchuan,
TEEE Member
Zhang Boming
IEEE Senior Member
Electrical Engineering Department, Tsinghua University, Beij ing, China
’
Abstract - Modern power systems are becoming
increasingly complex in operation and control due to more
and more new techniques and new devices introduced into
the systems. To ensure secure and economic operation of
the power systcms, especially in the environment of
deregulation, a Dispatcher Training Simulator (DTS) needs
to be developed. To simulate secondary devices (including
relays and automatic facilities) realistically in the DTS, it is
important to develop a user-friendly tool to customize the
secondary device models. This paper presents a new
approach to customize the simulation of secondary devices
in a dispatcher training simulator. A kind of script
language is designed to define the device models, which are
interpreted by an inner driver program. Meanwhile, the
introduction of component models, which describe the
common parts of different secondary devices, facilitates
users’ work. This paper also provides some solutions to the
problem of the data management and to the problem of
simulation speed. As the result, users can define secondary
devices flexibly and control the process of power flow
calculation and fault calculation by themselves. The new
approach proposed here has been applied to several
practical Chinese DTS systems.
device, which results in an extremely large amount of
effort needed to put a DTS into practice. Owing to lack
of special knowledge on such devices, developers are at
pains to design them. And users can not change the
models without the vendor’s help.
Mr. Wu [l] has implemented a kind of user-defined
model in a DTS. The model is based on a hierarchical
structure. By this model, user can configure the
automatic devices. However, this kind of model is
somewhat rigid for its fixed structure. And some devices
can not be easily modeled.
This paper presents a new method to customize
secondary device models. In order to make the
definition of the secondary device more flexible and
easy, a kind of script language is designed to define the.
models of secondary devices. In this way, developers of
the DTS do not need to understand principles of all the
secondary devices. Just using this kind of language, not
only developers but also users can describe the models
themselves. Because users can define the secondary
devices themselves to meet their own needs, instead of
resorting to their DTS vendors, they have an access to
simulate some secondary devices newly adopted. And
this method is easier and more flexible than that of the
hierarchical structure, thanks to the script language
something like a kind of programming language.
Meanwhile, components, which describe the common
parts of different secondary devices, are introduced. An
“element - component - device” structure is applied to
define the secondary devices.
In this paper, device data are managed through a
hierarchical directory structure, which is helpful in
seslrching and statistic.
In order to reduce the calculation time and the incore
memory requirement, some efficient treatments are
proposed, such as differentiating model data from
device data, binary coding of models, and reducing the
search scope.
This paper is an extension of our previous work,
which offered much experience in secondary device
simulation. Most of the proposed methods in this paper
have been applied in some practical Chinese DTS
systems.
Keywords: dispatcher training simulator (DTS),
customization, secondary devices simulation, power
systems
‘INTRODUCTION
Modern power systems are becoming increasingly
complex in operation and control due to more and more
new techniques and new devices introduced into the
systems. To ensure secure and economic operation of
the power systems, especially in the environment of
deregulation, a dispatcher training simulator (DTS)
needs to be developed. To simulate secondary devices
(including relays and automatic devices) realistically in
the DTS, it is important to develop a user-friendly tool
to customize the secondary device models.
In order to simulate these devices, following
questions need answering:
- How can they be realistically simulated?
- How can they be quickly simulated?
- Can all these devices be properly modeled?
-Can new models be built to satis@ future
requirements?
A conventional method to simulate secondary devices
is to write a different program for a different secondary
1
0-7803-7459-2/02/$17.000 2002 IEEE
-616-
Authorized licensed use limited to: Mikhail Nesterenko. Downloaded on July 17,2010 at 19:58:21 UTC from IEEE Xplore. Restrictions apply.
2
THE NEW APPROACH
2. I Device Simulation
A secondary device is activated once its criteria are
hit following a power flow or a fault calculation. The
action of the secondary device may drive a circuit
breaker open or close or adjust the output of a generator
up or down.
The simulation of secondary devices in a DTS is
demonstrated in Figure 1. When the system is
initialized, load flow or fault current is calculated, and
results are displayed by MMI (Man Machine Interface).
The module of secondary devices compares these results
with a preset threshold and decides their actions, which
activate another computing cycle of calculation
processes. Trainees and instructors can operate the
facilities directly in the system, also to activate a
computing cycle.
Model 1
...
Figure 2: Relations between models and the driver process
5
Traineehnstructoroperations
Fault calculation
Yes
Activate secondary devices
Figure 1: Secondary device simulation in a DTS
Conventionally, a fixed program was developed to
define the action logic of a secondary device. However,
this method often requires a separate section of program
and one different data structure for one kind of
secondary device, which used to suffer following'
problems:
-When users need to add new models or modify old
models, they have to ask vendors to modify source
codes and recompile them. It is hard to maintain the
system.
- Developers need to know the detailed principles of
the secondary devices, so it takes a long time to
develop this system.
- It is hard to debug and maintain the system, due to
large amounts of programs and data.
In this paper a new method is presented to customize
secondary device models. At first an abstract language is
used to model the devices. After parameters are
specified in database, modeling of the devices is
finished. During the process of simulation, an inner
driver process is designed to interpret these models and
to work as a feedback section of the. numerical
calculation process (power flow calculation and/or fault
calculation). This idea is shown in Figure 2.
Model 2
2.2 Modeling Script Language
In order to contrive these device models and the
driver program more user friendly, this paper employs a
series of key words to describe devices. This language
can be called device modeling script language. The
driver module is designed to interpret these scripts.
This script language includes some keywords, which
are classified into device identification operators.
process control operators, logic operators, calculation
operators, computing functions, system access functions
and so on.
- Device identification operators, such as DEVICE
and COMPONENT. These are the keywords to
initialize defining models.
- Process control operators, such as IF, ELSE, FOR,
WHILE, END, and RETURN.
- Logic operators, such as AND, OR, and NOT.
-Calculation operators, such as +, -, *, /, (, ), >, <,
__
--, !=, and =.
-Computing functions, such as SIN, COS, TAN,
EXP, LOGlO, and LOG.
-Variable type declarators, such as STRING, INT,
FLOAT, and TIME.
- Variable attribute declarators, such as PUBLIC,
PRIVATE, and TEMP.
-System access functions, such as GET and PUT.
GET is used to get calculation results, while PUT is
.taken to change system parameters. The formats are
as follows:
- GET (Device type, Device index, Parameter
OJP4
-PUT (Device type, Device index, Parameter
type, Value)
Where the device types include SYSTEM,
ISLAND, STATION, BUS, LINE, UNIT, LOAD,
TRANSFORMER, BREAKER, CAPACITOR and
so on, and parameter types include VOLTAGE (a
phase or a sequence couXl be specified),
CURRENT (a phase or a sequence could be
specified), POWER (active or reactive), STATE
(breaker state), FREQUENCY, SIMUL-TIME
(simulation time), and so on.
-617-
Authorized licensed use limited to: Mikhail Nesterenko. Downloaded on July 17,2010 at 19:58:21 UTC from IEEE Xplore. Restrictions apply.
- Annotation declarators, such as I*, *I,and If,
Based on these keywords, most devices, such as h.igh
frequency protection, impedance protection, zerosequence protection, busbar protection, under-frequency
protection, reserve power source automatic connection
devices, and so on, can be defined.
For instance, a model of under frequency load
shedding device is described in this script language as
follows.
models can be constructed by these components. A good
component library will facilitate users’ work.
Figure 3 shows the model of distance protection
based on some common components. Every block
stands for a component.
~I
Impedance
/*Under Frequency Load Shedding.
F means frequency; T means time; Brk specifies the
breaker connected to the load.
When systemJi.equency has been lower than F for T
seconds, breaker Brk will be opened. */
DEVICE UFLS (FLOAT F, FLOAT T, INT Brk)
PTLast records the beginning time whenfrequency is
lower than F. Every device needs it, so its attribute is
PRIVATE. */
PRIVA TE TIME TLast;
TEMP TIME TNow;
TEMP FLOAT Freq;
TEMP INT BrkState,Node, Island;
Node =GET(BREAKER,Brk,HEADNODE).
Island=GET(NODE,Node,ISLAND);
//Get system frequency.
Freq =GET(ISLAND,Island, FREQUENCY);
//Get system simulation time.
TNow =GET(SYSTEM,SIMUL-TIME);
IF( Freq>F)
TLast= TNow;
RETURN;
END IF
/*Get the breaker’s state. I stands f o r the
close state; 0 stands f o r the open state. */
BrkState =GET(BREAKER,Brk,STA TE);
IF (TNow-TLast> T AND BrkState = =I)
//Open this breaker.
P UT(BREAKER:Brk,STATE,0);
END IF
END DE VICE
and
i
I
I
I
1
Directional
comparison
F
F
r
,
r
t
Time
delay
I
I
I
I
I
I
I
I
I
I
I
I
I
I
Breaker
action
I
I
I
Distance protection
I
Figure 3: Distance protection composed of components
The developer of a DTS supplies some basic
components (such as the time delay component, the
impedance calculation component, etc), which are
described by the proposed script language. These basic
components can be used to realize some basic functions.
And then users can apply them to model their own
devices. In this way, the modeling process becomes
easier and more convenient. During the implementation
of the DTS, users can also modi@ and expand the
component library themselves.
Although above sentences are simple, they do define
a model. The first sentence, “DEVICE UFLS (FLOAT
F, FLOAT T, INT Brk)”, gives the data format, which is
necessary to specify a real device. Here, Brk is an
integer number, which can accelerate searching. But in
the data file, a name should be given instead of it.
2.4 Data Organization
In its modeling script, each model defines its
necessary parameters. Once the parameters of an actual
device are specified, the DTS system can simulate it
immediately. Because there are substantive secondary
devices in a DTS system, users can shift their attention
to the management of data.
These data are organized through the structure of
“component library - device library - device database”.
The component library comprises a component index
file and several scripts of components. The device
library consists of a device index file and several scripts
of device models.
The device database is managed through a.
hierarchical directory structure of “system-stationdevice”, which is shown in Figure 4.
2.3 Component Design
If users want to define a kind of new device from the
bottom, they will face two problems.
- The device model script is often very complicated
’to learn.
- There is much redundant work, because different
devices may have the same or similar module.
So, the idea of “element-component-device” is
proposed and implemented. In this thought, components
are designed from the bottom (element) and device
-618-
Authorized licensed use limited to: Mikhail Nesterenko. Downloaded on July 17,2010 at 19:58:21 UTC from IEEE Xplore. Restrictions apply.
System
Device M
Secondary devices
Secondary devices
At last, searching scope could be reduced. In a large
system, thousands of protection devices are installed. If
all of them need to be calculated and analyzed,
simulation speed must be a big problem. Actually, only
a few will act. In reference [2] a “window” technology is
proposed. Here a similar method is used. We need only
analyze the protection devices near the fault point. And
the hierarchical data structure is very useful to determine
the scope.
-- belonging to the system
Figure 4: Hierarchical structure of device bank
There is a file recording secondary devices belonging
to a primary device. Every station file records a primary
device index table and the secondary devices belonging
to it. One system file records a station index table and
the secondary devices belonging to it.
It should be mentioned again that, the data format of
secondary devices is defined in the modeling script,
which is shown in section 2.2.
These data are stored in files, but when the DTS is
initialized, all data including modeling scripts and
device data should be loaded into the memory. The
process is shown in Figure 5 .
Load device model scripts
I
Load secondary devices
I
6
Data checking
1
I
Figure 5: Initialization process
I
2.5 Space and Speed
Because there are substantive secondary devices in a
DTS, the problem of space and speed is concerned in
evaluating the performance of the DTS. This paper does
following analyses.
At first, the data attribute is specified in the modeling
script. Most model data, including logic structure and
public data are shared. Every secondary device defines
its unique (PRIVATE) data and needs not copy model
data. Because model data and device data are
differentiated, there are little redundancy data.
Secondly, model scripts are translated into some
binary codes after the system is initialized. The inner
driver process can interpret them more quickly.
3 PRACTICES
Methods proposed in this paper have been applied in
some practical Chinese DTS systems, such as the DTS
of Jilin province, the DTS of the Nantong power control
center in Jiangsu province, the DTS of Shenzhen power
control center in Guangdong province and etc.
For example, in DTS of Shenzhen city, there are
1447 line protectors, 3046 transformer protectors and
some other automatic devices. As a result, users can
define these secondary devices flexibly and can control
the process of power ow calculation and fault
.
calculation effectively. The simulation of prime relay
protection, which has short delay time, is very near real
time (CPU time of simulation is 30ms). Yet the CPU
time of backup relay protection simulation with longer
delay time is a little longer because of the speed of fault
calculation program. In this system, the messages of
secondary devices and circuit breaker actions are output
vividly so that trainee can acquire enough information to
decide what to do next.
? .
4 FUTUREWORK
In order to increase the practicability and flexibility,
visual modeling and data checking are the future work
worth doing.
First, visual modeling, a way to utilize man machine
interface to finish the modeling process, can bring
convenience to users. This technology will enable users
draw a block diagram of a model. Assisted by some
dialog boxes, users can finish constructing a model. This
visual way can also reduce maintenance.
Second, another class of keywords can be designed to
define some rules, which can be used to veri@ the data.
For instance, some parameters must be within a
reasonable range. In this way, the initialization process
can pick out some false data.
5 CONCLUSIONS
This approach to customize secondary device models
provides a.device modeling script language. It can deal
with complex device type and can be adaptive to the
future needs. Hierarchical structure accelerates
searching and facilitates maintenance. Customized
design makes users define secondary devices flexibly.
Differentiating model data and device data reduces the
incore memory used.
ACKNOWLEDGMENTS
- 619 -
Authorized licensed use limited to: Mikhail Nesterenko. Downloaded on July 17,2010 at 19:58:21 UTC from IEEE Xplore. Restrictions apply.
The authors wish to thank Mr. J. Ji Of the Nantong
power control center in Jiangsu province, China for his
professional advices.
a professor in Dept. of E.E., Tsinghua Univ. His
interests include Electricity Marketing, EMS , DTS and
DMS.
REFERENCES
W-UWenchuan, Sun Hongbin, Zhang Boming, et al.
Simulation of Automatic Device Based on UserDefined Model in Integrated EMSDTS. Automation
of Electric Power Systems, vo1.24, 110.4, Feb. 2000,
pp. 57-60.
Yang Shengchun, Wang Like, Zhang Shenming,
Wang Yuanlin. Simulation of relay protection based
on quantitative comparison in DTS dispatcher
training simulators. Automation of Electric Power
Systems, v01.22, no.8, Aug. 1998, pp.30-37.
[3] Podmore R., Giri J. C., Gorenberg M. P., et al. An
Advanced Dispatcher Training Simulator. IEEE
Transactions on Power Apparatus and Systems, vol
PAS-101, no.1, Jan 1982, pp.17-25.
[4] Dyliacco T. E., Enns M. K., Schoeffler J. D.
Considerations in Developing and Utilizing Operator
Training Simulators. IEEE Transactions on Power
Apparatus and Systems, vol. PAS-102, no.11, Nov.
1983, ~ ~ 3 6 7 2 - 3 6 7 9 .
[5] Shiota H., Tamenaga Y., Tsuji T., Dan K.
Development of Training Simulator for Power
System Operators. IEEE Transactions on Power
Apparatus and Systems, vol PAS-102, no.10, Oct
1983, ~ ~ 3 4 3 9 - 3 4 4 5 .
BIOGRAPHIES
Pan Zhelong was born in jiangsu province in China
in 1976. He received his B.S. degree from E.E.,
Tsinghua University in 1998. He is now a graduate
student at Tsinghua Univ. He is interested in the areas of
Energy Management System (EMS) and Dispatcher
Training Simulator (DTS).
Sun Hongbin was born in 1969. He received his
doctorate from Dept. of E.E., Tsinghua Univ. in 199'7.
He is now an associate professor in Dept. of E.E.,
Tsinghua Univ. His interests include Electricity
Marketing, Energy Management System (EMS),
Dispatcher Training Simulator (DTS) and Distribution
Management System (DMS).
Wu Wenchuan was born in 1973. He received his
M.S. degree from E.E., Tsinghua University in 1999. He
is now a researcher at Tsinghya Univ. His interests
include EMS and DTS.
Zhang Boming was born in 1948. He received his
doctorate'from E.E., Tsinghua Univ. in 1985. He is now
- 620 -
Authorized licensed use limited to: Mikhail Nesterenko. Downloaded on July 17,2010 at 19:58:21 UTC from IEEE Xplore. Restrictions apply.