On-Line Presentation of Data from PMU Stations

Arnar M´ar Loftsson
On-Line Presentation of Data
from PMU Stations
M.Sc. Thesis, October 2006

On-Line Presentation of Data from PMU Stations
Author
Supervisors
Associate Professor, Arne Hejde Nielsen, Ørsted-DTU
Associate Professor, Knud Ole Helgesen Pedersen, Ørsted-DTU
Ørsted DTU
Center for Electric Technology (CET)
Technical University of Denmark
Elektrovej
Building 325
DK-2800 Kongens Lyngby
Denmark
www.oersted.dtu.dk
Tel: (+45) 45 25 35 00
Fax: (+45) 45 88 61 11
cet@oersted.dtu.dk
Publication Date 01.10.2006
Class 1.(Public)
Edition 1. edition
Notes This report is part of a M.Sc. Electrical Engineering education
program at the Technical University of Denmark
Copyright c Arnar M´ar Loftson, 2006

Preface
This thesis was prepared at Center for Electric Technology (CET), the Tech-
nical University of Denmark in partial fulﬁllment of the requirements for
acquiring the M.Sc. degree in engineering.
The objective of this thesis is to shed some light on the possibilities of mon-
itoring electrical measurement data over a network. The data is generated
by a device called a Phasor Measurement Unit (PMU).
The thesis consists of the work done at Ørsted DTU, while developing a
client-server program. The work took place in the eight month period of
March to October 2006.
Lyngby, October 2006

Abstract
The following thesis describes the development process of designing and
implementing a client-server program. The main purpose of the program is
to remotely present on-line measurement data from PMU stations, developed
at DTU. The data presented is also to be stored in a database on a temporary
basis.
The LabVIEWR
software from National Instruments Corporation was used
to develop the client-server program as well as the database interface using
the LabVIEWR
Database Toolset. The project was twofold: At one hand
the implementation of a server program to interact with existing PMU soft-
ware. On the other hand the design of a client capable of receiving data
from two stations simultaneously, monitor it and store it.
The method chosen to communicate between the client and the server, was
the Global Variable method. The server writes several measurements in an
array to a Global Variable where the client can read them and monitor them
one by one. The Global Variable can be placed either at the server or at the
client.

Contents
Preface i
Abstract iii
List of Figures ix
List of Tables xiii
List of Symbols xvii
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem Description . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Limitations and Requirements . . . . . . . . . . . . . . . . . . 3
1.5 Work of Others . . . . . . . . . . . . . . . . . . . . . . . . . . 3

vi CONTENTS
1.6 Range of Work . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 The Phasor Measurement Unit 5
2.1 Description of the PMU . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 The DTU PMU . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Satellite system . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 The Phasors . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Data Transmission . . . . . . . . . . . . . . . . . . . . 7
2.2 Standards for Synchrophasors for Power Systems . . . . . . . 8
2.2.1 The 1995 Standard . . . . . . . . . . . . . . . . . . . . 8
2.2.2 The 2005 Standard . . . . . . . . . . . . . . . . . . . . 9
2.3 The Cyclic Redundancy Check . . . . . . . . . . . . . . . . . 11
2.3.1 CRC in general . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 The CRC of the DTU PMU . . . . . . . . . . . . . . . 12
2.3.3 CRC Discussion . . . . . . . . . . . . . . . . . . . . . 13
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Design and Construction 15
3.1 Client-Server Programming Methods . . . . . . . . . . . . . . 15
3.1.1 The TCP/IP Method . . . . . . . . . . . . . . . . . . 16
3.1.2 The Global Variable Method . . . . . . . . . . . . . . 17
3.1.3 TCP/IP Compared to Global Variable . . . . . . . . . 18

CONTENTS vii
3.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 The Server Simulation Program . . . . . . . . . . . . . 20
3.2.2 The Client Simulation Program . . . . . . . . . . . . . 20
3.2.3 Simulation Results . . . . . . . . . . . . . . . . . . . . 23
3.3 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 Global Queues . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2 Double Buﬀer System . . . . . . . . . . . . . . . . . . 26
3.3.3 Shared Variables . . . . . . . . . . . . . . . . . . . . . 27
3.3.4 Timed Structures . . . . . . . . . . . . . . . . . . . . . 27
3.3.5 Initial Synchronization . . . . . . . . . . . . . . . . . . 28
3.3.6 The Synchronization Check . . . . . . . . . . . . . . . 28
3.4 Loop Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.1 Database Setup . . . . . . . . . . . . . . . . . . . . . . 32
3.5.2 Database Limitations . . . . . . . . . . . . . . . . . . 32
3.5.3 The Data Storage . . . . . . . . . . . . . . . . . . . . 33
3.5.4 Improved Database VIs . . . . . . . . . . . . . . . . . 35
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4 Electrical Data Analysis 39
4.1 Phase Angle Diﬀerence . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Power Calculations . . . . . . . . . . . . . . . . . . . . . . . . 42

viii CONTENTS
4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Program Architecture 45
5.1 The Program Manual . . . . . . . . . . . . . . . . . . . . . . 45
5.1.1 The Server Manual . . . . . . . . . . . . . . . . . . . . 47
5.1.2 The Client Manual . . . . . . . . . . . . . . . . . . . . 48
5.2 The Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3 Description of the VIs . . . . . . . . . . . . . . . . . . . . . . 50
5.3.1 The Server VIs . . . . . . . . . . . . . . . . . . . . . . 51
5.3.2 The Client VIs . . . . . . . . . . . . . . . . . . . . . . 54
5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Conclusion 61
6.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3 The Broader Perspective . . . . . . . . . . . . . . . . . . . . . 63
A The DTU PMU LabVIEW Program Overview 65
B Packet Description 69
C Additional Database VIs 73
C.1 The Hierarchy of the Additional Database VIs . . . . . . . . 74
C.2 Description of the Additional Database VIs . . . . . . . . . . 75

CONTENTS ix
D Functional Global Variables 77
D.1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 78
E The Program CD 79
Bibliography 81

List of Figures
2.1 Data frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Simple TCP/IP server . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Simple TCP/IP client . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Simple Global Variable server . . . . . . . . . . . . . . . . . . 17
3.4 Simple Global Variable client . . . . . . . . . . . . . . . . . . 17
3.5 Conﬁguration of PMUs and client . . . . . . . . . . . . . . . . 19
3.6 The server simulation block diagram . . . . . . . . . . . . . . 21
3.7 The client simulation block diagram . . . . . . . . . . . . . . 22
3.8 The ”array” server block diagram . . . . . . . . . . . . . . . . 24
3.9 Single global queue . . . . . . . . . . . . . . . . . . . . . . . . 26
3.10 Double global queue . . . . . . . . . . . . . . . . . . . . . . . 26
3.11 Loop timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.12 Angle mean value . . . . . . . . . . . . . . . . . . . . . . . . . 35

xii LIST OF FIGURES
3.13 Block diagram of DB VIs . . . . . . . . . . . . . . . . . . . . 36
3.14 Improved block diagram of DB VIs . . . . . . . . . . . . . . . 36
4.1 Equivalent π circuit . . . . . . . . . . . . . . . . . . . . . . . 41
5.1 Overview of the program . . . . . . . . . . . . . . . . . . . . . 46
5.2 Front panel of PMU COMMON.vi . . . . . . . . . . . . . . . 47
5.3 Front panel of Client.vi . . . . . . . . . . . . . . . . . . . . . 48
5.4 Front panel of monitor VI . . . . . . . . . . . . . . . . . . . . 49
5.5 The Server Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 50
5.6 The Client Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 51
5.7 Server flow chart . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.8 Server block diagram . . . . . . . . . . . . . . . . . . . . . . . 53
5.9 Client block diagram . . . . . . . . . . . . . . . . . . . . . . . 54
5.10 Client flow chart . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.11 Inputs and Output of ChkandBuff.vi . . . . . . . . . . . . . . 56
5.12 Inputs and Output of ArraytoClusters.vi . . . . . . . . . . . . 57
5.13 Monitor flow chart . . . . . . . . . . . . . . . . . . . . . . . . 57
5.14 Write to DB flow chart . . . . . . . . . . . . . . . . . . . . . . 58
5.15 Inputs and Outputs of DayTable.vi . . . . . . . . . . . . . . . 59
5.16 Inputs of TableOperations.vi . . . . . . . . . . . . . . . . . . 59
A.1 DTU PMU Flowchart . . . . . . . . . . . . . . . . . . . . . . 66

LIST OF FIGURES xiii
A.2 DTU PMU Serial ﬂowchart . . . . . . . . . . . . . . . . . . . 67
A.3 DTU PMU Log and IEEE . . . . . . . . . . . . . . . . . . . . 68
C.1 The Database VIs Hierarchy . . . . . . . . . . . . . . . . . . . 74
C.2 Save to DB ﬂow chart . . . . . . . . . . . . . . . . . . . . . . 75
C.3 Inputs and Outputs of MeanCnt.vi . . . . . . . . . . . . . . . 76
C.4 Inputs and Output of MeanCalc.vi . . . . . . . . . . . . . . . 76
C.5 Inputs of DatatoDB.vi . . . . . . . . . . . . . . . . . . . . . . 76
D.1 Block diagram of a FGV . . . . . . . . . . . . . . . . . . . . . 78

List of Tables
2.1 Data frame organization I . . . . . . . . . . . . . . . . . . . . 9
2.2 Data frame organization II . . . . . . . . . . . . . . . . . . . 10
2.3 CRC Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Synchronization pseudo code I . . . . . . . . . . . . . . . . . 29
3.2 Synchronization pseudo code II . . . . . . . . . . . . . . . . . 29
3.3 Synchronization pseudo code III . . . . . . . . . . . . . . . . 30
3.4 Data extracted from the IEEE string . . . . . . . . . . . . . . 34
3.5 Mean value of angle algorithm . . . . . . . . . . . . . . . . . . 35
B.1 MS-DOSR
to WindowsR
Packet . . . . . . . . . . . . . . . . 70
B.2 The stat0 variable . . . . . . . . . . . . . . . . . . . . . . . . 71
B.3 The stat1 variable . . . . . . . . . . . . . . . . . . . . . . . . 71
B.4 Indexed data description . . . . . . . . . . . . . . . . . . . . . 72

List of Symbols
Symbol Deﬁnition
CRC The Cyclic Redundancy Check
DB Database
DTU Technical University of Denmark
FGV Functional Global Variable
GPS Global Positioning System
IEEE Institute of Electrical and Electronics Engineers
NI National Instruments
ODBC Open Database Connectivity
PC Personal Computer
PMU Phasor Measurement Unit
SOC Second of Century
SQL Structural Query Language
TCP/IP Transmission Control Protocol/Internet Protocol
TOL Time of Loop
UDL Universal Data Link
UTC Universal Time Coordinated
VI Visual Instrument
WACS Wide Area Stability and Voltage Control System
WAMS Wide Area Measurement System

Chapter 1
Introduction
Increasing technology development and better life standards of the mod-
ern society demand more stable, top quality electricity. In meeting these
demands the high voltage industry has been adding new technology to its
equipment in order to maximize its efficiency. This is often the only option
available as it is not always possible to add more power plants or transmis-
sion lines especially in populated areas where the need for more power is
perhaps the greatest.
One of those new technologies implemented in the modern power system
is the Phasor Measurement Unit (PMU). In general the main purpose of
the PMU is to synchronize measurements at different locations in the power
grid by using the GPS technology. This technology is called Wide Area
Measurement System (WAMS).
Development of the PMU is well on its way in several countries, e.g. in
USA they have developed technology called Wide–Area Stability and Volt-
age Control System (WACS), where they can receive and analyze measure-
ment data live [7]. An obvious advantage of that is the ability to foresee
a fault and thus the capability to take the necessary measures to minimize
the fault’s effect on the system or even stop the fault from occurring.

2 Introduction
1.1 Background
In Denmark there are ﬁve PMU stations located in Sealand. These stations
measure the system frequency and the voltage magnitude and phase angle at
the place where they are located. Some of them also measure currents. The
information obtained from these measurements is then sent through network
connections and stored at DTU. The need for receiving and analyzing the
data on-line is increasing. Therefore the main topic of this thesis was to
investigate methods for receiving on-line data from PMU stations.
1.2 Problem Description
The technology and the possibilities to upgrade the existing PMUs in Den-
mark are available today. Thus will this thesis aim to ﬁnd methods for
sending data on-line from PMU stations to a remote client.
In order to achieve that goal the following barriers must be surmounted.
• What software available today can meet up to the demands that this
project calls for?
• What methods can be used to ensure speed and reliability demands?
• Does the data need be stored at the client?
• What sort of electrical analyzation shall be done on the data?
• Is there need for comparison of data between more than two stations
at the same time?
These are the main questions that will be answered in this thesis.
1.3 Method
The idea is to modify existing PMU software so that the PMU can be
considered as a host or a server that delivers data to a network. At the

1.4 Limitations and Requirements 3
other end a guest or a client needs to be created in order to receive and
analyze the data generated by one or more PMUs at the same time.
Basic programming methods will be used to overcome this project. At ﬁrst
a simulation with real, existing data will be developed. Then the programs
developed in the simulation process will be adjusted to the actual PMU
stations located at DTU.
1.4 Limitations and Requirements
The work on this project is entirely going to take place at DTU that will,
inevitably, result in some limitations to the outcome of this project. The
number of PMU stations, to be worked with and tested, will be limited to
two. Also the server and the client will be on the same network but not
remotely connected as would be the case in practice.
Because of these limitations it must be required that the ﬁnal version of the
resulting program will be easily upgradeable so that it can be implemented
in practice. The program must also be able to handle all measurements
without any delay as well as any error that might occur.
1.5 Work of Others
This project will mainly be based on the software part of the PMU developed
at DTU. This software part was written in LabVIEWR
by one of this thesis
instructors, Associate Professor, Knud Ole Helgesen Pedersen, Ørsted-DTU.
1.6 Range of Work
For those still wondering what PMU stations are, then chapter 2 should
answer most of their questions. The basic structure of the PMU is described
along with most of its vital attributes.
Chapter 3 includes the design and construction of the work done in this
project. Among topics discussed are client-server programming methods,

4 Introduction
simulation process, synchronization, and database operations.
The electrical data analyzation is discussed in chapter 4 where the methods
used by the program, developed for this project, is accounted for.
The client-server program developed for this project and its architecture is
the topic of chapter 5. It starts with the program manual describing the user
interface of the program. Following the manual is a detailed description of
the programs developed. This chapter is very illustrative as the program
hierarchy, ﬂow charts and block diagrams ﬁll the pages.
Finally the conclusion of the work done can be read in chapter 6.

Chapter 2
The Phasor Measurement Unit
The Phasor Measurement Unit (PMU) is a generic device that produces
synchronized phasors from voltage and/or current inputs and synchronizing
signal. The signal provided by the synchronizing source shall be referenced
to Universal Time Coordinated (UTC). In order to synchronize the PMU
stations, the time signal is broadcasted from satellites.
2.1 Description of the PMU
The PMU stations developed at DTU have been installed at four diﬀerent
locations in the eastern electricity net in Denmark. Furthermore two stations
are at DTU on a research and development basis.
2.1.1 The DTU PMU
The DTU PMU stations commonly consist of two PCs where one is run-
ning the MS-DOSR
operating system and the other is running Microsoft
WindowsR
operating system. The MS-DOSR
computer has the role to re-
trieve measurements from the measurement equipment and place them in a

6 The Phasor Measurement Unit
package, along with other vital information, which is sent to the WindowsR
computer. The packet description can be seen in appendix B.
The reason for choosing MS-DOSR
as the operating system for the mea-
surement computer was to gain full control of the computer. By modifying
the AUTOEXEC.bat and the CONFIG.sys files in the MS-DOSR
system
many computer actions, for example updating the screen and configuring
network connections, can be turned off. These actions are unwanted by the
measurement part of the PMU as they can interrupt measurements causing
inaccuracy in the critical timing of the measurements.
The WindowsR
computer then runs a LabVIEWR
program that receives the
measurement package every 20 ms, checks for errors in the measurement,
converts the information to a IEEE standardized format [2] and stores the
measurements as binary files, once every hour. These operations are hard
to perform using the MS-DOSR
system which explains the selection of the
WindowsR
operating system for this part.
The main program structure of the DTU PMU can be seen on the flowcharts
in appendix A. As seen from those flowcharts a common LabVIEWR
pro-
gram is made of one or more Virtual Instruments (VI). These VIs are pro-
grams or files made by LabVIEWR
. A main program created in LabVIEWR
is a VI and has the file extension .vi. It can have many sub VIs that have
similar purpose as classes in a typical C or Java program. The DTU PMU
has a main VI called PMU COMMON.vi (Fig. A.1), the brain of the PMU,
which controls all communication between the two computers as well as run-
ning important VIs like PMU Serial.vi and PMU IEEE.vi also described in
appendix A, Figs. A.2 and A.3. The term VI will be used very frequently
throughout this report.
2.1.2 Satellite system
Designers today can choose from three satellite systems for disseminating the
time but only the Global Positioning System (GPS) meets all requirements
for this application. The GPS is a satellite based navigation system devel-
oped by the United States Department of Defence (DoD) in 1994. It consists
of 24 satellites that circle the earth twice a day in six orbital planes. [2]
The GPS is steered by a ground-based Cesium clock ensemble, which itself
is referenced to UTC. The signal from the GPS satellites can be received

2.1 Description of the PMU 7
by a simple omnidirectional antenna. When the DTU PMU is started up it
needs at least four satellites two determine its position. After that it only
needs one satellite to determine the time as it’s receiver is in a fixed position.
2.1.3 The Phasors
Both the voltage and the current measurements from the PMU unit are
transferred as phasors. When working with a AC power system the voltages
and the currents are a sinusoids on the form x(t) = Xm cos(2πft + φ) and
can therefore be represented as a phasor (X) which is generally written on
the form
X = (Xm/
√
2)ejφ
(2.1)
where Xm is the magnitude and φ is the phase angle. The main benefit of
using phasor representation is the fact that the phasors are independent of
the system frequency. In practice the system frequency is never completely
stable and fluctuates constantly around its nominal value which is 50Hz in
this case.
The DTU PMU measures at the observation interval T0 = 20ms which is
equal to 1/f where f is the system frequency, 50Hz. This should result
in a constant phase angle, φ, if it were not for the fluctuating frequency.
This is not a problem however because what is observed is the difference
between two phase angles which cancels out any fluctuation. The phase
angle difference of interest is either between the voltage phase angles of two
different stations or the voltage phase angle and the current phase angle at
one station
2.1.4 Data Transmission
The PMU transmits three types of information organized as frames. These
frames are called Data Frame, Header Frame and Configuration Frame. The
PMU is then supposed to be able to receive a frame called the command
frame. The only frame transmitted by the DTU PMU stations is the Data
Frame since it is the only frame containing measured data. The size of
the Data Frames can vary for it is dependent on the types and amount of
measurements (phasors generated) at the PMU location.
Normally the system nominal frequency along with information about sta-

tion and field names, scaling, conversion factors and data format, would be
stored in a configuration frame but since the DTU PMU is not equipped
with that frame this information is stored in the LabVIEWR
files of the
WindowsR
computer.
2.2 Standards for Synchrophasors for Power Systems
The DTU PMU stations were all based on the first Standard for Synchropha-
sors for Power Systems [2], published by the Institute of Electrical and
Electronics Engineers (IEEE) in the year 1995. This standard was then
completely revised and a new standard [9] was published in the year 2005 to
replace the original. The DTU PMU software is based on the 1995 standard
whereas this project will use the latest edition. Therefore both editions of
the standard will be discussed and compared in the following sections.
2.2.1 The 1995 Standard
Fig. 2.1 illustrates the arrangement of the binary data in each real-time
phasor data frame of the 1995 standard.
Figure 2.1: Data frame for phasor data in the 1995 synchrophasor standard
The Data Frame is identified by having the three most significant bits of
SMPCNT equal to zero. The second of century (SOC) cell in Fig. 2.1 is a 4
byte representation of the UTC time in seconds calculated from midnight of
January 1, 1900, which attains new value every second. Each PMU station
under consideration in this project computes 50 measurements each second,
i.e. a new measurement is made every 20ms. This means that every 50
measurements have the same SOC value.

2.2 Standards for Synchrophasors for Power Systems 9
The phasor cells, each 4 bytes, in this case consist of 2 bytes for the mag-
nitude and 2 bytes for the angle respectively, where the magnitude is repre-
sented with a 16 bit binary number in the range 0 to 215 − 1 and the angle
is in radians ×10−4 in the range −π to +π.
The last cell of interest in this project is the FREQ cell. The FREQ cell
contains the frequency which is represented by a 16 bit binary number in
Hz ×10−3 deviation from system nominal.
2.2.2 The 2005 Standard
Several changes were made from the former standard in this new revised
standard. Specifically, the sync, frame size and station identification fields
have been added to the data frame as well as the analog data field. The
fraction of second field has replaced the sample count field and the status
field has been modified to include time quality.
Tables 2.1 and 2.2 list the data frame organization of the new IEEE standard.
Table 2.1: Word definitions of fields common to all frame types
Field Bytes Description
SYNC 2 Frame synchronization word.
Leading byte: AA hex
Second byte: Frame type and version number.
FRAMESIZE 2 Total number of bytes in the frame, including CHK.
IDCODE 2 PMU ID number, 16 bit integer.
Identifies device sending and receiving messages.
SOC 4 Time stamp, SOC count starting at midnight 01-
Jan-1970.
FRACSEC 4 Fraction of Second and Time Quality, time of mea-
surement for data frames.
CHK 2 CRC-CCITT
In the first round of implementing the new standard, all fields will be avail-
able but not active. Meaning that fields like SYNC, IDCODE, STAT, ANA-
LOG and DIGITAL will be assigned a constant default value. This is be-
cause fulfilling the purpose of these fields would mean a considerable change
on the existing programs which is both expensive and time consuming.
Following changes have also been made on fields that were defined in the

Table 2.2: Data frame organization of the 2005 standard
Field Bytes Description
STAT 2 Bitmapped flags.
PHASORS 4 Phasor estimates, 3-phase positive sequence.
Polar format:
- Magnitude and angle, magnitude first
- Magnitude 16-bit unsigned integer range 0 to
65,535
- Angle 16-bit signed integer, in radians ×104
,
range -31,416 to +31,416
The number of phasors is limited to 5 in the DTU
PMU.
FREQ 2 Frequency deviation from nominal, in millihertz
(mHz) Range-nominal (50Hz) -32.767 to +32.767
Hz. 16-bit signed integers, range -31,767 to
+31,767
DFREQ 2 Rate of change of frequency in Hz per second times
100.
ANALOG 2 Analog word. 16-bit integer. It could be sampled
data such as control signal or transducer value.
The number of the analog values is defined in the
configuration frame.
DIGITAL 2 Digital status word. It could be bitmapped status
or flag.
The number of the digital status words is defined in
the configuration frame.
1995 standard:
• The STAT field no longer contains the number of bytes in each frame
but serves only as a complete status for the data in its data frame
within the bounds of the standard.
• The SOC field now contains the number of seconds since the 1st of
January 1970 instead of 1st of January 1900.
• The FRACSEC field replaces the SMPCNT field from the previous
standard.
The FRACSEC field is divided into two components, a 24-bit integer that is

2.3 The Cyclic Redundancy Check 11
the actual fraction-of-second count and an 8-bit time quality flag. The qual-
ity flag bits, not yet implemented in the DTU PMU, indicate the ”quality”
of the time as well as the Leap Second status.
The time of measurement is the SOC time stamp plus the fractional time.
Equation (2.2) shows how time of measurement is calculated.
Time = SOC + FRACSEC(23 : 0)/TIME BASE (2.2)
Normally the TIME BASE integer is given in the configuration frame, but
since the DTU PMU unit is not equipped with that frame the TIME BASE
is defined in the LabVIEWR
program of the DTU PMU unit as a constant
1, 000, 000 µs.
The time quality flag is used to indicate the quality of the time being re-
ported as well as the Leap Second status. For now this time quality flag is
not yet implemented in the DTU PMU unit.
2.3 The Cyclic Redundancy Check
The Cyclic Redundancy Check (CRC) method has been used for many years
in communications networks. The purpose of the CRC is to detect errors
and to validate messages. Many CRC methods are used in today’s communi-
cation systems and among the most common ones is the 16 bit CRC-CCITT
which will be the main topic of this section.
2.3.1 CRC in general
A CRC is the remainder of a binary division with no bit carry of the message
bit stream, by a predefined bit stream of length n, which represents the
coefficients of a polynomial. Common amongst all variations on CRCs is
that they use a generating polynomial in order to achieve their goal. In
general the CRC can be represented by (2.3).
M(x) · xn
= Q(x) · K(x) + R(x) (2.3)
In (2.3) M(x)·xn represents the original message bits with n zeros appended
to them, K(x) the generating polynomial and R(x) the remainder or the
CRC bits. Q(x) is the quotient.

In communication, the sender attaches the n bits of R(x) after the original
message bits of M(x) and sends them out (in place of the zeros). The receiver
takes M(x) and R(x) and checks whether M(x) · xn − R(x) is divisible by
K(x). If it is, then the receiver assumes the received message bits are correct.
Note that M(x) · xn − R(x) is exactly the string of bits, sent by the sender.
This string is called the codeword.
Another method of checking the CRC is to run a CRC calculation on the
entire codeword. If the result is zero, the check passes because M(x) · xn −
R(x) = Q(x) · K(x).
2.3.2 The CRC of the DTU PMU
When the CRC of the DTU PMU was originally implemented few years ago
it was based on some documentation about CRC from various sources. The
only thing that the 1995 standard [2] demands is that the CRC cell shall be
a 16 bit word using the generating polynomial X16 + X12 + X5 + 1 which
can be represented with the hexadecimal word 0x1021.
The 2005 standard [9] describes the CRC, commonly referred to as CRC-
CCITT, in more detail.
• It shall use the generating polynomial G(x) = X16 + X12 + X5 + 1.
• The initial value of the CRC shall be 0xFFFF.
• No ﬁnal mask should be XORed with the ﬁnal value of the CRC.
Table 2.3 shows example message data and the resulting CRC value from
[9] and [8].
Table 2.3: Known CRC values according to numerous sources
ASCII message Resultant CRC value
A 0xB915
abc 0x514A
ABCD 0xBFFA
123456789 0x29B1

2.3 The Cyclic Redundancy Check 13
Since the DTU PMU calculates the CRC from a cluster input it is difficult
to check whether it gets the same CRC values from the messages in table
2.3.
To check whether the DTU PMU calculated the CRC value correctly a sam-
ple ”C” code calculation example from [9] was translated into a LabVIEWR
program and the CRC value was calculated for an old data frame. Also a
completely different CRC ”C” code from [8] was translated into a LabVIEWR
program for comparison.
This comparison resulted in both ”C” code programs, that agreed with table
2.3, calculated the same CRC code for the data frame but the DTU PMU
CRC program, IEEE CRC.vi, gave a different result.
A thorough examination of IEEE CRC.vi shows that the reason for this
difference is that IEEE CRC.vi does not contain a CRC variable with the
initial value of 0xFFFF. Also the generator polynomial should be XORed
with the shifted CRC variable but not the message bits.
2.3.3 CRC Discussion
Although it seems that the DTU PMU does not calculate generally approved
CRC values it calculates a CRC value which could well be capable of de-
tecting errors. The 16 bit CRC-CCITT is however designed to detect over
99.9985% of all bursts errors that are greater than 17 bits long and 100% of
all bursts less than 17 bits.
Because of numerous CRC algorithms and methods available it is hard to
find a method which is generally accepted and defined. For example a report
on the internet by Joe Geluso [8] states, very convincingly that the values
in table 2.3 are incorrect. His main argument is that CRC algorithms, that
produce values as in table 2.3,
...do not augment a zero-length message with 16 zero bits, as
is required (either implicitly or explicitly) when calculating the
standard CRC.
However convincing this sounds it is hard not to follow the IEEE accepted
values and method so the decision was to go with the IEEE for now.

2.4 Summary
This chapter brieﬂy explains the Phasor Measurement Unit (PMU) devel-
oped at DTU. Both PMUs structure and functionality are described as the
main focus is on the new and revised IEEE standard for Synchrophasors
for Power Systems published recently. Also the CRC gets some attention
because of its important role in data transmission.

Chapter 3
Design and Construction
One of the main reasons why LabVIEWR
was chosen for this project was
the fact that the WindowsR
part of the PMU station was programmed in
LabVIEWR
. As the main objective in this project is to develop a client-
server program in order to monitor on-line data from PMU stations then the
benefits of choosing LabVIEWR
software is that it offers various methods
of programming a client–server program.
Two different methods of client–server programming in LabVIEWR
will be
examined in this chapter and how they were implemented in the simula-
tion which is also described in the forthcoming sections. The LabVIEWR
database toolset will also get its share of this chapter.
3.1 Client-Server Programming Methods
As mentioned above the LabVIEWR
offers at least two methods of client–
server programming. One of these methods is a direct Transmission Control
Protocol/Internet Protocol (TCP/IP) programming whereas the other uses
common global variables.

16 Design and Construction
3.1.1 The TCP/IP Method
Figs. 3.1 and 3.2 illustrate a very simple example of a client-server program
that uses built in TCP/IP VIs from the LabVIEWR
VI library.
Figure 3.1: Simple TCP/IP server in LabVIEW R
A basic server as illustrated in Fig. 3.1, programmed using the TCP/IP VIs
from LabVIEWR
, begins with the listen to connection VI where the time
out limit, port number and IP–address (optional) of the connection to the
client are specified. Once the connection has been established the numeric
data is cast into a string data and sent via two TCP write VIs. The first
TCP Write sets the amount of data to send and the second TCP Write sends
the data. Then when the data has been sent successfully the connection is
closed.
Figure 3.2: Simple TCP/IP client in LabVIEW R
The simple client illustrated in Fig. 3.2 begins with the TCP open con-
nection VI which opens the connection to the server using appropriate port
number and an IP–address. Once the connection is open the data can be
read from the port specified and cast into a numeric representation. The
first TCP Read in Fig. 3.2 acquires the size of the data and the second TCP

3.1 Client-Server Programming Methods 17
Read reads the data and passes it to the DATA variable. When this is done
the connection is closed.
3.1.2 The Global Variable Method
Before using the Global Variable method, the built in LabVIEWR
VI Server
must be configured. When configuring the VI Server the TCP/IP protocol
must be activated and the remote computer’s VIs must be given access to
the local computer in the machine access list.
Figure 3.3: Simple server in LabVIEW R
that uses a Global Variable VI
Fig. 3.3 is a block diagram of a simple server program that uses a Global
Variable VI. The Open Application Reference VI and the Open VI Reference
VI locate the Global Variable VI (Globals.vi) where the transferred data is
written. The data can be transferred as flattened string as in Fig. 3.3 or as
a variant. This is specified at the Invoke Node VI where the control name
of the variable in the Globals.vi is also given.
Figure 3.4: Simple client in LabVIEW R
that uses a Global Variable VI
The block diagram of the simple client program in Fig. 3.4 is very similar

to the server program in Fig. 3.3 where the difference lies in the function of
the Invoke Node VI. The Invoke Node VI is used to get the current value of
String from Globals.vi as flattened data. The unflatten from string object
converts the data into a string data type. To save the user the work of
constantly pushing the run button to check for new data it is possible to
insert a while-loop between the Open VI Reference VI and Close Reference
VI.
Of course this method also uses the TCP/IP communication protocol but
the VI Server handles all the TCP/IP programming so that the programmer
does not have to think about it. As in the TCP/IP method the user has to
specify the IP–address of the remote machine, only at the server or the client
but not both. The reason for this is that the Global Variable VI must be
placed at either the server or the client which means that either the server
or the client invoke the Global Variable VI locally.
3.1.3 TCP/IP Compared to Global Variable
When comparing these two methods in Figs. 3.1 to 3.4 then it is clear that
the number of VIs used in each method is almost the same, which means
that the programming is similarly complicated for both methods. Following
are the pros and cons of each method.
• The TCP/IP programs do not need an extra VI like the Global Vari-
able VI.
• The size of the data does not have to be specified in the Global Variable
method.
• Only one IP–address, the address of the Global Variable VI, needs to
be specified in the Global Variable method.
• No port number needs to be specified in the Global Variable method
unless the user wants a different port number than the default one
given by the VI Server.
• There is a delay in the TCP/IP method of great concern.
• There is no buffer between the server and the client in the Global
Variable method, which means that the data is constantly overwritten.
This can result in data loss if the client has not retrieved the data
before the server has overwritten them.

3.1 Client-Server Programming Methods 19
The choice was to go with the Global Variable method despite the risk of
loosing data, especially because of the delay in the TCP/IP method. The
reason for this delay is, according to information found on www.ni.com, that
there is an inherent 200 ms delay in sending TCP/IP messages on WindowsR
machines.
One of the biggest advantage of the Global Variable method is that the
Global Variable VI can be placed at either the client or the server. For as
it turned out the second PMU at DTU could not access the client so the
client had to get the data from the PMU. The ﬁrst PMU at DTU however
had to write the data to the client as the client could not access the PMU.
This is illustrated in Fig. 3.5.
PMU 1 PMU 2
Server VI Server VI
global
variable
VI
global
variable
VI
global
variable
VI
CLIENT
PC
Client VI
Figure 3.5: Conﬁguration of global variable access between PMU 1, PMU 2 and
a client PC
Ideally all of the data should be written to the Global Variable VI at the
client PC or the data should be read from the Global Variable VIs at the
PMUs. This is however not always possible as in the case in Fig. 3.5. In
that case, having other alternatives is invaluable.
An access problem as in Fig. 3.5 must lie in the set up of the WindowsR
2000 operating system of the PMUs as this problem does not occur between
normal PCs using the WindowsR
XP system and LabVIEWR
8.

3.2 Simulation
One of the advantages of using LabVIEWR
is that it offers the option of
running a client-server simulation on a single PC. Of course some of the
simulation had to be performed using two computers to test the behavior of
the program when using a remote connection. However the majority of the
simulation and development process was performed on only one PC.
One of the biggest problems when trying to simulate a PMU was to generate
the measurements data flow. The solution was to use old data that had been
stored in binary format. From these binary files it was possible to extract
the data frames, described in [2], one at a time.
3.2.1 The Server Simulation Program
The block diagram in Fig. 3.6 describes the flow of one of the simulation
server program developed for this project. In the simulation there are always
two server programs running to simulate two PMUs. This server program
consists of four VIs that serve the only purpose of writing a string, in the
form of a data frame, to the Global Variable VI.
The data frame was designed by IEEE so that measurement data could be
transferred between networks without loosing reliability. That is why it was
chosen to let the server program send the entire data frame to the Global
Variable VI so that the client program could run a CRC on the data to
verify its authenticity. However in the simulation process the CRC was not
executed on the data because the old data used had already been checked
using the CRC algorithm mentioned in chapter 2.3.2.
3.2.2 The Client Simulation Program
Fig. 3.7 illustrates the flow of the simulation client program developed for
this project. This client program includes several VIs where few of them
are database related VIs described later in this chapter. The main purpose
of the client is to read the data from the Global Variable VI, verify it and
possibly store it in a database and/or monitor the data live.
The server programs are not executed at the same time so there is always

3.2 Simulation 21
run String to Buffer.vi
get string from
Binary to String.vi
convert bin file with 1
hour measurement data
to a string
divide string into
data frames and
call Buffer to
Queue.vi
insert data frames
to a queue A
dequeue data
frames from queue
A and write to
Global Variable.vi
while number of data
frames < 180.000
while stop = false
to sub LOOP
to main LOOP
waitwait
SERVER.vi
Figure 3.6: Block diagram of one of the server simulation programs
time diﬀerence between the data in string1 and string2 of the Global Variable
VI. To rectify this the client sets an initial time stamp from the string with
the higher time stamp. The string with the higher time stamp is then
enqueued whereas the other is not enqueued until it has reached the initial
time stamp value. As a result of this either SQ1 or SQ2 will always contain
more elements than the other corresponding to a few seconds of data.
The Compare and Monitor VI is a very important VI as it synchronizes the
data to be viewed. This VI also allows the user to choose what type of data
he/she wants to monitor. The synchronization process ensures that the data
monitored from two diﬀerent sources has the same time stamp.

get data frames from
Global Variable.vi
call Buffer to Queue.vi
string1 to queue SQ1
string2 to queue SQ2
dequeue data frames, extract
data from data frames into
cluster and enqueue to
cluster queues CQ1 and CQ2
optional: run Compare
and Monitor.vi
review cluster queues and
synchronize data if necessary
dequeue clusters
and monitor data
while stop = false
while stop = false
CLIENT.vi
find Global Variable.vi
check if any data is in
string1 AND string2 of
Global Variable.vi
data OK
no data
SQ1
CQ1 CQ2
SQ2
CQ1 CQ2
to chart
CQ1 and
CQ2 in sync
wait
wait
Compare and Monitor.vi
Figure 3.7: Block diagram of the client simulation program

3.2 Simulation 23
3.2.3 Simulation Results
3.2.3.1 Problem in Simulation
In the simulation process the string queues, SQ1 and SQ2 (see Fig. 3.7),
behaved mysteriously. By this meaning that they were fully synchronized
in the beginning but as the program progressed the difference of the time
stamps of their oldest elements went from 0 to 8 or even 9 seconds. As there
are 50 measurements in one second this difference was considerable and of
great concern. This also meant that when the data was being monitored the
synchronization process was constantly kicking in as the monitor queues,
CQ1 and CQ2 (see Fig. 3.7), followed the string queues.
In order to find out the reason for this desynchronization, the main loops of
both the SERVER.vi and the CLIENT.vi were timed using the Tick Count
(ms) VI. The results of the timing process were that execution time of both
loops varied between 40 to 50 ms on average and rarely went below 20 ms
as they were supposed to. A more thorough timing investigation revealed
that calling the Invoke Node VI (mentioned in chapter 3.1.2) was this time
consuming. The LabVIEWR
8.2 Help on www.ni.com [3] partly explains
this. It says, under ”Call By Reference Node Details”:
At run time, there is a small amount of overhead in calling the
VI that is not necessary in a normal subVI call. This overhead
comes from validating the VI reference and a few other book-
keeping details.
Also because this project is about developing a client-server program that
is supposed to communicate across a network the same article says:
Calling a VI located in another LabVIEW application (across
the network) involves considerably more overhead.
Which should result in even greater run time across the network compared
to the simulation run time as the simulation was run locally.
Because of this delay the queues, at the servers, fill up and their oldest
elements are removed to give space for new ones. In other words a loss of
data is considerable and only about half of the data is transferred through
to the client.

3.2.3.2 Possible Solution of Simulation Problem
The main cause of the delay problem is the fact that the server and the
client call the Invoke Node VI to write and read the data, respectively, in
the Global Variable VI. As this cannot be done every 20 ms the solution
might be to send more than one measurement at a time. That is to transfer
at least ﬁve IEEE formatted data strings as an array in every iteration.
Fig. 3.8 shows the new simulation block diagram of the server program.
What changes is that the times of the main loop and the sub loop (TOL)
are now diﬀerent. The TOL of the main loop is now equal to nx20 ms, where
n is the number of data frames in the array to be transferred, but the TOL
of the sub loop remains 20 ms to simulate the behavior of the PMU.
run String to Buffer.vi
get string from
Binary to String.vi
convert bin file with 1
hour measurement data
to a string
divide string into data
frames and insert data
frames into array with
shift registers
insert array of data
frames into a queue A
and clear array
dequeue array of
data frames from
queue A and write to
Global Variable.vi
for i = (1:180.000)
while stop = false
to sub LOOP
to main LOOP
waitwait
SERVER.vi
if i % n = 0
TRUEFALSE
TOL = 20 ms
TOL = nx20 ms
Figure 3.8: Block diagram of the server simulation program that transfers arrays
of data frames
Also the Binary to String VI changes in such a way that elements are only

3.3 Synchronization 25
inserted into queue ”A” when the number of data frames in the array are
equal to n.
The structure of the client remains mostly unchanged. It’s main loop TOL
increases to nx20 ms as the TOL of the server’s main loop. And instead
of retrieving strings from the Global Variable VI, it now retrieves arrays of
strings with n elements. An extra for-loop was added in the main loop in
order to insert the data frames, from the array, to the cluster queues, CQ1
and CQ2, one by one.
The cluster queues, CQ1 and CQ2, remain unchanged so that the Compare
and Monitor VI needs no modification.
3.2.3.3 Simulation of the Modified Simulation Programs
The modifications done on the simulation programs proved to be very suc-
cessful in the simulation process. The choice was to transfer an array of five
data frames (n = 5) which should result in a safe TOL.
The TOL of the client and both of the servers was varied from 99 to 101 ms
which resulted in no data loss. Also the monitor program ran very smoothly,
and the synchronization process was rarely called. The duration time of the
simulation process was less than two minutes.
3.3 Synchronization
One if not the most important part of comparing two or more signals is that
they have to be synchronized to give any meaningful result. This is why a
great part of this project has gone into acquiring full synchronization of the
live signals.
In order to achieve full synchronization a number of options available in
LabVIEWR
were tested in the simulation process. Following is the sum-
mation of these options where the first three are all possible solutions of a
buffer system between the main client program and the monitor programs.

3.3.1 Global Queues
The use of global queues was the first option tried in the simulation process.
First the data frame is read from the Global Variable VI and then buffered
into a global queue of a string type. Then the data frame is dequeued and
data is extracted from the data frame, put into a cluster and enqueued
to another global queue of a cluster type. When the user then wishes to
monitor the data this cluster queue is accessed from the second VI so that
the data is enqueued at one end of the queue and dequeued at the other end
at the same time as illustrated in Fig. 3.9.
Global Queue
Client
data
Monitor
data
Figure 3.9: Block diagram of two VIs accessing the same global queue
In the simulation process this did not seem to cause any conflicts and the
data was enqueued and dequeued at the same time without any problems.
3.3.2 Double Buffer System
Although using a single shared global queue did not seem to cause any
conflicts, the implementation of a double queue was also simulated. This
method is common amongst programmers where the idea is to avoid any
conflicts between programs. As illustrated in Fig. 3.10 the client program
writes data into one queue while the monitor program reads the data from
the other queue.
Global Queues
Client
data
Monitor
data
Figure 3.10: Block diagram of two VIs accessing a double global queue
At first this method does not seem to be much more complicated than
using only one buffer comparing Figs. 3.9 and 3.10. However from the
programmers point of view this method is very difficult to implement. The
reason for this complexity is that it is necessary to control when each VI

accesses the queues, when the queues should be flushed, and what is to
happen when the data is not being monitored and thus not dequeued.
In simulation this method gave a lot of problems and did not function very
well with the synchronization check so it was decided to go with the single
buffer system as it was simple and did not give any serious problems.
3.3.3 Shared Variables
The design of the client demanded that the data, extracted from the data
frames in the purpose of being monitored, had to be accessed from two dif-
ferent VIs at the same time. This was a concern because of the possibility of
a access violation. Normally in situations like this a designer would consider
the use of notifiers that allow only one VI to access another VI at a time.
But in this case the two VIs had to access the data at the same time which
ruled out the use of notifiers.
LabVIEWR
offers the possibility of using shared variables in cases like this.
The shared variables have built in buffer system so that the designer does
not have to buffer the data specially. However the designer has no control
over these variables like reviewing the data without removing it from the
buffer or getting the status of the buffer. Also on the downside is the fact
that it is not possible to create a shared variable in the form of a cluster
which means either that numerous variables need to be created resulting in
very heavy programming or all data must be converted to the same type in
order to use arrays.
These restrictions of the shared variables as well as the negative results
when implemented in the simulation programs quickly ruled out the use of
the shared variables for this project.
3.3.4 Timed Structures
One of the new features in LabVIEWR
8 is the timed structures. The timed
structures and their associated VIs are used to control the rate and priority
at which a timed structure executes its sub diagram, synchronize the start
time of timed structures, create timing sources, and establish a hierarchy of
timing sources.

By using the timed loop of the timed structures it is possible to synchronize
two or more signals. Making long story short, these timed structure VIs
where not applicable in this project as it seems that they are designed to
synchronize periodic signals which is not the case here. Therefore a further
inspection of the timed structures was abandoned.
3.3.5 Initial Synchronization
When the client has established a connection to the Global Variable VI,
an initial synchronization is performed. The initial synchronization process
begins by determining the initial time stamp value. The initial time stamp
is the SOC value of the data with the higher time stamp incremented by
one second.
Then when the SOC value of the data retrieved from the Global Variable
VI reaches the initial time stamp, the data is enqueued. By doing this the
oldest elements of both array queues will have the same time stamp and are
therefore synchronized.
3.3.6 The Synchronization Check
Since the time interval between the measured data is only 20 ms the smallest
computer operation can cause the data to go out of synchronization during
live monitoring. This is why the program has to be constantly verifying that
the data is synchronized.
Every 20 ms the monitor program checks whether the measurements have
the same time stamp. Each time stamp has a SOC number and a FRAC
number deﬁned in [9]. Table 3.1 describes what the synchronization al-
gorithm does when the data has the same SOC number but not the same
FRAC number. Then the algorithm dequeues either queue 1 (data from
PMU 1) or queue 2 (data from PMU 2) depending on which one has the
higher FRAC number.
Tables 3.2 and 3.3 describe what happens if the SOC numbers diﬀer from
one another. First queue 1 or 2 are dequeued to get the same SOC number.
Then, as in table 3.1, the algorithm dequeues either queue 1 or queue 2 to
get the same FRAC number.

Table 3.1: The synchronization algorithm in pseudo code, part I
if SOC1 != SOC2 or FRAC1 != FRAC2
if SOC1 = SOC2
SOC sec = SOC2
if FRAC1 > FRAC2
while FRAC2 != FRAC1
dequeue queue 2
else
while FRAC1 != FRAC2
dequeue queue 1
Table 3.2: The synchronization algorithm in pseudo code, part II
elseif SOC1 > SOC2
SOC sec = SOC1
SOC frac = FRAC1
while SOC2 != SOC sec
dequeue queue 2
tmpFRAC = FRAC2
if SOC frac = tmpFRAC
continue to monitor
else
if tmpFRAC > SOC frac
while FRAC2 != SOC frac
dequeue queue 2
else
dequeue queue 1
When the algorithm has ensured that the next elements to be removed from
queues 1 and 2 have the same time stamp then the data is printed on the
screen and the synchronization check is repeated.

Table 3.3: The synchronization algorithm in pseudo code, part III
elseif SOC1 < SOC2
SOC sec = SOC2
SOC frac = FRAC2
while SOC1 != SOC sec
dequeue queue 1
tmpFRAC = FRAC1
if SOC frac = tmpFRAC
continue to monitor
else
if tmpFRAC > SOC frac
dequeue queue 2
else
dequeue queue 1
3.4 Loop Timing
The time interval between measurements is only 20 ms, thus it is very im-
portant that every iteration of the loop where the data is extracted and
monitored can be executed within those 20 ms. Should the iteration take
more time than 20 ms it would result in a notable delay. As the simulation
process revealed the 20 ms time interval was to strict so that the TOL of
the main loops was set to nx20 ms as each iteration transferred n number
of measurements using arrays.
Also it is important that every iteration of the client’s and both of the
server’s loops should take exactly nx20 ms of execution time to prevent
any possible data loss. To ensure correct execution time LabVIEWR
oﬀers
several timing VIs to control the loop timing. One of them is the Wait Until
Next ms Multiple VI.
When Wait Until Next ms Multiple is called, it will return, or
ﬁnish, when the millisecond timer value of the operating system
is a multiple of the millisecond multiple input. For instance, if

3.5 Database 31
the VI is called with a millisecond multiple input of 10 ms, and
the millisecond timer value is 112 ms, then the VI will only wait
8 more millisecond, at which time the millisecond timer value
will be 120 ms, which is a multiple of 10 ms. Using this VI to
time a loop means that the loop will be synchronized with the
operating system millisecond timer value multiples [5].
synchronize
data
dequeue
Q1
dequeue
Q2
print to
screen
WAIT
20 ms
dequeue
Q1
dequeue
Q2
print to
screen
WAIT
20 ms
i i+1
Figure 3.11: Illustration of a loop timing using Wait Until Next ms Multiple VI
Fig. 3.11 shows an example of two loop iterations in the monitor program.
The example shows that the two iterations do not include the same oper-
ations but because of the wait function, both iteration have the same time
duration of exactly 20 ms.
Placement of the Wait Until Next ms Multiple VI in the program loop is also
important as it is not desired that the waiting occurs between the dequeuing
and printing the data to the screen. To ensure that it does not happen a
structural sequence diagram can be used to force the waiting to occur before
dequeuing the queues which would be immediately followed by the printing
to screen operation as in Fig. 3.11.
3.5 Database
Right in the beginning phases of this project it was decided to look into
the possibilities of storing the measurement data at the client computer.
The idea was that the user could examine old data as perhaps it would be
diﬃcult to be constantly monitoring the data. Only data reaching couple of
weeks back should be stored as older data was still to be stored in binary
format.
Again LabVIEWR
oﬀers possible solutions to this problem with the Lab-
VIEW Database Connectivity Toolset. The LabVIEW Database Connec-

tivity Toolset is an add-on package for accessing databases and has to be
installed separately.
3.5.1 Database Setup
Before it is possible to access or write data in a table, a connection to the
database must be established. The Database Connectivity Toolset supports
different standards that use different methods of connecting to databases.
These standards and methods will not be described in this project, only the
method used will get a brief description.
To be able to use the high-level VIs from the toolset to create tables, delete
tables, insert data into tables, or select data from tables in a database,
a data source has to be created. The data source can be created using
the MicrosoftR
ODBC Data Source Administrator where drivers can be
registered and configured to be available as data sources for the application
to be used (MicrosoftR
Access in this case). The ODBC driver selected here
was the MicrosoftR
Access Driver.
Next a universal data link (UDL) has to be created. The UDL contains
information about what OLE DB provider is used (MicrosoftR
OLE DB is
the default provider for the ODBC drivers), server information, user ID and
password, default database, and other related information.
Finally a database file has to be available. There is no need to have MS
Access or any other database installed to use the Database Connectivity
Toolset VIs. The LabVIEW.mdb file, which comes with the toolset, can be
renamed and modified using the high-level VIs once the database connection
has been established.
Many of the terms mentioned here are described in further detail in [10].
3.5.2 Database Limitations
Following are the limitations of the MS Access files (mdb files).
• Maximum number of columns is 255.
• There is now row limitations but table size cannot exceed 1 Gb.

3.5 Database 33
• Maximum number of objects (tables, queries, etc.) in a database is
32.768.
• Maximum mdb file size is 2 Gb. However, because your database can
include linked tables in other files, its total size is limited only by
available storage capacity.
The 2 Gb limit should be plenty because if the amount data to be stored
exceeds this limit one should consider using some other database like for
example Structural Query Language (SQL).
If only one mdb file is used to store the data a rough calculation estimates
that one hour of data takes about 10 Mb of storage space which results in
the mdb file being capable of storing less than 10 days of data.
3.5.3 The Data Storage
Initially the idea was to store the entire IEEE data frame string in the
database. That would have been very convenient because the table would
only need one column that would include all the information for each mea-
surement. However the VI developed for the simulation process to write
data to the database slowed down the entire program while writing the data
to the database. The VI was run in a separate loop in parallel to the main
loop for one hour which resulted in only one third of the data written to
the database. This meant that writing data to database using the high-level
VIs from the database toolkit takes about 60 ms.
Because of this a decision was made to store the data every second, which
means an average value from 50 measurements. This also means that the
IEEE string cannot be stored as it is not possible to find an average value
of a string. The data to be stored has to be chosen from the string, table
3.4 shows an example of the data chosen from the DTU PMUs.
For convenience all the data chosen to be stored in the database was con-
verted to the same format, the single precision [32 bit real (∼ 6 digit preci-
sion)].
Another problem arose as the phasors are complex numbers and there is
no simple method available for computing the average value of a complex

Table 3.4: The data that was chosen to be extracted from the IEEE string at
the DTU PMUs
SOC SOC time stamp defined in table 2.1 converted
from unsigned 32b to date/time format
Voltage Magnitude Extracted from PHASOR ♯1 in single precision
format
Voltage Angle Extracted from PHASOR ♯1 in single precision
format
Current Magnitude Extracted from PHASOR ♯2 in single precision
format
Current Angle Extracted from PHASOR ♯2 in single precision
format
Frequency Scaled from FREQ defined in table 2.2 in single
precision format
number. The decision was to take the root-mean-square (rms) value of the
magnitudes, defined by (3.1).
Xrms =
1
√
2
X2
0 + X2
1 + ...X2
49 (3.1)
Calculating the average value of the angle is more complicated. This is
because the angle constantly travels from −180◦ to 180◦ and if the angle
changes from −180◦ to 180◦ within one second then the average value for
that second would result in a value near 0◦ instead of a value near 180◦.
By changing the negative angle values to positive by adding 360◦ to them
would result in a similar problem when the angle changes from 360◦ to 0◦.
The solution used here was to make the angle continue to grow instead of
falling to 0◦ as illustrated in Fig. 3.12.
Table 3.5 lists the algorithm used to calculate the mean value of the an-
gles. According to this algorithm the angle is only greater than 360◦ during
the second where the angle changes from 360◦ to 0◦. When that second
passes, the angle goes back to normal. The angle is also normalized with
the Quotient and Remainder VI resulting in a mean value between 0◦ and
360◦.

3.5 Database 35
Time [s]
Degrees
0 1
340
380 mean value
= 360
Figure 3.12: Deﬁnition of the mean value for angles used in this project
Table 3.5: The algorithm for calculating the mean value of an angle
if ANGLE(i) < 0
ANGLE(i) = ANGLE(i) + 360
else
ANGLE(i) = ANGLE(i)
if ANGLE(i-1) - ANGLE(i) > 300
ANGLE(i) = ANGLE(i) + 360
else
ANGLE(i) = ANGLE(i)
if i < 50 (the second not completed)
max(ANGLE(i),ANGLE(i-1)) = MAX
min(ANGLE(i),ANGLE(i-1)) = ANGLE(i+1)
else (the second completed)
MAX + min(ANGLE(i),ANGLE(i-1)) / 2 = tmp
tmp - 360· ﬂoor(tmp/360) = MEAN ANGLE
Finally the average values of the SOC time stamp and the frequency are
computed using general averaging methods.
3.5.4 Improved Database VIs
As mentioned in the previous section the database VI developed for the
simulation process did not handle the 20 ms time interval and because of
this delay a compromise was made which was to store average values of

one second of data. Further inspections of why this delay occurs revealed
however that the method used in simulation was not optimal. Fig. 3.13
illustrates the method used that caused the delay in the program.
Figure 3.13: Block diagram of a VI that writes a string to a table of a database
The VIs in Fig. 3.13 were called in every iteration of the main loop which
meant that the connection to the database was opened and closed every time
a new data was written to the tables of the database. This is unnecessary
and can easily be avoided.
In the Global Variable method, described in chapter 3.1.2, a connection to
the Global Variable VI is established and then data can be written and read
while conditions allow until the connection is closed. A similar method can
be used when writing data to the database. This method is illustrated in
Fig. 3.14.
Figure 3.14: Improved block diagram of a VI that writes numerous strings to a
table of a database
Instead of calling the write to database VI in every iteration of the main
loop it can be run separately using its own while-loop where the data is
written to the database. Then the VIs opening and closing the connection
to the database are only called once during the entire runtime of the program

3.6 Summary 37
causing no delay. This means that using the method from Fig. 3.14 allows
all of the data to be written to the database. Despite being able to store
all of the data the idea of storing the entire IEEE data frame string was
abandoned as it is more convenient to work with the data when stored as
described in table 3.4.
A further and more detailed description of the database VIs is in chapter
5.3.2.
3.6 Summary
In this chapter was a discussion of client-server programming methods. The
simulation process performed during this project was described as well as the
synchronization algorithm used to synchronize data from two diﬀerent PMU
stations. Finally the database demands for the project were addressed.

Chapter 4
Electrical Data Analysis
One of the main objective of this project was to create a client-server pro-
gram to give the possibility of viewing and analyzing electrical measurement
data from PMU stations on-line.
Unfortunately this project does not give much space for comprehensive elec-
trical data analysis but following sections will aim to shed some light on the
analysis performed by the program developed for this project.
4.1 Phase Angle Difference
Amongst several measurements performed by the PMU is the phase angle
measurement as the phase angle is always a part of the phasor defined in
chapter 2.1.3. The voltage (V) and current (I) phasors are defined in (4.1)
and (4.2) along with their phase angles δ and φ respectively.
V = (Vm/
√
2)ejδ
(4.1)
I = (Im/
√
2)ejφ
(4.2)
In (4.1) and (4.2) Vm and Im represent the voltage and current magnitudes
respectively. The client program developed offers the possibility of moni-

40 Electrical Data Analysis
toring the voltage phase angle difference between two stations. It is also
possible to monitor the voltage and current(s) phase angle difference at a
single PMU station. The difference, δ − φ, indicates the changes in the load
observed by the PMU.
As the client program can receive data from two PMU stations simultane-
ously it is possible to compare measurements from both stations on-line.
Although the voltage magnitude and frequency of the stations can be com-
pared on-line then the voltage phase angle difference between the stations is
of most importance. This is because of the relationship between the voltage
phase angle difference and the complex power delivered by a transmission
line.
To demonstrate this relationship it is possible to consider a lossless trans-
mission line between two PMU stations. Although lines are never lossless in
practice, neglecting losses gives simpler expressions for the line parameters.
Fig. 4.1 illustrates this example. Because the line is lossless then
R = G = 0
(R: resistance, G: conductance) which leads to
Z = jX Ω
and
Y
2
=
jωCℓ
2
S
where ℓ is the line length. The complex power (S2) delivered to PMU station
2 is given by (4.3).
S2 = V2ejδ2
V1e−jδ1 − V2ejδ2
−jX
+
jωCℓ
2
V 2
2 ej2δ2
=
jV1V2ejδ2−jδ1 − jV 2
2 ej2δ2
X
+
jωCℓ
2
V 2
2 ej2δ2
(4.3)
From (4.3) the real power delivered can be calculated as follows:
P2 = ℜ(S2) =
V1V2 sin(δ1 − δ2) − V 2
2 sin(2δ2)
X
−
ωCl
2
V 2
2 sin(2δ2)

4.1 Phase Angle Difference 41
Also if (δ1 = δ) and (δ2 = 0) then P2 is given by (4.4).
P2 =
V1V2
X
sin(δ) W (4.4)
PMU 1
V1
= V1
ejd1
PMU 2
V2
= V2
ejd2
Z
Y/2Y/2
Figure 4.1: Equivalent π circuit for a lossless transmission line between two
PMU stations
Where δ is the angle by which V1 leads V2, i.e. the transmission angle.
From (4.4) it is evident that the real power is dependent on the phase angle
difference and thus it can be very interesting to monitor the phase angle
difference in relation to the real power as well as the reactive power.
The calculations and approximations made here are valid for medium long
transmission lines in the range of 80 to 250 km. For longer lines the total
series impedance is
Z′
= Z
sinh(γℓ)
γℓ
Ω
and the shunt admittance is
Y ′
2
=
Y
2
tanh(γℓ/2)
γℓ/2
S
where
γ =
√
zy m−1
called the propagation constant. z and y are the series impedance and shunt
admittance, respectively, per unit length. This is described further in [1].
From these calculations it is evident that a comparison between two stations
at the same time, measuring at the same level (at both ends of a transmis-
sion line) gives the most meaningful results. Thus adding more stations is
unnecessary and can only complicate things.

42 Electrical Data Analysis
4.2 Power Calculations
The previous section demonstrates that the power absorbed by the load is
dependant on the phase angle difference. Relating to that it can be inter-
esting to monitor the real and reactive power in relation to the phase angle
difference.
For a general RLC load under sinusoidal-steady-state excitation, the load
current can be given by (4.5). Similarly the load voltage is assumed to be
given by (4.6)
i(t) = Im cos(ωt + β) A (4.5)
v(t) = Vm cos(ωt + δ) V (4.6)
Then the instantaneous power absorbed by the load is
p(t) = v(t)i(t) = VmIm cos(ωt + δ) cos(ωt + β)
= V I cos(δ − β){1 + cos [2(ωt + δ)]} + V I sin(δ − β) sin [2(ωt + δ)]
Substituting IR for I cos(δ − β) and IX for I sin(δ − β) leads to (4.7)
p(t) = V IR{1 + cos [2(ωt + δ)]} + V IX sin [2(ωt + δ)] (4.7)
The average power P, absorbed by the resistive component of the load, can
then be calculated from (4.7) and is given by (4.8). Similarly the average
reactive power Q, absorbed by the reactive part of the load, is given by (4.9).
P = V IR = VrmsIrms cos (δ − φ) W (4.8)
Q = V IX = VrmsIrms sin (δ − φ) Var (4.9)
The client program offers the possibility of monitoring P and Q from station
A along with the phase angle difference between station A and B.

4.3 Summary 43
4.3 Summary
This chapter was mainly a short description of the electrical data calculations
that are available in the monitoring VIs of the program developed during
this project.

Chapter 5
Program Architecture
The greater part of the work in this project was to develop the client-server
program in LabVIEWR
. Therefore it is important to report some of the
work done here. This chapter will be dedicated to the description of the
programs developed during the project. This description will include a pro-
gram manual describing the user interface of the program, the hierarchy of
the programs, block diagrams, flow charts and algorithms.
5.1 The Program Manual
In order to get a better comprehension on what the program is all about
Fig. 5.1 illustrates simplified overview of the client-server program, set up
at DTU. What Fig. 5.1 shows is the two different set-ups of the Global
Variable VIs belonging to both PMU stations. The Global Variable VI that
PMU station 1 writes to is located at the client whereas the one belonging to
PMU station 2 is hosted locally. This means that station 1 needs to specify
an IP–address to access the Global Variable VI and the client also needs to
specify an IP–address to access the Global Variable VI located at station 2.
This is also described in chapter 3.1.3.
Before running the client-server program following matters must be consid-

46 Program Architecture
global
variable
VI
global
variable
VI
IEEEarray IEEEarray
PMU 1
SERVER VI
Array Queue
PMU 2
SERVER VI
Array Queue
PC
Array Queue Array Queue
Synchronize
and
Monitor
Database
Cluster Queue
Cluster QueueCluster Queue
Cluster Queue
CLIENT VI
Figure 5.1: Overview of the client-server program, set up at DTU
ered.
• The connection between the client and the server must be veriﬁed.
This can be done with the LabVIEWR
VIs Set and Get available from
www.ni.com.
• The PMUs LabVIEWR
VIs must be running.
• Paths locating the Global Variable VIs must be accurate in both the
Server.vi and the Client.vi
• IP–addresses of the servers and the client must be veriﬁed.
• The database connection must be checked.
When this has all been checked the server VIs and the client VI can be run
in no particular order.

5.1 The Program Manual 47
5.1.1 The Server Manual
The front panel of the modified PMU COMMON.vi in Fig. 5.2 is the inter-
face on the screen at the DTU PMU when it is running. The modifications
done for the client-server program are the controls depicted in the SERVER
operations box. There the most important ones are the Live Stream drop
down menu and the IP–address field.
Figure 5.2: The front panel of the modified PMU COMMON.vi at the server
computer
In the Live Stream drop down menu the user can select ”one station” to start
the Server VI that sends the data on-line to a Global Variable VI located
at the computer specified by the IP–address field. If the IP–address field is
left blank then the Server VI writes the data to a local Global Variable VI.
By selecting the ”two stations” option, two Server VIs start running where
the second one serves as a reference server that was developed exclusively
for the testing process. The reference Server VI can be used to implement
phase angle difference or time delay specified with the PhaseDiff and Delay
fields respectively. The LED’s, Serv1 and Serv2, indicate if an error occurs
in the Server VIs.
When the ”one station” option is selected a Server VI front panel pops up
and a green LED, labeled Sending, lights up indicating that the data is being
written to the Global Variable VI.

5.1.2 The Client Manual
The client interface was designed in such a way that the user does not have to
think about IP–addresses, VI paths or database connections. Thus making
the interface simple and user friendly. To make sure that this design goal is
achieved, the programs must be installed properly in the beginning.
Before running the client VI the PMU stations to be monitored must be
selected from the drop down menus, Station 1 and Station 2, shown in Fig.
5.3. The size of the data queues can also be changed in the IEEEQsize field.
When the client is running, the View and Database drop down menus only
become active when the data retrieved from the Global Variable VIs has
been verified. This allows the user to store the data in database and/or
monitor the data on-line from a graph.
Figure 5.3: The front panel of the Client.vi
By selecting the option ”P and Q” from the View menu the VI depicted
in Fig. 5.4 pops up. The upper graph monitors P (the real power) and Q
(the reactive power) of station 1 as well as the voltage phase angle difference
between station 1 and 2. The lower graph then shows the voltage magnitude
and the frequency of station 1.
The View menu also offers two other options, ”CAM” (short for compare
and monitor) and ”PhDiff”. By selecting the ”CAM” option a similar VI as
depicted in 5.4 pops up. This VI offers the possibilities of monitoring one
of the following options at a time:

5.1 The Program Manual 49
Figure 5.4: The front panel of the P and Q monitor VI
1. The voltage magnitudes from PMU station 1 and 2.
2. The voltage phase angles from PMU station 1 and 2.
3. The current magnitudes from PMU station 1 and 2.
4. The current phase angles from PMU station 1 and 2.
5. The frequencies from PMU station 1 and 2.
When the ”PhDiﬀ” is selected a monitor pops up showing the voltage and
current phase angle diﬀerences from PMU stations 1 and 2.

5.2 The Hierarchy
Figs. 5.5, 5.6 and C.1 illustrate the hierarchies of the programs developed
during this project. In these figures the double lined boxes include the main
VIs, normal lined boxes include sub VIs and VIs called by the main VIs, dot-
dashed boxes indicate a drop-down menu and option numbers and dotted
boxes represent VIs that were developed during the project but are not
important for the program operation. The numbered boxes beneath some
of the VIs indicate that there are two of the VIs connected to the numbers,
one for each PMU being monitored.
PMU_COMMON.viOther PMU VI’s
PMU_SERIAL.vi
Global_Data.vi
NEWConverData.vi
NEWIEEE_CRC.vi
BuffArray.vi
SERVER
2nd Server.vi
2
SERVER.vi
ConvertManip.vi
1
Figure 5.5: The hierarchy of the Server.vi and its associated VIs
The blue boxes in Fig. 5.5 represent VIs developed by Mr. Pedersen and
are described in appendix A, Figs. A.1 and A.2. These VIs were slightly
modified during this project in relation to the server.vi.
The Global Data.vi and the Global info.vi are not to be confused with the
Global Variable VIs as these VIs contain local global variables used by the
server- and the client-programs respectively. The other VIs in the hierarchy
figures are described in the following sections.
5.3 Description of the VIs
The VIs in Figs. 5.5, 5.6 and C.1 need to be explained some more in order
to give understanding of their functionality in the whole program.

5.3 Description of the VIs 51
CLIENT.vi
ChkandBuff.viGetInitTime.viArraytoClusters.vi
Global_info.vi
VIEW DATABASE
1 2 3 10
CAM.vi PhDiff.vi PQ_Mon.vi WritetoDB.viNo DB
DatatoBuffer.vi
CRC_Chk.vi
DBandCAMbuff.vi
DayTable.vi
TableOperations.vi
Figure 5.6: The hierarchy of the Client.vi and its sub VIs
This section is rather detailed and can be interesting for those interested in
LabVIEWR
programming or other general programming languages.
5.3.1 The Server VIs
Server.vi
The main purpose of the server.vi is to extract data from an array queue
containing arrays of data frame strings and write the data to the Global
Variable VI. Fig. 5.7 explains the program flow of the server.vi and Fig.
5.8 shows the block diagram of the server.vi when it has located the Global
Variable VI and is writing the data to it (Case:1 in Fig. 5.7).
Notice that in the block diagram of Fig. 5.8, the data array is transferred
as a variant but not as a flattened string as in Fig. 3.3. By doing this, using
the Flatten to String VI is avoided as it is only available in LabVIEWR
7.x.
LabVIEWR
8.0 (used in this project) has a Flatten to String VI but that VI
does not offer the output ”type string” that is necessary when transferring

SERVER
Initialize the VI
while no error or stop = false
Case:0
Is there any data
in array Queue
IEEEQ
yes no
Connect to the Global
Variable VI
SHIFT = 1
Case:1
Extract data from IEEEQ
and write to Global
Variable VI
Restore variables and
terminate the VI
SHIFT 0
1
wait
TOL = nx20 ms
Figure 5.7: The flow chart of the server VI
flattened data using the Invoke Node VI.
NEWConvertData.vi and NEWIEEE CRC.vi
NEWConvertData.vi and NEWIEEE CRC.vi are newer versions of Conver-
Data.vi and IEEE CRC.vi from the original PMU software. The NEWCon-
vertData.vi converts the measurement data to a data frame defined in the
new IEEE standard [9] instead of a data frame defined in the 1995 standard
[2] as the ConvertData.vi does.
The NEWIEEE CRC.vi calculates the CRC code of the data, discussed in
chapter 2.3. This VI uses the C-code algorithm defined in appendix B of
the new IEEE standard [9].

Figure 5.8: The block diagram of the server VI in normal operation
PMU COMMON.vi and PMU Serial.vi
These two VIs from the original PMU software had to be slightly modified
in order to run the server.vi. The PMU COMMON.vi was changed so that
when it reaches Case:22 (See Fig. A.1) then the user can choose to run
server.vi and thus start sending the data on-line. Extra variables, necessary
for running server.vi, were also created in Case:0 of the PMU COMMON.vi.
Case:20, 0.0.4 (See Fig. A.2) of the PMU Serial.vi was modified in such a
way that the measurement data, streaming from the MS-DOSR
computer,
is converted to a data frame, inserted into an array and buffered to a queue
(IEEEQ) when the array includes n number of data frames. Each time the
array is enqueued it’s elements are removed.

Figure 5.9: The block diagram of the client VI, retrieving data from the Global
Variable VIs
5.3.2 The Client VIs
Client.vi
The main purpose of the client.vi is to retrieve data, sent from two diﬀerent
PMU stations, from the Global Variable VIs. Fig. 5.10 illustrates the ﬂow
of the client.vi and Fig. 5.9 shows the program’s block diagram while in the
process of retrieving data from the Global Variable VIs.
The client VI runs two while-loops in parallel during normal operation. The
”upper loop’s” purpose, in Fig. 5.9, is only to retrieve data, extract data

CLIENT
0.0 Queues created
0.1 Establish connection to both Global Variable VIs
0.2 Check for data in both Global Variable VIs
while stop = false Case:0
0 Retrieve data from both Global
Variable VIs
Get initial time with GetInitTime.vi
1 Perform CRC on array1 and
buffer array1 to IEEEQ1 if
array1 has reached initial time
no yes
Both arrays reached initial time ?
Case:1
Are there any elements in
IEEEQ1 and IEEEQ2
no yes
Case:2.1
Dequeue IEEEQ1 -> DBandCAMbuff.vi
DBandCAMbuff.vi -> CAM1 and DBQ1
0
1
WAIT until next nx20 ms multiple2
goto Case:2.1 next
goto Case:1 next
Promt user to run:
Promt user to save
data to database
A: CAM.vi
B: PhDiff.vi
C: PQmon.vi
2 Perform CRC on array2 and
buffer array2 to IEEEQ2 if
array2 has reached initial time
Case:2.0
Dequeue IEEEQ2 -> DBandCAMbuff.vi
DBandCAMbuff.vi -> CAM2 and DBQ2
1 Perform CRC on
array1 and buffer
array1 to IEEEQ1
2 Perform CRC on
array2 and buffer
array2 to IEEEQ2
WAIT until next nx20 ms multiple
3
1.0
while stop = false
RUNINPARALLEL
2.0
Destroy Queues, Abort Vis, EXIT
TOL = nx20 ms
Figure 5.10: The ﬂow chart of the client VI
and enqueue data to the appropriate queues. The ”lower loop” then checks
if the user wishes to monitor the data or store it in a database by running
appropriate VIs. The reason for doing this is because that when the user

chooses to run a monitor program, an Invoke Node VI is called which could
delay the ”upper loop” if it was placed there. That is unacceptable as the
process in the ”upper loop” is very sensitive to any disturbances and it has
to be synchronized with the server main loop.
GetInitTime.vi
This VI compares the SOC values of both arrays retrieved. It returns the
higher SOC value incremented by one second. The VI is only called one
time to determine the initial time of the values to be placed in the IEEEQs
(see Fig. 5.10).
ChkandBuﬀ.vi
This VI uses a for-loop to go through all n elements of the arrays retrieved.
Each element goes through a CRC (CRC Chk.vi) and if any of the elements
include errors detected by the CRC algorithm then an error message is
displayed in the source window (see Fig. 5.3. This VI also enqueues the
arrays into the IEEEQs (see Fig. 5.10).
ChkandBuff.vi
Queue in
Queue size
INPUT
Station ID
Array in
msg
OUTPUT
Figure 5.11: Inputs and Output of the ChkandBuﬀ.vi
ArraytoClusters.vi
The inputs and outputs of ArraytoClusters.vi are shown in Fig. 5.12. This
VI has a for-loop that extracts information from the array input into clus-
ters that are enqueued to the CAM and DB queues (see Fig. 5.10) in each
for-loop iteration. This means that for every array element dequeued from
the IEEEQs, n elements are enqueued to the CAM and DB queues. The
information in the clusters generated depend on which PMU is being moni-
tored, controlled by the PMU ID (Station ID) input. For the PMU stations

located at DTU the cluster would have the same information as listed in
table 3.4.
ArraytoClusters.vi
CAM Queue in
DB Queue in
INPUT
Station ID
Array in
#MON
OUTPUT
SOC
Figure 5.12: Inputs and Output of the ArraytoClusters.vi
CAM.vi, PhDiff.vi and PQmon.vi
while stop = false Case:0
Are there any elements in
CAM1 and CAM2
yes no
Case:1
Synchronization algorithm
Case:2
0
WAIT until next 20 ms
multiple
1
Dequeue CAM1 and CAM2
Extract Data
Print Data to Chart
2
Is Data out of sync?
yes no
Figure 5.13: The flow chart of the monitor VIs
These three VIs all have the same structure and their common flow chart
is depicted in Fig. 5.13. The only part that differentiates them apart is
Case:2.1 where the data is extracted from the queues and printed to the
screen.
The CAM.vi has a drop-down menu that allows the user to select between
viewing a comparison of the voltage magnitude, voltage phase angle, current

magnitude, current phase angle or the frequency of the PMU stations being
monitored.
The PhDiff.vi calculates the difference between the voltage phase angle and
the current phase angle from both PMU stations.
Finally the PQmon.vi uses the PQcalc.vi to calculate P and Q from (4.8)
and (4.9). Then it prints out the voltage phase angle difference between
both PMU stations along with the calculated values of P and Q from PMU
station no. 1.
WritetoDB.vi
WRITE TO DB
0.0
Set InitTime equal to
max(DBQ1(SOC),DBQ2(SOC))+1
0.1
Dequeue DBQ1 while
DBQ1(SOC) != InitTime
Dequeue DBQ2 while
DBQ2(SOC) != InitTime
1
while exit = false
0.2 Get PMU ID’s from both stations, set day and year
Open connection to DB
Generate table names
0.3
create tables if they don’t exist
with TableOperations.vi
1.0
Wait until next 20ms multiple
1.1 check day and year to decide
whether to create and/or drop
tables with DayTable.vi
1.2
Dequeue DBQ1 and DBQ2
and insert data to DB
2
close connection to DB
check if tables exist
0.4
Figure 5.14: The flow chart of the WritetoDB.vi
In chapter 3.5.2 it is roughly estimated that a single mdb file could store up
to 10 days of data from a PMU station. Here the demand is that the mdb

ﬁle must store data from two PMU stations. This is why the WritetoDB.vi
only allows a maximum data storage for a week. Adjusting the storage
time is however not problematic. Fig. 5.14 shows the ﬂow chart of the
WritetoDB.vi.
DayTable.vi
This VI controls whether it is necessary to create and/or drop tables in the
database. New tables are created every time a new day starts and the oldest
tables are dropped if the database is full.
DayTable.vi
Option
Day of year
INPUT
SOC
Table in 2
Table in 1
Table out 1
Table out 2
OUTPUT
Figure 5.15: Inputs and Outputs of the DayTable.vi
TableOperations.vi
This VI either drops a table, creates a table, inserts data into a table, gets
data from a table or lists tables available in a database. The inputs are
shown in Fig. 5.16. The TableOperations.vi is called both by WritetoDB.vi
and DayTable.vi. The VI creates tables of the format described in table 3.4.
TableOperations.vi
Option
INPUT
Table name
Figure 5.16: Inputs of the TableOperations.vi

5.4 Summary
This chapter includes the program’s manual, describing the procedure when
running then client-server program. It also describes and illustrates the pro-
grams developed for this project in such a way that it could be reconstructed
in any other programming language. The program hierarchy is documented
as well as the ﬂowcharts of the main parts of the program.

Chapter 6
Conclusion
In this project a client-server program was developed in order to present
measurement data on-line from two PMU stations simultaneously. The
LabVIEWR
software was chosen for the job, both because the PMU soft-
ware was programmed in it and also because it oﬀers several methods of
client-server programming solutions. In the beginning the Global Variable
method and the TCP/IP method were considered as possible candidates for
this project. Both methods were compared and of the two the Global Vari-
able method was chosen, mainly because of a delay problem in the TCP/IP
method.
A database interface was also designed in LabVIEWR
to store the data at
the client for the possibility of further data analysis. The MicrosoftR
Access
database was selected to store the data.
6.1 Results
At ﬁrst the Global Variable method seemed to live up to the task quite well.
However while the data was being monitored, the synchronization algorithm
frequently interrupted causing the monitoring process to ”hiccup” occasion-
ally. The reason for this, as later revealed, was that the time restriction of

62 Conclusion
20 ms was to strict for the program to transfer the data. The Invoke Node
VI, used to write to and read from the Global Variable VI, takes at least
twice the required time to execute. This resulted in severe data loss as more
than half of the data did not transfer.
The solution was to transfer n number of measurements as an array, every
nx20 ms, where n should be at least 5. By doing this the time critical Invoke
Node VI was called only ones each nx20 ms. Thus the server program and
the data retrieving part of the client had a synchronized run time of nx20
ms whereas the run time of the monitor and database programs remained
20 ms. Therefore the measurements could be viewed and stored every 20
ms.
Unfortunately there was not enough time to test the final version of the
program on the DTU PMUs. Earlier testing procedures did however give
similar results as the simulation processes. Thus it will be assumed that,
since the simulation of the final version did run without any major faults,
the program will also run fine over the network.
6.2 Further Work
The Global Variable method has at least one flaw which is the possibility
of data loss. The reason for this possibility is because there is no buffer
between the client and the server. Thus the data sent on-line is constantly
overwritten which could lead to data loss if the client gets held up for some
reason and cannot retrieve the data in time before the server writes new
data over the old one.
A possible solution to this might be to replace the Global Variable VI with
a Functional Global Variable VI discussed in appendix D.
Another possible solution could be to use the LavVIEW’sR
network-published
shared variable. Using the network-published shared variable, it is possible
to write to and read from shared variables across an Ethernet network. The
network-published shared variable also has a built in FIFO (first in first out)
buffer system [6].
The resulting program is not entirely finished but it can be used as ”bone
structure” for further development of this type of project. The program
is very sensitive to any external computer operations which can affect the

6.3 The Broader Perspective 63
timing- and the synchronization process. Changing the database provider
should also be considered as the MicrosoftR
Access database is rather lim-
ited.
6.3 The Broader Perspective
The idea of presenting or analyzing measurement data from PMU stations
on-line is hardly new in the worldwide perspective. Numerous PMU stations
are being produced today and many of them provide the possibility of on-line
monitoring.
The program developed in this project was purely based on the PMU device
constructed at DTU. The idea behind the DTU PMU device is not to design
a product for marketing purposes, but more intended as a tool to be used for
further research and developments in the electrical system. Thus a client-
server program as developed in this project could be used to further enhance
those studies and widen the range of the DTU PMU possibilities.

Appendix A
The DTU PMU LabVIEW
Program Overview
PMU COMMON.vi
The PMU COMMON.vi whose flowchart is shown in Fig. A.1 is the main
VI of the PMU. The VI begins with running important VIs as PMU Serial.vi
(Fig. A.2 and PMU IEEE.vi (Fig. A.3). Then the buffers are created and
initialized. Network and serial connections are verified. But most impor-
tantly this VI controls all communications with the MS-DOSR
computer
and prepares for receiving the package sent from that computer.

PMU_DTU1
PMU_COMMON
State: 0 State: 1
Case:0
0.0
Get PMU name from
WAMS_Spec
0.1
0.1.0
Initialize global variable
LogQueue
0.1.1
Run PMU_Log.vi
0.2
Initialize global variables:
DiscNotify, GPSNotify
Checks net connection
with NetConnect.vi
Other initialization
0.3
Run PMU_Serial.vi
0.4
0.4.0
DataQueue, DataSmf
0.4.1
Run PMU_IEEE.vi
0.5
MonitorHistory,
MonitorQueue,
DebugQueue
Error
N
Y
Case:1
Opens Com with
ComOpen.vi
TF
Case:2
EstablishSerial
Connection.vi
TF
Case:3
Send command with
SendCmd.vi which creates
telegraph with
CreateTele.vi
OK
N
Case:4
Y
CreateTele.vi
Error?
No:
CheckProto.vi
Case:5
Yes:
ErrorMain
Case:0
Case:5
StopCmd.vi
TF
Case:17
EstablishSerial
Connection.vi
TF
40x
Case:18
Send command with
SendCmd.vi which creates
telegraph with
CreateTele.vi
TF
Case:20
Prepairing package
receiving
Case:22
Case:21
Check if global variables:
GPS_Running AND
DATA2DISK_Running
TF
Run MonitorDTU1.vi, or
Debug.vi or SetPCTime.vi
or none of these three
Case:10
NetConnect.vi
TF
DosBoot.vi
Case:11
NetConnect.vi
TF
30x
Case:12
SetdosZ.bat
Error
DosBoot.vi
N
Y
Case:13
NetConnect.vi
FT
40x
Case:14
Wait 1s 20 times
After each case in State:0 go to State:1
and check ErrorMain, ErrorProto and
ErrorDisk
If No Error then go to next case in
State:0
Else
1.0
StopProto
StopDisk
Wait 1s
Close references to
MonitorDTU1.vi
SetPCTime.vi
Debug.vi
1.1
If ErrorMain then
write to Message.vi
and do if error is:
1..99
close Virefs
goto case 0*
100..199
close COM1
goto case 1*
200..599
Normal mode: goto case 10*
Test mode: goto case 2*
1100..1199
close COM1
goto case 1*
1200..1299
goto case 13*
1300..1699
goto case 1*
1700..2199
close COM1
goto case 1*
else if not ErrorMain then
nothing
1.2
If ErrorProto then write to
Message.vi and goto case 1**
1.3
If ErrorDisk then write to
Message.vi and goto case 1***
1.4
Clear ErrorMain,
ErrorProto and ErrorDisk
* after State:1.4 and ErrorDisk=ErrorDisk=0
** after State:1.4 and ErrorDisk=0
*** after State:1.4
Figure A.1: The ﬂowchart for the DTU PMU common program

67
PMU Serial.vi
PMU_Serial
State: 0 State: 1
Case:0
Check GPS_notify
if error
ErrorProto=1
else if GPS_notify !=20
ErrorProto=1
else
goto case:1*
Case:1
Write buffer 10 to COM1
goto case:20
Case:20
0.0
Read buffer from COM1
if error
return 20 to state:0.1
else
If buffer != 81
else
read packet (83 bytes) from COM1
If byteCount != 83
return 22 or 25 to state:0.1
else
CheckProto.vi
(check if packet is legal)
If CheckProto.vi is false
else
ParseData.vi
(string packet into array packet)
If ParseData not OK
else
0.0.0
Divide packet into global variables:
MonitorQueue
MonitorHistory
DebugQueue
TimeNotf
0.0.1
Packet into NewPacket
0.0.2
First packet: return 0 to
state:0.1
Not first packet:
if UTC != UTC_Old(+1)
return -2 or -3 to state:0.1
else
if #packet > 179.999
return -4 to state:0.1
else
If #packet <= Old_packet and #packet !=0
and Old_packet != 179.999
else
If #packet != Old_packet+1
else
0.0.3
UTC to UTC_Old
#packet to Old_packet
0.0.4
Data2Buffer.vi
0.1
If number from state:0.0 < 0
flush buffer
else
next package
If ExitAll = StopProto =
False
Check ErrorProto
initialize ErrorProto
goto state:0
Figure A.2: The ﬂowchart for the DTU PMU serial program
The PMU Serial.vi reads the packet sent through COM port from the MS-
DOSR
computer. Checks the package for errors and then buﬀers the data

68 The DTU PMU LabVIEW Program Overview
from the packet.
PMU IEEE.vi
PMU_IEEE
State: 0 State: 1
Case:0
Check global variable
DISK_notify
if timout = false
goto case 1
Case:1
Check global variable
DataQueue
if error
ErrorDisk = 1
else
check #of elements in
DataQueue
If #of elements in
DataQueue = 0
wait 10 ms
else
goto case:1.0
1.0
If #of elements in
DataQueue - QLngth =< 0
goto case:1.1
else
dequeue DataQueue
goto case:1.1
1.1
Dequeue DataQueue
CreateFileName.vi
(create BIN files and folders)
ConvertData.vi
(convert data to IEEE standard)
Write data to BIN file
if error
goto case:0
else
write: Disk: New File to message.vi
goto case:1.2
1.2
Dequeue DataQueue
ConvertData.vi
if hour from ConvertData.vi
= hour of last data
goto state:0.1
else
goto state:0.0.0
0.0
0.0.0
Close BIN file
0.0.1
Zip BIN file with Zip.vi
0.0.2
Disk: New File to Msg.vi
CreateFileName.vi
0.1
Write to BIN file
if error
ErrorDisk=4
goto case:0
else
goto case:1.2
If ErrorDisk != 0 or StopDisk is true
or ExitAll is true
close BIN file
Zip BIN file with Zip.vi
goto case:0
else
goto next case which was called in
state:0
Figure A.3: The flowchart for the DTU PMU log and IEEE programs
The PMU IEEE.vi extracts the data from the data queue and converts it to
a data frame string defined by IEEE standard. Then it stores one hour of
data, as zipped binary files.

Appendix B
Packet Description
Here is the packet description of the packet sent from the MS-DOSR
com-
puter of the PMU to the WindowsR
computer. The packet is sent through
a COM port as the network operations of the MS-DOSR
computer are dis-
abled.
One packet is transferred each whole 20 ms UTC time exactly. The time
stamp is the beginning of the 20 ms UTC interval. Data bytes are swapped
according to LabVIEWR
data format.

On-Line Presentation of Data from PMU Stations

On-Line Presentation of Data from PMU Stations

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to On-Line Presentation of Data from PMU Stations

Similar to On-Line Presentation of Data from PMU Stations (20)

More from Power System Operation

More from Power System Operation (20)

Recently uploaded

Recently uploaded (20)

On-Line Presentation of Data from PMU Stations