Aml Thesis

Arnar Mr Loftsson a
On-Line Presentation of Data from PMU Stations
M.Sc. Thesis, October 2006
Arnar Mr Loftsson a
M.Sc. Thesis, October 2006
Author Arnar Mr Loftsson a 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 Class Edition Notes
01.10.2006 1.(Public) 1. edition This report is part of a M.Sc. Electrical Engineering education program at the Technical University of Denmark c Arnar Mr Loftson, 2006 a
Copyright
Preface
This thesis was prepared at Center for Electric Technology (CET), the Technical University of Denmark in partial fulllment 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 monitoring 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 Arnar Mr Loftsson a
ii
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 LabVIEW R software from National Instruments Corporation was used to develop the client-server program as well as the database interface using the LabVIEW R Database Toolset. The project was twofold: At one hand the implementation of a server program to interact with existing PMU software. 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.
iv
Contents
Preface
Abstract
iii
List of Figures
ix
List of Tables
xiii
List of Symbols
xvii
1 Introduction 1.1 1.2 1.3 1.4 1.5 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problem Description . . . . . . . . . . . . . . . . . . . . . . . Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations and Requirements . . . . . . . . . . . . . . . . . . Work of Others . . . . . . . . . . . . . . . . . . . . . . . . . .
1 2 2 2 3 3
vi 1.6
CONTENTS Range of Work . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 The Phasor Measurement Unit 2.1 Description of the PMU . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.1.4 2.2 The DTU PMU . . . . . . . . . . . . . . . . . . . . . . Satellite system . . . . . . . . . . . . . . . . . . . . . . The Phasors . . . . . . . . . . . . . . . . . . . . . . . Data Transmission . . . . . . . . . . . . . . . . . . . .
5 5 5 6 7 7 8 8 9 11 11 12 13 14
Standards for Synchrophasors for Power Systems . . . . . . . 2.2.1 2.2.2 The 1995 Standard . . . . . . . . . . . . . . . . . . . . The 2005 Standard . . . . . . . . . . . . . . . . . . . .
2.3
The Cyclic Redundancy Check . . . . . . . . . . . . . . . . . 2.3.1 2.3.2 2.3.3 CRC in general . . . . . . . . . . . . . . . . . . . . . . The CRC of the DTU PMU . . . . . . . . . . . . . . . CRC Discussion . . . . . . . . . . . . . . . . . . . . .
2.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Design and Construction 3.1 Client-Server Programming Methods . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 The TCP/IP Method . . . . . . . . . . . . . . . . . . The Global Variable Method . . . . . . . . . . . . . . TCP/IP Compared to Global Variable . . . . . . . . .
15 15 16 17 18
CONTENTS 3.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 3.3 The Server Simulation Program . . . . . . . . . . . . . The Client Simulation Program . . . . . . . . . . . . . Simulation Results . . . . . . . . . . . . . . . . . . . .
vii 20 20 20 23 25 26 26 27 27 28 28 30 31 32 32 33 35 37
Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 Global Queues . . . . . . . . . . . . . . . . . . . . . . Double Buer System . . . . . . . . . . . . . . . . . . Shared Variables . . . . . . . . . . . . . . . . . . . . . Timed Structures . . . . . . . . . . . . . . . . . . . . . Initial Synchronization . . . . . . . . . . . . . . . . . . The Synchronization Check . . . . . . . . . . . . . . .
3.4 3.5
Loop Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 3.5.2 3.5.3 3.5.4 Database Setup . . . . . . . . . . . . . . . . . . . . . . Database Limitations . . . . . . . . . . . . . . . . . . The Data Storage . . . . . . . . . . . . . . . . . . . . Improved Database VIs . . . . . . . . . . . . . . . . .
3.6
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Electrical Data Analysis 4.1 4.2 Phase Angle Dierence . . . . . . . . . . . . . . . . . . . . . . Power Calculations . . . . . . . . . . . . . . . . . . . . . . . .
39 39 42
viii 4.3
CONTENTS Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Program Architecture 5.1 The Program Manual . . . . . . . . . . . . . . . . . . . . . . 5.1.1 5.1.2 5.2 5.3 The Server Manual . . . . . . . . . . . . . . . . . . . . The Client Manual . . . . . . . . . . . . . . . . . . . .
45 45 47 48 50 50 51 54 60
The Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . Description of the VIs . . . . . . . . . . . . . . . . . . . . . . 5.3.1 5.3.2 The Server VIs . . . . . . . . . . . . . . . . . . . . . . The Client VIs . . . . . . . . . . . . . . . . . . . . . .
5.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Conclusion 6.1 6.2 6.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . The Broader Perspective . . . . . . . . . . . . . . . . . . . . .
61 61 62 63
A The DTU PMU LabVIEW Program Overview
65
B Packet Description
69
C Additional Database VIs C.1 The Hierarchy of the Additional Database VIs . . . . . . . .
73 74 75
C.2 Description of the Additional Database VIs . . . . . . . . . .
CONTENTS D Functional Global Variables D.1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . .
ix 77 78
E The Program CD
79
Bibliography
81
CONTENTS
List of Figures
2.1 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9
Data frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple TCP/IP server . . . . . . . . . . . . . . . . . . . . . . Simple TCP/IP client . . . . . . . . . . . . . . . . . . . . . . Simple Global Variable server . . . . . . . . . . . . . . . . . . Simple Global Variable client . . . . . . . . . . . . . . . . . . Conguration of PMUs and client . . . . . . . . . . . . . . . . The server simulation block diagram . . . . . . . . . . . . . . The client simulation block diagram . . . . . . . . . . . . . . The array server block diagram . . . . . . . . . . . . . . . . Single global queue . . . . . . . . . . . . . . . . . . . . . . . .
8 16 16 17 17 19 21 22 24 26 26 31 35
3.10 Double global queue . . . . . . . . . . . . . . . . . . . . . . . 3.11 Loop timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12 Angle mean value . . . . . . . . . . . . . . . . . . . . . . . . .
xii
LIST OF FIGURES 3.13 Block diagram of DB VIs . . . . . . . . . . . . . . . . . . . . 3.14 Improved block diagram of DB VIs . . . . . . . . . . . . . . . 4.1 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 Equivalent circuit . . . . . . . . . . . . . . . . . . . . . . . Overview of the program . . . . . . . . . . . . . . . . . . . . . Front panel of PMU COMMON.vi . . . . . . . . . . . . . . . Front panel of Client.vi . . . . . . . . . . . . . . . . . . . . . 36 36 41 46 47 48 49 50 51 52 53 54 55 56 57 57 58 59 59 66
Front panel of monitor VI . . . . . . . . . . . . . . . . . . . . The Server Hierarchy . . . . . . . . . . . . . . . . . . . . . . . The Client Hierarchy . . . . . . . . . . . . . . . . . . . . . . . Server ow chart . . . . . . . . . . . . . . . . . . . . . . . . . Server block diagram . . . . . . . . . . . . . . . . . . . . . . . Client block diagram . . . . . . . . . . . . . . . . . . . . . . .
5.10 Client ow chart . . . . . . . . . . . . . . . . . . . . . . . . . 5.11 Inputs and Output of ChkandBu.vi . . . . . . . . . . . . . . 5.12 Inputs and Output of ArraytoClusters.vi . . . . . . . . . . . . 5.13 Monitor ow chart . . . . . . . . . . . . . . . . . . . . . . . . 5.14 Write to DB ow chart . . . . . . . . . . . . . . . . . . . . . . 5.15 Inputs and Outputs of DayTable.vi . . . . . . . . . . . . . . . 5.16 Inputs of TableOperations.vi . . . . . . . . . . . . . . . . . . A.1 DTU PMU Flowchart . . . . . . . . . . . . . . . . . . . . . .
LIST OF FIGURES A.2 DTU PMU Serial owchart . . . . . . . . . . . . . . . . . . . A.3 DTU PMU Log and IEEE . . . . . . . . . . . . . . . . . . . . C.1 The Database VIs Hierarchy . . . . . . . . . . . . . . . . . . . C.2 Save to DB ow chart . . . . . . . . . . . . . . . . . . . . . . C.3 Inputs and Outputs of MeanCnt.vi . . . . . . . . . . . . . . . C.4 Inputs and Output of MeanCalc.vi . . . . . . . . . . . . . . . C.5 Inputs of DatatoDB.vi . . . . . . . . . . . . . . . . . . . . . . D.1 Block diagram of a FGV . . . . . . . . . . . . . . . . . . . . .
xiii 67 68 74 75 76 76 76 78
xiv
LIST OF FIGURES
List of Tables
2.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5
Data frame organization I . . . . . . . . . . . . . . . . . . . . Data frame organization II . . . . . . . . . . . . . . . . . . .
9 10 12 29 29 30 34 35 70 71 71 72
CRC Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronization pseudo code I . . . . . . . . . . . . . . . . . Synchronization pseudo code II . . . . . . . . . . . . . . . . . Synchronization pseudo code III . . . . . . . . . . . . . . . . Data extracted from the IEEE string . . . . . . . . . . . . . . Mean value of angle algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1 MS-DOS R to Windows R Packet
B.2 The stat0 variable . . . . . . . . . . . . . . . . . . . . . . . . B.3 The stat1 variable . . . . . . . . . . . . . . . . . . . . . . . . B.4 Indexed data description . . . . . . . . . . . . . . . . . . . . .
xvi
LIST OF TABLES
List of Symbols
Symbol CRC DB DTU FGV GPS IEEE NI ODBC PC PMU SOC SQL TCP/IP TOL UDL UTC VI WACS WAMS
Denition The Cyclic Redundancy Check Database Technical University of Denmark Functional Global Variable Global Positioning System Institute of Electrical and Electronics Engineers National Instruments Open Database Connectivity Personal Computer Phasor Measurement Unit Second of Century Structural Query Language Transmission Control Protocol/Internet Protocol Time of Loop Universal Data Link Universal Time Coordinated Visual Instrument Wide Area Stability and Voltage Control System Wide Area Measurement System
xviii
Chapter
Introduction
Increasing technology development and better life standards of the modern 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 eciency. This is often the only option available as it is not always possible to add more power plants or transmission 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 dierent 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 WideArea Stability and Voltage Control System (WACS), where they can receive and analyze measurement 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 faults eect on the system or even stop the fault from occurring.
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 Denmark 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
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 LabVIEW R 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 simulation process, synchronization, and database operations.
Introduction
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
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 dierent 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 running the MS-DOS R operating system and the other is running Microsoft Windows R operating system. The MS-DOS R computer has the role to retrieve measurements from the measurement equipment and place them in a
package, along with other vital information, which is sent to the Windows R computer. The packet description can be seen in appendix B. The reason for choosing MS-DOS R as the operating system for the measurement computer was to gain full control of the computer. By modifying the AUTOEXEC.bat and the CONFIG.sys les in the MS-DOS R system many computer actions, for example updating the screen and conguring network connections, can be turned o. 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 Windows R computer then runs a LabVIEW R 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 les, once every hour. These operations are hard to perform using the MS-DOS R system which explains the selection of the Windows R operating system for this part. The main program structure of the DTU PMU can be seen on the owcharts in appendix A. As seen from those owcharts a common LabVIEW R program is made of one or more Virtual Instruments (VI). These VIs are programs or les made by LabVIEW R . A main program created in LabVIEW R is a VI and has the le 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 running 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 developed 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
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 its receiver is in a xed 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(2f t + ) 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 benet 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 uctuates 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 uctuating frequency. This is not a problem however because what is observed is the dierence between two phase angles which cancels out any uctuation. The phase angle dierence of interest is either between the voltage phase angles of two dierent 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 Conguration 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 eld names, scaling, conversion factors and data format, would be stored in a conguration frame but since the DTU PMU is not equipped with that frame this information is stored in the LabVIEW R les of the Windows R computer.
2.2
Standards for Synchrophasors for Power Systems
The DTU PMU stations were all based on the rst Standard for Synchrophasors 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 identied by having the three most signicant 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
The phasor cells, each 4 bytes, in this case consist of 2 bytes for the magnitude and 2 bytes for the angle respectively, where the magnitude is represented with a 16 bit binary number in the range 0 to 215 1 and the angle is in radians 104 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 103 deviation from system nominal.
2.2.2
The 2005 Standard
Several changes were made from the former standard in this new revised standard. Specically, the sync, frame size and station identication elds have been added to the data frame as well as the analog data eld. The fraction of second eld has replaced the sample count eld and the status eld has been modied to include time quality. Tables 2.1 and 2.2 list the data frame organization of the new IEEE standard. Table 2.1: Word denitions of elds common to all frame types
Field SYNC Bytes 2 Description Frame synchronization word. Leading byte: AA hex Second byte: Frame type and version number. Total number of bytes in the frame, including CHK. PMU ID number, 16 bit integer. Identies device sending and receiving messages. Time stamp, SOC count starting at midnight 01Jan-1970. Fraction of Second and Time Quality, time of measurement for data frames. CRC-CCITT
FRAMESIZE IDCODE SOC FRACSEC CHK
2 2 4 4 2
In the rst round of implementing the new standard, all elds will be available but not active. Meaning that elds like SYNC, IDCODE, STAT, ANALOG and DIGITAL will be assigned a constant default value. This is because fullling the purpose of these elds would mean a considerable change on the existing programs which is both expensive and time consuming. Following changes have also been made on elds that were dened in the
10
Table 2.2: Data frame organization of the 2005 standard

Field STAT PHASORS Bytes 2 4 Description Bitmapped ags. Phasor estimates, 3-phase positive sequence. Polar format: - Magnitude and angle, magnitude rst - 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. 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 Rate of change of frequency in Hz per second times 100. Analog word. 16-bit integer. It could be sampled data such as control signal or transducer value. The number of the analog values is dened in the conguration frame. Digital status word. It could be bitmapped status or ag. The number of the digital status words is dened in the conguration frame.
FREQ
DFREQ ANALOG
2 2
DIGITAL
1995 standard: The STAT eld 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 eld now contains the number of seconds since the 1st of January 1970 instead of 1st of January 1900. The FRACSEC eld replaces the SMPCNT eld from the previous standard. The FRACSEC eld 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 ag. The quality ag 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 conguration frame, but since the DTU PMU unit is not equipped with that frame the TIME BASE is dened in the LabVIEW R program of the DTU PMU unit as a constant 1, 000, 000 s. The time quality ag is used to indicate the quality of the time being reported as well as the Leap Second status. For now this time quality ag 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 todays communication 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 predened bit stream of length n, which represents the coecients 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.
12
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 X 16 + X 12 + X 5 + 1 which can be represented with the hexadecimal word 0x1021. The 2005 standard [9] describes the CRC, commonly referred to as CRCCCITT, in more detail. It shall use the generating polynomial G(x) = X 16 + X 12 + X 5 + 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 A abc ABCD 123456789 Resultant CRC value 0xB915 0x514A 0xBFFA 0x29B1
2.3 The Cyclic Redundancy Check
13
Since the DTU PMU calculates the CRC from a cluster input it is dicult 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 sample C code calculation example from [9] was translated into a LabVIEW R program and the CRC value was calculated for an old data frame. Also a completely dierent CRC C code from [8] was translated into a LabVIEW R 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 dierent result. A thorough examination of IEEE CRC.vi shows that the reason for this dierence 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 detecting 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 nd a method which is generally accepted and dened. 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.
14
2.4
Summary
This chapter briey explains the Phasor Measurement Unit (PMU) developed 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 LabVIEW R was chosen for this project was the fact that the Windows R part of the PMU station was programmed in LabVIEW R . As the main objective in this project is to develop a clientserver program in order to monitor on-line data from PMU stations then the benets of choosing LabVIEW R software is that it oers various methods of programming a clientserver program. Two dierent methods of clientserver programming in LabVIEW R will be examined in this chapter and how they were implemented in the simulation which is also described in the forthcoming sections. The LabVIEW R database toolset will also get its share of this chapter.
3.1
Client-Server Programming Methods
As mentioned above the LabVIEW R oers 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 LabVIEW R 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 LabVIEW R , begins with the listen to connection VI where the time out limit, port number and IPaddress (optional) of the connection to the client are specied. Once the connection has been established the numeric data is cast into a string data and sent via two TCP write VIs. The rst 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 connection VI which opens the connection to the server using appropriate port number and an IPaddress. Once the connection is open the data can be read from the port specied and cast into a numeric representation. The rst 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 LabVIEW R VI Server must be congured. When conguring the VI Server the TCP/IP protocol must be activated and the remote computers 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 attened string as in Fig. 3.3 or as a variant. This is specied 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
18
to the server program in Fig. 3.3 where the dierence 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 attened data. The unatten 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 IPaddress 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 Variable VI. The size of the data does not have to be specied in the Global Variable method. Only one IPaddress, the address of the Global Variable VI, needs to be specied in the Global Variable method. No port number needs to be specied in the Global Variable method unless the user wants a dierent 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 buer 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 Windows R 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
Server VI
global variable VI
PMU 2
Server VI
global variable VI
Client VI
global variable VI
CLIENT PC
Figure 3.5: Conguration 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 Windows R 2000 operating system of the PMUs as this problem does not occur between normal PCs using the Windows R XP system and LabVIEW R 8.
20
3.2
Simulation
One of the advantages of using LabVIEW R is that it oers 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 ow. The solution was to use old data that had been stored in binary format. From these binary les 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 ow 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 ow 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
SERVER.vi run String to Buffer.vi

to sub LOOP
get string from Binary to String.vi
to main LOOP
convert bin file with 1 hour measurement data to a string
while stop = false
divide string into data frames and call Buffer to Queue.vi

wait
wait
dequeue data frames from queue A and write to Global Variable.vi
insert data frames to a queue A

while number of data frames < 180.000
Figure 3.6: Block diagram of one of the server simulation programs
time dierence 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 dierent sources has the same time stamp.
22
CLIENT.vi
find Global Variable.vi
check if any data is in string1 AND string2 of Global Variable.vi
no data
data OK
get data frames from Global Variable.vi
call Buffer to Queue.vi
string1 to queue SQ1 string2 to queue SQ2

Compare and Monitor.vi
SQ1
SQ2 review cluster queues and synchronize data if necessary
wait
dequeue data frames, extract data from data frames into cluster and enqueue to cluster queues CQ1 and CQ2
CQ1 and CQ2 in sync
dequeue clusters and monitor data
CQ1
CQ2
wait
CQ1 to chart
CQ2
optional: run Compare and Monitor.vi

while stop = false
while stop = false
Figure 3.7: Block diagram of the client simulation program
3.2 Simulation
23
3.2.3
3.2.3.1
Simulation Results
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 dierence 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 dierence 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 nd 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 LabVIEW R 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 bookkeeping 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, ll 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.
24 3.2.3.2
Design and Construction 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 dierent. 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.
SERVER.vi run String to Buffer.vi
to sub LOOP
get string from Binary to String.vi
to main LOOP
convert bin file with 1 hour measurement data to a string

TOL = 20 ms
TOL = nx20 ms
divide string into data frames and insert data frames into array with shift registers
wait FALSE if i % n = 0 TRUE
wait
dequeue array of data frames from queue A and write to Global Variable.vi
while stop = false
for i = (1:180.000)
insert array of data frames into a queue A and clear array
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. Its main loop TOL increases to nx20 ms as the TOL of the servers 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 modication.
3.2.3.3
Simulation of the Modied Simulation Programs
The modications done on the simulation programs proved to be very successful in the simulation process. The choice was to transfer an array of ve 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 LabVIEW R were tested in the simulation process. Following is the summation of these options where the rst three are all possible solutions of a buer system between the main client program and the monitor programs.
26
3.3.1
Global Queues
The use of global queues was the rst option tried in the simulation process. First the data frame is read from the Global Variable VI and then buered 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.
Client Global Queue data data Monitor
Figure 3.9: Block diagram of two VIs accessing the same global queue In the simulation process this did not seem to cause any conicts and the data was enqueued and dequeued at the same time without any problems.
3.3.2
Double Buer System
Although using a single shared global queue did not seem to cause any conicts, the implementation of a double queue was also simulated. This method is common amongst programmers where the idea is to avoid any conicts 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.
Client data data Global Queues Monitor
Figure 3.10: Block diagram of two VIs accessing a double global queue At rst this method does not seem to be much more complicated than using only one buer comparing Figs. 3.9 and 3.10. However from the programmers point of view this method is very dicult to implement. The reason for this complexity is that it is necessary to control when each VI
3.3 Synchronization
27
accesses the queues, when the queues should be ushed, 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 buer 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 different 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 notiers 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 notiers. LabVIEW R oers the possibility of using shared variables in cases like this. The shared variables have built in buer system so that the designer does not have to buer the data specially. However the designer has no control over these variables like reviewing the data without removing it from the buer or getting the status of the buer. 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 LabVIEW R 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.
28
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 dened in [9]. Table 3.1 describes what the synchronization algorithm 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 dier 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.
3.3 Synchronization
29
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 while FRAC1 != SOC frac 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.
30
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 while FRAC2 != SOC frac dequeue queue 2 else while FRAC1 != SOC frac dequeue queue 1
3.4
Loop Timing
The time interval between measurements is only 20 ms, thus it is very important 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 clients and both of the servers loops should take exactly nx20 ms of execution time to prevent any possible data loss. To ensure correct execution time LabVIEW R oers 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 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].
i i+1
31
synchronize data
dequeue dequeue Q1 Q2
print to screen
WAIT
dequeue dequeue Q1 Q2
print to screen
WAIT
20 ms
20 ms
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 operations 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 dicult 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 LabVIEW R oers possible solutions to this problem with the LabVIEW Database Connectivity Toolset. The LabVIEW Database Connec-
32
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 dierent standards that use dierent 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 Microsoft R ODBC Data Source Administrator where drivers can be registered and congured to be available as data sources for the application to be used (Microsoft R Access in this case). The ODBC driver selected here was the Microsoft R Access Driver. Next a universal data link (UDL) has to be created. The UDL contains information about what OLE DB provider is used (Microsoft R 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 le 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 le, which comes with the toolset, can be renamed and modied 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 les (mdb les). 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 le size is 2 Gb. However, because your database can include linked tables in other les, 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 le 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 le 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 measurement. 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 nd 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 converted to the same format, the single precision [32 bit real ( 6 digit precision)]. Another problem arose as the phasors are complex numbers and there is no simple method available for computing the average value of a complex
34
Table 3.4: The data that was chosen to be extracted from the IEEE string at the DTU PMUs
SOC SOC time stamp dened in table 2.1 converted from unsigned 32b to date/time format Extracted from PHASOR 1 in single precision format Extracted from PHASOR 1 in single precision format Extracted from PHASOR 2 in single precision format Extracted from PHASOR 2 in single precision format Scaled from FREQ dened in table 2.2 in single precision format
Voltage Magnitude Voltage Angle
Current Magnitude Current Angle
Frequency
number. The decision was to take the root-mean-square (rms) value of the magnitudes, dened by (3.1).
1 Xrms = 2
2 2 2 X0 + X1 + ...X49
(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 angles. 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
380
mean value = 360
340 0 Time [s] 1
Figure 3.12: Denition 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
Dge er s e
36
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 dierent PMU stations. Finally the database demands for the project were addressed.
38
Chapter
4 Electrical Data Analysis
One of the main objective of this project was to create a client-server program 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 electrical 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 Dierence
Amongst several measurements performed by the PMU is the phase angle measurement as the phase angle is always a part of the phasor dened in chapter 2.1.3. The voltage (V) and current (I) phasors are dened in (4.1) and (4.2) along with their phase angles and respectively. (4.1) V = (Vm / 2)ej j I = (Im / 2)e (4.2) In (4.1) and (4.2) Vm and Im represent the voltage and current magnitudes respectively. The client program developed oers the possibility of moni-
40
Electrical Data Analysis
toring the voltage phase angle dierence between two stations. It is also possible to monitor the voltage and current(s) phase angle dierence at a single PMU station. The dierence, , indicates the changes in the load observed by the PMU. As the client program can receive data from two PMU stations simultaneously it is possible to compare measurements from both stations on-line. Although the voltage magnitude and frequency of the stations can be compared on-line then the voltage phase angle dierence between the stations is of most importance. This is because of the relationship between the voltage phase angle dierence and the complex power delivered by a transmission line. To demonstrate this relationship it is possible to consider a lossless transmission 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 jC Y = 2 2
where is the line length. The complex power (S2 ) delivered to PMU station 2 is given by (4.3).
S2 = V2 ej2
jC 2 j22 V1 ej1 V2 ej2 V2 e + jX 2 jC 2 j22 jV1 V2 ej2 j1 jV22 ej22 + V2 e = X 2
(4.3)
From (4.3) the real power delivered can be calculated as follows: V1 V2 sin(1 2 ) V22 sin(22 ) Cl 2 V sin(22 ) X 2 2
P2 = (S2 ) =
4.1 Phase Angle Dierence Also if (1 = ) and (2 = 0) then P2 is given by (4.4).
41
P2 =
V1 V2 sin() X
Z
(4.4)
PMU 1 V 1 = V 1 ejd1 Y/2 Y/2
PMU 2
2 V 2 = V2 ej d
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 dierence and thus it can be very interesting to monitor the phase angle dierence 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 sinh() Z = Z and the shunt admittance is Y tanh(/2) Y = 2 2 /2 where = S
zy
m1
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 transmission line) gives the most meaningful results. Thus adding more stations is unnecessary and can only complicate things.
42
4.2
Power Calculations
The previous section demonstrates that the power absorbed by the load is dependant on the phase angle dierence. Relating to that it can be interesting to monitor the real and reactive power in relation to the phase angle dierence. 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 + ) v(t) = Vm cos(t + ) A V (4.5) (4.6)
Then the instantaneous power absorbed by the load is
p(t) = v(t)i(t) = Vm Im 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 = Vrms Irms cos ( ) W Var (4.8) (4.9)
Q = V IX = Vrms Irms sin ( )
The client program oers the possibility of monitoring P and Q from station A along with the phase angle dierence 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.
44
Chapter
5 Program Architecture
The greater part of the work in this project was to develop the client-server program in LabVIEW R . 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 program manual describing the user interface of the program, the hierarchy of the programs, block diagrams, ow 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 simplied overview of the client-server program, set up at DTU. What Fig. 5.1 shows is the two dierent 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 IPaddress to access the Global Variable VI and the client also needs to specify an IPaddress 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
PMU 1
SERVER VI
Array Queue Array Queue
PMU 2
SERVER VI
global variable IEEEarray VI
global IEEEarray variable VI
Array Queue
Array Queue
Cluster Queue
Cluster Queue
PC
Database CLIENT VI
Synchronize and Monitor
Cluster Queue
Cluster Queue
Figure 5.1: Overview of the client-server program, set up at DTU
ered.
The connection between the client and the server must be veried. This can be done with the LabVIEW R VIs Set and Get available from www.ni.com. The PMUs LabVIEW R VIs must be running. Paths locating the Global Variable VIs must be accurate in both the Server.vi and the Client.vi IPaddresses of the servers and the client must be veried. 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 modied PMU COMMON.vi in Fig. 5.2 is the interface on the screen at the DTU PMU when it is running. The modications 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 IPaddress eld.
Figure 5.2: The front panel of the modied 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 specied by the IPaddress eld. If the IPaddress eld 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 dierence or time delay specied with the PhaseDi and Delay elds respectively. The LEDs, 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.
48
5.1.2
The Client Manual
The client interface was designed in such a way that the user does not have to think about IPaddresses, 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 eld. 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 veried. 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 dierence between station 1 and 2. The lower graph then shows the voltage magnitude and the frequency of station 1. The View menu also oers two other options, CAM (short for compare and monitor) and PhDi. By selecting the CAM option a similar VI as depicted in 5.4 pops up. This VI oers 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 dierences from PMU stations 1 and 2.
50
5.2
The Hierarchy
Figs. 5.5, 5.6 and C.1 illustrate the hierarchies of the programs developed during this project. In these gures the double lined boxes include the main VIs, normal lined boxes include sub VIs and VIs called by the main VIs, dotdashed 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.
Other PMU VIs
PMU_COMMON.vi
Global_Data.vi PMU_SERIAL.vi SERVER BuffArray.vi NEWConverData.vi 1 ConvertManip.vi NEWIEEE_CRC.vi SERVER.vi 2nd Server.vi 2
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 modied 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 gures 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

Global_info.vi
51
CLIENT.vi
ArraytoClusters.vi
GetInitTime.vi
ChkandBuff.vi
DBandCAMbuff.vi CRC_Chk.vi
VIEW
DATABASE
DatatoBuffer.vi
CAM.vi
PhDiff.vi
PQ_Mon.vi
No DB
WritetoDB.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 LabVIEW R 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 ow 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 attened string as in Fig. 3.3. By doing this, using the Flatten to String VI is avoided as it is only available in LabVIEW R 7.x. LabVIEW R 8.0 (used in this project) has a Flatten to String VI but that VI does not oer the output type string that is necessary when transferring
52
SERVER Initialize the VI
while no error or stop = false
SHIFT 1
Case:0 Is there any data in array Queue IEEEQ yes no
wait
Connect to the Global Variable VI SHIFT = 1 Case:1 Extract data from IEEEQ and write to Global Variable VI TOL = nx20 ms Restore variables and terminate the VI
Figure 5.7: The ow chart of the server VI
attened data using the Invoke Node VI.
NEWConvertData.vi and NEWIEEE CRC.vi NEWConvertData.vi and NEWIEEE CRC.vi are newer versions of ConverData.vi and IEEE CRC.vi from the original PMU software. The NEWConvertData.vi converts the measurement data to a data frame dened in the new IEEE standard [9] instead of a data frame dened 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 dened in appendix B of the new IEEE standard [9].
53
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 modied 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 modied in such a way that the measurement data, streaming from the MS-DOS R computer, is converted to a data frame, inserted into an array and buered to a queue (IEEEQ) when the array includes n number of data frames. Each time the array is enqueued its elements are removed.
54
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 dierent PMU stations, from the Global Variable VIs. Fig. 5.10 illustrates the ow of the client.vi and Fig. 5.9 shows the programs 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 loops purpose, in Fig. 5.9, is only to retrieve data, extract data

CLIENT 0.0 0.1 0.2 1.0 while stop = false 0 Case:0 Retrieve data from both Global Variable VIs Get initial time with GetInitTime.vi Perform CRC on array1 and buffer array1 to IEEEQ1 if array1 has reached initial time Perform CRC on array2 and buffer array2 to IEEEQ2 if array2 has reached initial time WAIT until next nx20 ms multiple Queues created Establish connection to both Global Variable VIs Check for data in both Global Variable VIs
55
RUNI PA L N RAL EL
Both arrays reached initial time ? no Case:1 1 Perform CRC on array1 and buffer array1 to IEEEQ1 Perform CRC on array2 and buffer array2 to IEEEQ2 yes Case:2.0 Are there any elements in IEEEQ1 and IEEEQ2 no yes
Case:2.1 0 1 2 goto Case:1 next Dequeue IEEEQ1 -> DBandCAMbuff.vi DBandCAMbuff.vi -> CAM1 and DBQ1 Dequeue IEEEQ2 -> DBandCAMbuff.vi DBandCAMbuff.vi -> CAM2 and DBQ2 WAIT until next nx20 ms multiple
goto Case:2.1 next
TOL = nx20 ms
while stop = false
Promt user to run: Promt user to save data to database
A: CAM.vi B: PhDiff.vi C: PQmon.vi
2.0
Destroy Queues, Abort Vis, EXIT
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
56
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).
INPUT OUTPUT
Queue in Queue size Array in Station ID
ChkandBuff.vi
msg
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 clusters 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 monitored, controlled by the PMU ID (Station ID) input. For the PMU stations
57
located at DTU the cluster would have the same information as listed in table 3.4.
INPUT OUTPUT
CAM Queue in DB Queue in Array in Station ID SOC
ArraytoClusters.vi
#MON
Figure 5.12: Inputs and Output of the ArraytoClusters.vi
CAM.vi, PhDi.vi and PQmon.vi
while stop = false
Case:0 Are there any elements in CAM1 and CAM2 yes Case:1 Synchronization algorithm Case:2 0 WAIT until next 20 ms multiple Dequeue CAM1 and CAM2 Extract Data Print Data to Chart Is Data out of sync? yes no no
Figure 5.13: The ow chart of the monitor VIs These three VIs all have the same structure and their common ow chart is depicted in Fig. 5.13. The only part that dierentiates 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
58
magnitude, current phase angle or the frequency of the PMU stations being monitored. The PhDi.vi calculates the dierence 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 dierence 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 Dequeue DBQ1 while DBQ1(SOC) != InitTime Dequeue DBQ2 while DBQ2(SOC) != InitTime 0.2 Get PMU IDs from both stations, set day and year Open connection to DB Generate table names check if tables exist create tables if they dont exist with TableOperations.vi
0.1
0.3 0.4
1 while exit = false 1.0 1.1 Wait until next 20ms multiple check day and year to decide whether to create and/or drop tables with DayTable.vi Dequeue DBQ1 and DBQ2 and insert data to DB
1.2
2 close connection to DB
Figure 5.14: The ow chart of the WritetoDB.vi In chapter 3.5.2 it is roughly estimated that a single mdb le could store up to 10 days of data from a PMU station. Here the demand is that the mdb
59
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.
INPUT OUTPUT
Option Day of year SOC Table in 1 Table in 2 Table out 1
DayTable.vi
Table out 2
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.
INPUT
Option
TableOperations.vi
Table name
Figure 5.16: Inputs of the TableOperations.vi
60
5.4
Summary
This chapter includes the programs manual, describing the procedure when running then client-server program. It also describes and illustrates the programs 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 LabVIEW R software was chosen for the job, both because the PMU software was programmed in it and also because it oers 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 Variable method was chosen, mainly because of a delay problem in the TCP/IP method. A database interface was also designed in LabVIEW R to store the data at the client for the possibility of further data analysis. The Microsoft R 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 occasionally. 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 nal 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 nal version did run without any major faults, the program will also run ne over the network.
6.2
Further Work
The Global Variable method has at least one aw which is the possibility of data loss. The reason for this possibility is because there is no buer 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 LavVIEWs R 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 (rst in rst out) buer system [6]. The resulting program is not entirely nished 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 aect the
6.3 The Broader Perspective
63
timing- and the synchronization process. Changing the database provider should also be considered as the Microsoft R Access database is rather limited.
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 clientserver program as developed in this project could be used to further enhance those studies and widen the range of the DTU PMU possibilities.
64
Conclusion
Appendix
A The DTU PMU LabVIEW Program Overview
PMU COMMON.vi The PMU COMMON.vi whose owchart 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 buers are created and initialized. Network and serial connections are veried. But most importantly this VI controls all communications with the MS-DOS R computer and prepares for receiving the package sent from that computer.
PMU_DTU1
PMU_COMMON Y Case:0 Error N 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 Initialize global variables: DataQueue, DataSmf 0.4.1 Run PMU_IEEE.vi 0.5 Initialize global variables: MonitorHistory, MonitorQueue, DebugQueue Case:4 CreateTele.vi Error? No: CheckProto.vi Case:5 Yes: ErrorMain Case:0 Case:5 StopCmd.vi F T DosBoot.vi OK Y F T N F T Close references to MonitorDTU1.vi SetPCTime.vi Debug.vi Case:10 NetConnect.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 Case:20 Prepairing package receiving If ErrorDisk then write to Message.vi and goto case 1*** 1.4 Clear ErrorMain, ErrorProto and ErrorDisk Case:2 EstablishSerial Connection.vi Case:22 Run MonitorDTU1.vi, or Debug.vi or SetPCTime.vi or none of these three 1.0 StopProto StopDisk Wait 1s Opens Com with ComOpen.vi F T State: 0 Case:1 Case:21 Check if global variables: GPS_Running AND DATA2DISK_Running F T State: 1 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
Case:3 Send command with SendCmd.vi which creates telegraph with CreateTele.vi
Case:11 30x NetConnect.vi F Y Case:12 SetdosZ.bat Error N DosBoot.vi T
40x
Case:17 EstablishSerial Connection.vi F T T Case:18 Case:14 Send command with SendCmd.vi which creates telegraph with CreateTele.vi F T Wait 1s 20 times F 40x Case:13 NetConnect.vi
* 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 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 return 21 to state:0.1 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 return 23 to state:0.1 else ParseData.vi (string packet into array packet) If ParseData not OK return 24 to state:0.1 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 return -6 to state:0.1 else If #packet != Old_packet+1 return -5 to state:0.1 else return 0 to state:0.1 0.0.3 UTC to UTC_Old #packet to Old_packet 0.0.4 Data2Buffer.vi State: 1 If ExitAll = StopProto = False Check ErrorProto initialize ErrorProto goto state:0
0.1 If number from state:0.0 < 0 flush buffer else next package
Figure A.2: The owchart for the DTU PMU serial program The PMU Serial.vi reads the packet sent through COM port from the MSDOS R computer. Checks the package for errors and then buers the data
68 from the packet.
The DTU PMU LabVIEW Program Overview
PMU IEEE.vi
PMU_IEEE State: 0 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 Write to BIN file if error ErrorDisk=4 goto case:0 else goto case:1.2 1.2 0.0 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 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 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 State: 1
Figure A.3: The owchart 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 dened by IEEE standard. Then it stores one hour of data, as zipped binary les.
Appendix
B Packet Description
Here is the packet description of the packet sent from the MS-DOS R computer of the PMU to the Windows R computer. The packet is sent through a COM port as the network operations of the MS-DOS R computer are disabled. 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 LabVIEW R data format.
70
Packet Description
Table B.1: MS-DOS R to Windows R 2000 (LabVIEW R ) Packet

Byte no. 0 1 2 3 4 5 6 10 14 18 22 26 30 34 38 42 46 50 54 58 62 66 70 74 78 82 83 C++ type unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned oat oat oat oat oat oat oat oat oat oat oat oat oat oat oat unsigned unsigned char char char char char char long long long long C++ name st1 st2 year month day hour packet utcsec stat0 stat1 frq dfrq ampl0 angl0 ampl1 angl1 ampl2 angl2 ampl3 angl3 ampl4 angl4 debug0 debug1 idata index bcc Description 0x81 0x81 Year Month Day Hour Number of packet within the hour UTC seconds since 1-1-1900 Status 0 Status 1 Frequency df/dt Voltage, amplitude [kV] Voltage, phase [ ] Current 0, amplitude [kA] Current 0, phase [ ] Current 1, amplitude [kA] Current 1, phase [ ] Current 2, amplitude [kA] Current 2, phase [ ] Current 3, amplitude [kA] Current 3, phase [ ] Debug data 0 Debug data 1 Indexed data Index for indexed data Checksum
char char
71 Status 0 The stat0 variable is described further in table B.2. Table B.2: The stat0 variable
Bit no. 0-3 4* 5* 6* 7* 8 9-11 12 13 14 15 16 17-31 Description GPS Tracking Status, should be 13 (0xd) for valid timing Positive leap second scheduled Negative leap second scheduled A/D overow UTC synchronization suspicious UTC time is available Undened Leap second pending asserted by GPS control segment Leap pending: set 24 hours before, until beginning of leap second GPS leap warning: 6 hours before, until 6 hours after leap event Leap in progress. Only set during the leap second Packets lost, set in rst 20 ms packet after the lost packets 0
Bits 8-15 are the leap second ags from the latest received GPS Primary NTP Event Packet. This means that they are delayed by the time for serial data transmission from GPS to the DOS PC. * Means that status bit is not yet implemented.
Status 1
Table B.3: The stat1 variable

Bit no. 0-31 Description 0
72 Index + Indexed Data
Packet Description
Indexed data carry the data specied in the index byte according to the following table. Index is incremented by one each 20 ms (every new packet). Index is in the range 0 to 49. This means that indexed data is renewed each second and can be up to 1 second old. Table B.4: Indexed data description
Bit no. 0 1 2 3 4 5 6 7 8 9 10-17 18-49 Indexed data description PMU - 0: HVE400, 1: HVE132, 2: RAD132, 3: ASV400, 4: DTU Wincom error counter Wincom timeout counter Free buer - 0: DOS packet buer full, 500: DOS packet buer empty Event packet counter Event packet error counter Event packet request timeout counter Comprehensive Timing Packet counter Comprehensive Timing Packet error counter GPS receiver mode - shall be 6 for Over determined Clock Satellite number - Negative: no contact, Positive: contact 0
Debug 0 Av time error [s]
Debug 1 Time error [s]
Appendix
C Additional Database VIs
At rst it was assumed that the High-Level database VIs of the LabVIEW R Database Connectivity Toolset could not handle writing data to a database every twenty millisecond. Because of this several VIs were developed in order to calculate the mean value of the data to be stored and write the results to a database at a one second interval. This appendix documents these VIs.
74
Additional Database VIs
C.1
The Hierarchy of the Additional Database VIs
The Hierarchy of the Additional Database VIs is illustrated in the block diagram of Fig. C.1.
Global_info.vi
Save_to_DB.vi
MeanCnt.vi
DatatoDB.vi
1 MeanCalc.vi
Database Toolkit High-Level vis
Figure C.1: The hierarchy of the Save to DB.vi and its sub VIs
C.2 Description of the Additional Database VIs
75
C.2
Description of the Additional Database VIs
SavetoDB.vi Fig. C.2 shows the ow of this VI. When the user chooses to save the data to a database this VI is run separately from the client VI.
SAVE TO DB 0.0 Set InitTime equal to max(DBQ1(SOC),DBQ2(SOC))+1 Dequeue DBQ1 while DBQ1(SOC) != InitTime Dequeue DBQ2 while DBQ2(SOC) != InitTime 1 while exit = false Dequeue DBQ1 and DBQ2 DBQ1(DataArray) -> MeanCnt.vi DBQ2(DataArray) -> MeanCnt.vi MeanCnt.vi(Cnt) = 0? no yes Clusters of 1s average value of data to DB AvgCluster1 -> DatatoDB1.vi AvgCluster2 -> DatatoDB2.vi
0.1
Figure C.2: The ow chart of the SavetoDB.vi
76 MeanCnt.vi
Additional Database VIs
This VI controls the amount of time the average value is calculated over.
INPUT OUTPUT
Data Array 1
Avg Array 1
MeanCnt.vi
Data Array 2
Cnt Avg Array 2
Figure C.3: Inputs and Outputs of the MeanCnt.vi
MeanCalc.vi This VI calculates the average values of the phasors as described with (3.1) for the magnitude and in table 3.5 for the phase angle.
INPUT OUTPUT
Data Array
MeanCalc.vi
Shift Array
Shift Array
Figure C.4: Inputs and Output of the MeanCalc.vi
DatatoDB.vi The inputs of the DatatoDB.vi are as in Fig. C.5. The basic structure of this VI is as illustrated in 3.13 where connection to the database is opened, then the data is inserted and nally the connection is closed.
INPUT
Data Cluster
DatatoDB.vi
Table name
Figure C.5: Inputs of the DatatoDB.vi
Appendix
Functional Global Variables
The possibility of a data loss occurrence using the Global Variable method is discussed in chapter 3.1.3. The reason for this possibility is because there is no buer 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. On the other hand if the client is too fast it can retrieve the same data twice. A possible solution to this problem might be to implement a functional global variable (FGV) as a buer between the client and the server. Following are some denitions and descriptions of a FGV from [4]. A global variable is a shared resource. If one piece of code accesses a global variable, no other piece of code can access the global variable until the rst piece releases the global variable. When you block the access of a time-critical VI to a global variable, forcing the time-critical VI to wait, you introduce jitter to the application and compromise the determinism of the application. You can avoid this behavior by using a Functional Global (Variable). With a Functional Global, the time-critical VI does not have to access the global if another section of code is already using the
78
Functional Global Variables global. You avoid the delays caused by accessing standard global variables.
A Functional Global, also called a LabVIEW 2-Style Global, is a VI that uses a loop with uninitialized shift registers to hold global data.
D.1
Block Diagram
Fig. D.1 shows a possible block diagram of a FGV that could be used to transfer array of IEEE formatted strings between the client and the server.
Figure D.1: Possible block diagram of a FGV In Fig. D.1 the server would write the data into the variable called StringIn1 and the client would read the data from the variable StringOut1. The index variable is a control variable that has to be controlled by the client to index the array generated by the loop and the shift registers. This however could result in a build-up of a huge array thus a great memory usage. To deal with that, some sort of a delete function must be implemented. When this method is used the server must run the FGV using a Invoke Node VI after it has written the data into the control variable (StringIn1) also using the Invoke Node VI as described in chapter 3.1.2. This means that both the server and the client have to add an extra Invoke Node operation in their main loops resulting in a higher run time.
Appendix
E The Program CD
This appendix includes the programs developed in this project on a CD. The CD includes the simulation programs developed (in CSSIM folder), both with the normal Global Variable method and the modied Global Variable method where arrays are transferred instead of strings. Similarly the CD includes the network programs (in CSPRG folder), also with the normal and modied Global Variable method.
80
The Program CD
The Program CD
Bibliography
[1] Power System Analysis and Design. Brooks/Cole, third edition, 2002. [2] A.G.Phadke and K.Martin. Ieee standard for synchrophasors for power systems. Standard ISBN 1-55937-693-7, The Institute of Electrical and Electronics Engineers, Inc., 1996. [3] National Instruments Corporation. Call by reference node. http://zone.ni.com/reference/en-XX/help/371361B01/glang/call by reference node/. [4] National Instruments Corporation. Improving determinism with functional globals, labview 2-style globals, in labview real-time. http://zone.ni.com/devzone/cda/tut/p/id/4338. [5] National Instruments Corporation. Software timed loops using wait (ms) and wait until next ms multiple. http://zone.ni.com/devzone/cda/tut/p/id/4120. [6] National Instruments Corporation. Using the labview shared variable. http://zone.ni.com/devzone/cda/tut/p/id/4679. [7] K.Martin R.Wilson C.Taylor, D.Erickson and V.Venkatasubramanian. Wacs:wide-area stability and voltage control system:r&d and online demonstration. Paper 10.1109/JPROC.2005.846338, Washington State University, 2003. [8] Joe Geluso. Crc16-ccitt. http://www.joegeluso.com/software/articles/ccitt.htm. [9] K.Martin and D.Hamai. Ieee standard for synchrophasors for power systems. Standard ISBN 0-7381-4821-0 SS95382, The Institute of Electrical and Electronics Engineers, Inc., 2006.
82
BIBLIOGRAPHY
[10] National Instruments Corporation. Database Connectivity Toolset User Manual, May 2001.
www.oersted.dtu.dk
rsted DTU Center for Electric Technology Technical University of Denmark Elektrovej Building 325 DK-2800 Kongens Lyngby Denmark Tel: (+45) 45 25 35 00 Fax: (+45) 45 88 61 11 E-mail: cet@oersted.dtu.dk

Aml Thesis

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Aml Thesis

Загружено:

Авторское право:

Доступные форматы

Arnar Mr Loftsson a

On-Line Presentation of Data from PMU Stations

M.Sc. Thesis, October 2006

On-Line Presentation of Data from PMU Stations

M.Sc. Thesis, October 2006

On-Line Presentation of Data from PMU Stations

Publication Date Class Edition Notes

Lyngby, October 2006 Arnar Mr Loftsson a

CONTENTS Range of Work . . . . . . . . . . . . . . . . . . . . . . . . . . 3

A The DTU PMU LabVIEW Program Overview

C.2 Description of the Additional Database VIs . . . . . . . . . .

CONTENTS D Functional Global Variables D.1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5

Data frame organization I . . . . . . . . . . . . . . . . . . . . Data frame organization II . . . . . . . . . . . . . . . . . . .

B.1 MS-DOS R to Windows R Packet

1.4 Limitations and Requirements

Limitations and Requirements

4 simulation process, synchronization, and database operations.

The Phasor Measurement Unit

Description of the PMU

The DTU PMU

The Phasor Measurement Unit

2.1 Description of the PMU

The Phasor Measurement Unit

Standards for Synchrophasors for Power Systems

The 1995 Standard

2.2 Standards for Synchrophasors for Power Systems

The 2005 Standard

FRAMESIZE IDCODE SOC FRACSEC CHK

The Phasor Measurement Unit

Table 2.2: Data frame organization of the 2005 standard

2.3 The Cyclic Redundancy Check

The Cyclic Redundancy Check

The Phasor Measurement Unit

The CRC of the DTU PMU

2.3 The Cyclic Redundancy Check

The Phasor Measurement Unit

3 Design and Construction

Client-Server Programming Methods

Design and Construction

The TCP/IP Method

3.1 Client-Server Programming Methods

The Global Variable Method

Design and Construction

TCP/IP Compared to Global Variable

3.1 Client-Server Programming Methods

Design and Construction

The Server Simulation Program

The Client Simulation Program

SERVER.vi run String to Buffer.vi

get string from Binary to String.vi

convert bin file with 1 hour measurement data to a string

while stop = false

divide string into data frames and call Buffer to Queue.vi

dequeue data frames from queue A and write to Global Variable.vi

insert data frames to a queue A

Figure 3.6: Block diagram of one of the server simulation programs

Design and Construction

find Global Variable.vi

check if any data is in string1 AND string2 of Global Variable.vi

get data frames from Global Variable.vi

call Buffer to Queue.vi

string1 to queue SQ1 string2 to queue SQ2