aml thesis

8/6/2019 Aml Thesis

1/105

Arnar Mar Loftsson

On-Line Presentation of Datafrom PMU Stations

M.Sc. Thesis, October 2006

8/6/2019 Aml Thesis

2/105

8/6/2019 Aml Thesis

3/105

Arnar Mar Loftsson

On-Line Presentation of Datafrom PMU Stations

M.Sc. Thesis, October 2006

8/6/2019 Aml Thesis

4/105

8/6/2019 Aml Thesis

5/105

Preface

This thesis was prepared at Center for Electric Technology (CET), the Tech-nical University of Denmark in partial fulfillment of the requirements foracquiring the M.Sc. degree in engineering.

The objective of this thesis is to shed some light on the possibilities of mon-itoring electrical measurement data over a network. The data is generatedby a device called a Phasor Measurement Unit (PMU).

The thesis consists of the work done at rsted DTU, while developing aclient-server program. The work took place in the eight month period of

March to October 2006.

Lyngby, October 2006

Arnar Mar Loftsson

8/6/2019 Aml Thesis

6/105

ii

8/6/2019 Aml Thesis

7/105

Abstract

The following thesis describes the development process of designing andimplementing a client-server program. The main purpose of the program isto remotely present on-line measurement data from PMU stations, developedat DTU. The data presented is also to be stored in a database on a temporarybasis.

The LabVIEWR software from National Instruments Corporation was usedto develop the client-server program as well as the database interface usingthe LabVIEWR Database Toolset. The project was twofold: At one handthe implementation of a server program to interact with existing PMU soft-

ware. On the other hand the design of a client capable of receiving datafrom two stations simultaneously, monitor it and store it.

The method chosen to communicate between the client and the server, wasthe Global Variable method. The server writes several measurements in anarray to a Global Variable where the client can read them and monitor themone by one. The Global Variable can be placed either at the server or at theclient.

8/6/2019 Aml Thesis

8/105

iv

8/6/2019 Aml Thesis

9/105

Contents

Preface i

Abstract iii

List of Figures ix

List of Tables xiii

List of Symbols xvii

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Problem Description . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Limitations and Requirements . . . . . . . . . . . . . . . . . . 3

1.5 Work of Others . . . . . . . . . . . . . . . . . . . . . . . . . . 3

8/6/2019 Aml Thesis

10/105

vi CONTENTS

1.6 Range of Work . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 The Phasor Measurement Unit 5

2.1 Description of the PMU . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 The DTU PMU . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Satellite system . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3 The Phasors . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4 Data Transmission . . . . . . . . . . . . . . . . . . . . 7

2.2 Standards for Synchrophasors for Power Systems . . . . . . . 8

2.2.1 The 1995 Standard . . . . . . . . . . . . . . . . . . . . 8

2.2.2 The 2005 Standard . . . . . . . . . . . . . . . . . . . . 9

2.3 The Cyclic Redundancy Check . . . . . . . . . . . . . . . . . 11

2.3.1 CRC in general . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2 The CRC of the DTU PMU . . . . . . . . . . . . . . . 12

2.3.3 CRC Discussion . . . . . . . . . . . . . . . . . . . . . 13

2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Design and Construction 15

3.1 Client-Server Programming Methods . . . . . . . . . . . . . . 15

3.1.1 The TCP/IP Method . . . . . . . . . . . . . . . . . . 16

3.1.2 The Global Variable Method . . . . . . . . . . . . . . 17

3.1.3 TCP/IP Compared to Global Variable . . . . . . . . . 18

8/6/2019 Aml Thesis

11/105

CONTENTS vii

3.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 The Server Simulation Program . . . . . . . . . . . . . 20

3.2.2 The Client Simulation Program . . . . . . . . . . . . . 20

3.2.3 Simulation Results . . . . . . . . . . . . . . . . . . . . 23

3.3 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.1 Global Queues . . . . . . . . . . . . . . . . . . . . . . 26

3.3.2 Double Buffer System . . . . . . . . . . . . . . . . . . 26

3.3.3 Shared Variables . . . . . . . . . . . . . . . . . . . . . 27

3.3.4 Timed Structures . . . . . . . . . . . . . . . . . . . . . 27

3.3.5 Initial Synchronization . . . . . . . . . . . . . . . . . . 28

3.3.6 The Synchronization Check . . . . . . . . . . . . . . . 28

3.4 Loop Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5.1 Database Setup . . . . . . . . . . . . . . . . . . . . . . 32

3.5.2 Database Limitations . . . . . . . . . . . . . . . . . . 32

3.5.3 The Data Storage . . . . . . . . . . . . . . . . . . . . 33

3.5.4 Improved Database VIs . . . . . . . . . . . . . . . . . 35

3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Electrical Data Analysis 39

4.1 Phase Angle Difference . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Power Calculations . . . . . . . . . . . . . . . . . . . . . . . . 42

8/6/2019 Aml Thesis

12/105

viii CONTENTS

4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Program Architecture 45

5.1 The Program Manual . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1 The Server Manual . . . . . . . . . . . . . . . . . . . . 47

5.1.2 The Client Manual . . . . . . . . . . . . . . . . . . . . 48

5.2 The Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3 Description of the VIs . . . . . . . . . . . . . . . . . . . . . . 50

5.3.1 The Server VIs . . . . . . . . . . . . . . . . . . . . . . 51

5.3.2 The Client VIs . . . . . . . . . . . . . . . . . . . . . . 54

5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6 Conclusion 61

6.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.2 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.3 The Broader Perspective . . . . . . . . . . . . . . . . . . . . . 63

A The DTU PMU LabVIEW Program Overview 65

B Packet Description 69

C Additional Database VIs 73

C.1 The Hierarchy of the Additional Database VIs . . . . . . . . 74

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

8/6/2019 Aml Thesis

13/105

CONTENTS ix

D Functional Global Variables 77

D.1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 78

E The Program CD 79

Bibliography 81

8/6/2019 Aml Thesis

14/105

x CONTENTS

8/6/2019 Aml Thesis

15/105

List of Figures

2.1 Data frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 Simple TCP/IP server . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Simple TCP/IP client . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Simple Global Variable server . . . . . . . . . . . . . . . . . . 17

3.4 Simple Global Variable client . . . . . . . . . . . . . . . . . . 17

3.5 Configuration of PMUs and client . . . . . . . . . . . . . . . . 19

3.6 The server simulation block diagram . . . . . . . . . . . . . . 21

3.7 The client simulation block diagram . . . . . . . . . . . . . . 22

3.8 The array server block diagram . . . . . . . . . . . . . . . . 24

3.9 Single global queue . . . . . . . . . . . . . . . . . . . . . . . . 26

3.10 Double global queue . . . . . . . . . . . . . . . . . . . . . . . 26

3.11 Loop timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.12 Angle mean value . . . . . . . . . . . . . . . . . . . . . . . . . 35

8/6/2019 Aml Thesis

16/105

xii LIST OF FIGURES

3.13 Block diagram of DB VIs . . . . . . . . . . . . . . . . . . . . 36

3.14 Improved block diagram of DB VIs . . . . . . . . . . . . . . . 36

4.1 Equivalent circuit . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Overview of the program . . . . . . . . . . . . . . . . . . . . . 46

5.2 Front panel of PMU COMMON.vi . . . . . . . . . . . . . . . 47

5.3 Front panel of Client.vi . . . . . . . . . . . . . . . . . . . . . 48

5.4 Front panel of monitor VI . . . . . . . . . . . . . . . . . . . . 49

5.5 The Server Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 50

5.6 The Client Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 51

5.7 Server flow chart . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.8 Server block diagram . . . . . . . . . . . . . . . . . . . . . . . 53

5.9 Client block diagram . . . . . . . . . . . . . . . . . . . . . . . 54

5.10 Client flow chart . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.11 Inputs and Output of ChkandBuff.vi . . . . . . . . . . . . . . 56

5.12 Inputs and Output of ArraytoClusters.vi . . . . . . . . . . . . 57

5.13 Monitor flow chart . . . . . . . . . . . . . . . . . . . . . . . . 57

5.14 Write to DB flow chart . . . . . . . . . . . . . . . . . . . . . . 58

5.15 Inputs and Outputs of DayTable.vi . . . . . . . . . . . . . . . 59

5.16 Inputs of TableOperations.vi . . . . . . . . . . . . . . . . . . 59

A.1 DTU PMU Flowchart . . . . . . . . . . . . . . . . . . . . . . 66

8/6/2019 Aml Thesis

17/105

LIST OF FIGURES xiii

A.2 DTU PMU Serial flowchart . . . . . . . . . . . . . . . . . . . 67

A.3 DTU PMU Log and IEEE . . . . . . . . . . . . . . . . . . . . 68

C.1 The Database VIs Hierarchy . . . . . . . . . . . . . . . . . . . 74

C.2 Save to DB flow chart . . . . . . . . . . . . . . . . . . . . . . 75

C.3 Inputs and Outputs of MeanCnt.vi . . . . . . . . . . . . . . . 76

C.4 Inputs and Output of MeanCalc.vi . . . . . . . . . . . . . . . 76

C.5 Inputs of DatatoDB.vi . . . . . . . . . . . . . . . . . . . . . . 76

D.1 Block diagram of a FGV . . . . . . . . . . . . . . . . . . . . . 78

8/6/2019 Aml Thesis

18/105

xiv LIST OF FIGURES

8/6/2019 Aml Thesis

19/105

List of Tables

2.1 Data frame organization I . . . . . . . . . . . . . . . . . . . . 9

2.2 Data frame organization II . . . . . . . . . . . . . . . . . . . 10

2.3 CRC Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Synchronization pseudo code I . . . . . . . . . . . . . . . . . 29

3.2 Synchronization pseudo code II . . . . . . . . . . . . . . . . . 29

3.3 Synchronization pseudo code III . . . . . . . . . . . . . . . . 30

3.4 Data extracted from the IEEE string . . . . . . . . . . . . . . 34

3.5 Mean value of angle algorithm . . . . . . . . . . . . . . . . . . 35

B.1 MS-DOSR to WindowsR Packet . . . . . . . . . . . . . . . . 70

B.2 The stat0 variable . . . . . . . . . . . . . . . . . . . . . . . . 71

B.3 The stat1 variable . . . . . . . . . . . . . . . . . . . . . . . . 71

B.4 Indexed data description . . . . . . . . . . . . . . . . . . . . . 72

8/6/2019 Aml Thesis

20/105

xvi LIST OF TABLES

8/6/2019 Aml Thesis

21/105

List of Symbols

Symbol Definition

CRC The Cyclic Redundancy CheckDB DatabaseDTU Technical University of DenmarkFGV Functional Global VariableGPS Global Positioning SystemIEEE Institute of Electrical and Electronics EngineersNI National Instruments

ODBC Open Database ConnectivityPC Personal ComputerPMU Phasor Measurement UnitSOC Second of CenturySQL Structural Query LanguageTCP/IP Transmission Control Protocol/Internet ProtocolTOL Time of LoopUDL Universal Data LinkUTC Universal Time CoordinatedVI Visual InstrumentWACS Wide Area Stability and Voltage Control SystemWAMS Wide Area Measurement System

8/6/2019 Aml Thesis

22/105

xviii

8/6/2019 Aml Thesis

23/105

Chapter 1

Introduction

Increasing technology development and better life standards of the mod-ern society demand more stable, top quality electricity. In meeting thesedemands the high voltage industry has been adding new technology to its

equipment in order to maximize its efficiency. This is often the only optionavailable as it is not always possible to add more power plants or transmis-sion lines especially in populated areas where the need for more power isperhaps the greatest.

One of those new technologies implemented in the modern power systemis the Phasor Measurement Unit (PMU). In general the main purpose ofthe PMU is to synchronize measurements at different locations in the powergrid by using the GPS technology. This technology is called Wide AreaMeasurement System (WAMS).

Development of the PMU is well on its way in several countries, e.g. inUSA they have developed technology called WideArea Stability and Volt-age Control System (WACS), where they can receive and analyze measure-ment data live [7]. An obvious advantage of that is the ability to foreseea fault and thus the capability to take the necessary measures to minimizethe faults effect on the system or even stop the fault from occurring.

8/6/2019 Aml Thesis

24/105

2 Introduction

1.1 Background

In Denmark there are five PMU stations located in Sealand. These stationsmeasure the system frequency and the voltage magnitude and phase angle atthe place where they are located. Some of them also measure currents. Theinformation obtained from these measurements is then sent through networkconnections and stored at DTU. The need for receiving and analyzing thedata on-line is increasing. Therefore the main topic of this thesis was toinvestigate methods for receiving on-line data from PMU stations.

1.2 Problem Description

The technology and the possibilities to upgrade the existing PMUs in Den-mark are available today. Thus will this thesis aim to find methods forsending 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 thisproject 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 stationsat 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 beconsidered as a host or a server that delivers data to a network. At the

8/6/2019 Aml Thesis

25/105

1.4 Limitations and Requirements 3

other end a guest or a client needs to be created in order to receive andanalyze the data generated by one or more PMUs at the same time.

Basic programming methods will be used to overcome this project. At firsta simulation with real, existing data will be developed. Then the programsdeveloped in the simulation process will be adjusted to the actual PMUstations 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. Thenumber of PMU stations, to be worked with and tested, will be limited totwo. Also the server and the client will be on the same network but notremotely connected as would be the case in practice.

Because of these limitations it must be required that the final version of theresulting program will be easily upgradeable so that it can be implementedin practice. The program must also be able to handle all measurementswithout 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 developedat DTU. This software part was written in LabVIEW R by one of this thesisinstructors, Associate Professor, Knud Ole Helgesen Pedersen, rsted-DTU.

1.6 Range of Work

For those still wondering what PMU stations are, then chapter 2 shouldanswer most of their questions. The basic structure of the PMU is describedalong with most of its vital attributes.

Chapter 3 includes the design and construction of the work done in thisproject. Among topics discussed are client-server programming methods,

8/6/2019 Aml Thesis

26/105

4 Introduction

simulation process, synchronization, and database operations.

The electrical data analyzation is discussed in chapter 4 where the methods

used by the program, developed for this project, is accounted for.

The client-server program developed for this project and its architecture isthe topic of chapter 5. It starts with the program manual describing the userinterface of the program. Following the manual is a detailed description ofthe programs developed. This chapter is very illustrative as the programhierarchy, flow charts and block diagrams fill the pages.

Finally the conclusion of the work done can be read in chapter 6.

8/6/2019 Aml Thesis

27/105

Chapter 2

The Phasor Measurement Unit

The Phasor Measurement Unit (PMU) is a generic device that producessynchronized phasors from voltage and/or current inputs and synchronizingsignal. The signal provided by the synchronizing source shall be referencedto Universal Time Coordinated (UTC). In order to synchronize the PMUstations, the time signal is broadcasted from satellites.

2.1 Description of the PMU

The PMU stations developed at DTU have been installed at four differentlocations in the eastern electricity net in Denmark. Furthermore two stationsare at DTU on a research and development basis.

2.1.1 The DTU PMU

The DTU PMU stations commonly consist of two PCs where one is run-ning the MS-DOSR operating system and the other is running MicrosoftWindowsR operating system. The MS-DOSR computer has the role to re-trieve measurements from the measurement equipment and place them in a

8/6/2019 Aml Thesis

28/105

6 The Phasor Measurement Unit

package, along with other vital information, which is sent to the WindowsR

computer. The packet description can be seen in appendix B.

The reason for choosing MS-DOS R as the operating system for the mea-surement computer was to gain full control of the computer. By modifyingthe AUTOEXEC.bat and the CONFIG.sys files in the MS-DOSR systemmany computer actions, for example updating the screen and configuringnetwork connections, can be turned off. These actions are unwanted by themeasurement part of the PMU as they can interrupt measurements causinginaccuracy in the critical timing of the measurements.

The WindowsR computer then runs a LabVIEWR program that receives themeasurement package every 20 ms, checks for errors in the measurement,converts the information to a IEEE standardized format [2] and stores the

measurements as binary files, once every hour. These operations are hardto perform using the MS-DOSR system which explains the selection of theWindowsR operating system for this part.

The main program structure of the DTU PMU can be seen on the flowchartsin appendix A. As seen from those flowcharts a common LabVIEW R pro-gram is made of one or more Virtual Instruments (VI). These VIs are pro-grams or files made by LabVIEWR. A main program created in LabVIEWR

is a VI and has the file extension .vi. It can have many sub VIs that havesimilar purpose as classes in a typical C or Java program. The DTU PMUhas a main VI called PMU COMMON.vi (Fig. A.1), the brain of the PMU,

which controls all communication between the two computers as well as run-ning important VIs like PMU Serial.vi and PMU IEEE.vi also described inappendix A, Figs. A.2 and A.3. The term VI will be used very frequentlythroughout this report.

2.1.2 Satellite system

Designers today can choose from three satellite systems for disseminating thetime but only the Global Positioning System (GPS) meets all requirements

for this application. The GPS is a satellite based navigation system devel-oped by the United States Department of Defence (DoD) in 1994. It consistsof 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 itselfis referenced to UTC. The signal from the GPS satellites can be received

8/6/2019 Aml Thesis

29/105

2.1 Description of the PMU 7

by a simple omnidirectional antenna. When the DTU PMU is started up itneeds at least four satellites two determine its position. After that it onlyneeds one satellite to determine the time as its receiver is in a fixed position.

2.1.3 The Phasors

Both the voltage and the current measurements from the PMU unit aretransferred as phasors. When working with a AC power system the voltagesand the currents are a sinusoids on the form x(t) = Xm cos(2f t + ) andcan therefore be represented as a phasor (X) which is generally written onthe form

X = (Xm/

2)ej (2.1)

where Xm is the magnitude and is the phase angle. The main benefit ofusing phasor representation is the fact that the phasors are independent ofthe system frequency. In practice the system frequency is never completelystable and fluctuates constantly around its nominal value which is 50Hz inthis case.

The DTU PMU measures at the observation interval T0 = 20ms which isequal to 1/f where f is the system frequency, 50Hz. This should resultin a constant phase angle, , if it were not for the fluctuating frequency.This is not a problem however because what is observed is the differencebetween two phase angles which cancels out any fluctuation. The phase

angle difference of interest is either between the voltage phase angles of twodifferent stations or the voltage phase angle and the current phase angle atone station

2.1.4 Data Transmission

The PMU transmits three types of information organized as frames. Theseframes are called Data Frame, Header Frame and Configuration Frame. ThePMU 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 DataFrame since it is the only frame containing measured data. The size ofthe Data Frames can vary for it is dependent on the types and amount ofmeasurements (phasors generated) at the PMU location.

Normally the system nominal frequency along with information about sta-

8/6/2019 Aml Thesis

30/105


tion and field names, scaling, conversion factors and data format, would bestored in a configuration frame but since the DTU PMU is not equippedwith that frame this information is stored in the LabVIEW R files of the

WindowsR computer.

2.2 Standards for Synchrophasors for Power Systems

The DTU PMU stations were all based on the first Standard for Synchropha-sors for Power Systems [2], published by the Institute of Electrical andElectronics Engineers (IEEE) in the year 1995. This standard was thencompletely 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 standardwhereas this project will use the latest edition. Therefore both editions ofthe 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-timephasor data frame of the 1995 standard.

Figure 2.1: Data frame for phasor data in the 1995 synchrophasor standard

The Data Frame is identified by having the three most significant bits of

SMPCNT equal to zero. The second of century (SOC) cell in Fig. 2.1 is a 4byte representation of the UTC time in seconds calculated from midnight ofJanuary 1, 1900, which attains new value every second. Each PMU stationunder consideration in this project computes 50 measurements each second,i.e. a new measurement is made every 20ms. This means that every 50measurements have the same SOC value.

8/6/2019 Aml Thesis

31/105

2.2 Standards for Synchrophasors for Power Systems 9

The phasor cells, each 4 bytes, in this case consist of 2 bytes for the mag-nitude and 2 bytes for the angle respectively, where the magnitude is repre-sented with a 16 bit binary number in the range 0 to 2 15

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 cellcontains the frequency which is represented by a 16 bit binary number inHz 103 deviation from system nominal.

2.2.2 The 2005 Standard

Several changes were made from the former standard in this new revised

standard. Specifically, the sync, frame size and station identification fieldshave been added to the data frame as well as the analog data field. Thefraction of second field has replaced the sample count field and the statusfield has been modified to include time quality.

Tables 2.1 and 2.2 list the data frame organization of the new IEEE standard.

Table 2.1: Word definitions of fields common to all frame types

Field Bytes Description

SYNC 2 Frame synchronization word.Leading byte: AA hexSecond byte: Frame type and version number.

FRAMESIZE 2 Total number of bytes in the frame, including CHK.

IDCODE 2 PMU ID number, 16 bit integer.Identifies device sending and receiving messages.

SOC 4 Time stamp, SOC count starting at midnight 01-Jan-1970.

FRACSEC 4 Fraction of Second and Time Quality, time of mea-surement for data frames.

CHK 2 CRC-CCITT

In the first round of implementing the new standard, all fields will be avail-

able but not active. Meaning that fields like SYNC, IDCODE, STAT, ANA-LOG and DIGITAL will be assigned a constant default value. This is be-cause fulfilling the purpose of these fields would mean a considerable changeon the existing programs which is both expensive and time consuming.

Following changes have also been made on fields that were defined in the

8/6/2019 Aml Thesis

32/105


Table 2.2: Data frame organization of the 2005 standard

Field Bytes DescriptionSTAT 2 Bitmapped flags.

PHASORS 4 Phasor estimates, 3-phase positive sequence.Polar format:

- Magnitude and angle, magnitude first

- Magnitude 16-bit unsigned integer range 0 to65,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 DTUPMU.

FREQ 2 Frequency deviation from nominal, in millihertz(mHz) Range-nominal (50Hz) -32.767 to +32.767Hz. 16-bit signed integers, range -31,767 to+31,767

DFREQ 2 Rate of change of frequency in Hz per second times100.

ANALOG 2 Analog word. 16-bit integer. It could be sampleddata such as control signal or transducer value.The number of the analog values is defined in theconfiguration frame.

DIGITAL 2 Digital status word. It could be bitmapped statusor flag.

The number of the digital status words is defined inthe configuration frame.

1995 standard:

The STAT field no longer contains the number of bytes in each framebut serves only as a complete status for the data in its data framewithin the bounds of the standard.

The SOC field now contains the number of seconds since the 1 st of

January 1970 instead of 1

st

of January 1900. The FRACSEC field replaces the SMPCNT field from the previous

standard.

The FRACSEC field is divided into two components, a 24-bit integer that is

8/6/2019 Aml Thesis

33/105

8/6/2019 Aml Thesis

34/105


In communication, the sender attaches the n bits ofR(x) after the originalmessage bits ofM(x) and sends them out (in place of the zeros). The receivertakes 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 theentire 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 agoit was based on some documentation about CRC from various sources. Theonly thing that the 1995 standard [2] demands is that the CRC cell shall bea 16 bit word using the generating polynomial X16 + X12 + X5 + 1 whichcan be represented with the hexadecimal word 0x1021.

The 2005 standard [9] describes the CRC, commonly referred to as CRC-CCITT, in more detail.

It shall use the generating polynomial G(x) = X16

+ X

12

+ X

5

+ 1.

The initial value of the CRC shall be 0xFFFF.

No final mask should be XORed with the final value of the CRC.

Table 2.3 shows example message data and the resulting CRC value from[9] and [8].

Table 2.3: Known CRC values according to numerous sources

ASCII message Resultant CRC value

A 0xB915

abc 0x514A

ABCD 0xBFFA

123456789 0x29B1

8/6/2019 Aml Thesis

35/105

2.3 The Cyclic Redundancy Check 13

Since the DTU PMU calculates the CRC from a cluster input it is difficultto check whether it gets the same CRC values from the messages in table2.3.

To check whether the DTU PMU calculated the CRC value correctly a sam-ple C code calculation example from [9] was translated into a LabVIEW R

program and the CRC value was calculated for an old data frame. Also acompletely different CRC C code from [8] was translated into a LabVIEWR

program for comparison.

This comparison resulted in both C code programs, that agreed with table2.3, calculated the same CRC code for the data frame but the DTU PMUCRC program, IEEE CRC.vi, gave a different result.

A thorough examination of IEEE CRC.vi shows that the reason for thisdifference is that IEEE CRC.vi does not contain a CRC variable with theinitial value of 0xFFFF. Also the generator polynomial should be XORedwith 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 approvedCRC values it calculates a CRC value which could well be capable of de-

tecting errors. The 16 bit CRC-CCITT is however designed to detect over99.9985% of all bursts errors that are greater than 17 bits long and 100% ofall bursts less than 17 bits.

Because of numerous CRC algorithms and methods available it is hard tofind a method which is generally accepted and defined. For example a reporton the internet by Joe Geluso [8] states, very convincingly that the valuesin table 2.3 are incorrect. His main argument is that CRC algorithms, thatproduce 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 thestandard CRC.

However convincing this sounds it is hard not to follow the IEEE acceptedvalues and method so the decision was to go with the IEEE for now.

8/6/2019 Aml Thesis

36/105


2.4 Summary

This chapter briefly explains the Phasor Measurement Unit (PMU) devel-oped at DTU. Both PMUs structure and functionality are described as themain focus is on the new and revised IEEE standard for Synchrophasorsfor Power Systems published recently. Also the CRC gets some attentionbecause of its important role in data transmission.

8/6/2019 Aml Thesis

37/105

Chapter 3

Design and Construction

One of the main reasons why LabVIEWR was chosen for this project wasthe fact that the WindowsR part of the PMU station was programmed inLabVIEWR. As the main objective in this project is to develop a client-server program in order to monitor on-line data from PMU stations then thebenefits of choosing LabVIEWR software is that it offers various methodsof programming a clientserver program.

Two different methods of clientserver programming in LabVIEW R will beexamined in this chapter and how they were implemented in the simula-tion which is also described in the forthcoming sections. The LabVIEWR

database toolset will also get its share of this chapter.

3.1 Client-Server Programming Methods

As mentioned above the LabVIEWR offers at least two methods of clientserver programming. One of these methods is a direct Transmission ControlProtocol/Internet Protocol (TCP/IP) programming whereas the other usescommon global variables.

8/6/2019 Aml Thesis

38/105

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 programthat uses built in TCP/IP VIs from the LabVIEW R VI library.

Figure 3.1: Simple TCP/IP server in LabVIEWR

A basic server as illustrated in Fig. 3.1, programmed using the TCP/IP VIsfrom LabVIEWR, begins with the listen to connection VI where the timeout limit, port number and IPaddress (optional) of the connection to theclient are specified. Once the connection has been established the numericdata is cast into a string data and sent via two TCP write VIs. The firstTCP Write sets the amount of data to send and the second TCP Write sendsthe data. Then when the data has been sent successfully the connection isclosed.

Figure 3.2: Simple TCP/IP client in LabVIEW R

The simple client illustrated in Fig. 3.2 begins with the TCP open con-nection VI which opens the connection to the server using appropriate portnumber and an IPaddress. Once the connection is open the data can beread from the port specified and cast into a numeric representation. Thefirst TCP Read in Fig. 3.2 acquires the size of the data and the second TCP

8/6/2019 Aml Thesis

39/105

3.1 Client-Server Programming Methods 17

Read reads the data and passes it to the DATA variable. When this is donethe connection is closed.

3.1.2 The Global Variable Method

Before using the Global Variable method, the built in LabVIEWR VI Servermust be configured. When configuring the VI Server the TCP/IP protocolmust be activated and the remote computers VIs must be given access tothe 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 GlobalVariable VI. The Open Application Reference VI and the Open VI Reference

VI locate the Global Variable VI (Globals.vi) where the transferred data iswritten. The data can be transferred as flattened string as in Fig. 3.3 or asa variant. This is specified at the Invoke Node VI where the control nameof 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

8/6/2019 Aml Thesis

40/105


to the server program in Fig. 3.3 where the difference lies in the function ofthe Invoke Node VI. The Invoke Node VI is used to get the current value ofString from Globals.vi as flattened data. The unflatten from string object

converts the data into a string data type. To save the user the work ofconstantly pushing the run button to check for new data it is possible toinsert a while-loop between the Open VI Reference VI and Close ReferenceVI.

Of course this method also uses the TCP/IP communication protocol butthe VI Server handles all the TCP/IP programming so that the programmerdoes not have to think about it. As in the TCP/IP method the user has tospecify the IPaddress of the remote machine, only at the server or the clientbut not both. The reason for this is that the Global Variable VI must beplaced 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 thatthe number of VIs used in each method is almost the same, which meansthat the programming is similarly complicated for both methods. Followingare the pros and cons of each method.

The TCP/IP programs do not need an extra VI like the Global Vari-able VI.

The size of the data does not have to be specified in the Global Variablemethod.

Only one IPaddress, the address of the Global Variable VI, needs tobe specified in the Global Variable method.

No port number needs to be specified in the Global Variable methodunless the user wants a different port number than the default onegiven by the VI Server.

There is a delay in the TCP/IP method of great concern. There is no buffer between the server and the client in the Global

Variable method, which means that the data is constantly overwritten.This can result in data loss if the client has not retrieved the databefore the server has overwritten them.

8/6/2019 Aml Thesis

41/105

3.1 Client-Server Programming Methods 19

The choice was to go with the Global Variable method despite the risk ofloosing data, especially because of the delay in the TCP/IP method. Thereason 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 theGlobal Variable VI can be placed at either the client or the server. For asit turned out the second PMU at DTU could not access the client so theclient had to get the data from the PMU. The first PMU at DTU howeverhad to write the data to the client as the client could not access the PMU.This is illustrated in Fig. 3.5.

PMU 1 PMU 2

Server VI Server VI

global

variableVI

global

variableVI

global

variableVI

CLIENTPC

Client VI

Figure 3.5: Configuration of global variable access between PMU 1, PMU 2 anda client PC

Ideally all of the data should be written to the Global Variable VI at theclient 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. Inthat 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 betweennormal PCs using the WindowsR XP system and LabVIEWR 8.

8/6/2019 Aml Thesis

42/105


3.2 Simulation

One of the advantages of using LabVIEWR is that it offers the option ofrunning a client-server simulation on a single PC. Of course some of thesimulation had to be performed using two computers to test the behavior ofthe program when using a remote connection. However the majority of thesimulation and development process was performed on only one PC.

One of the biggest problems when trying to simulate a PMU was to generatethe measurements data flow. The solution was to use old data that had beenstored in binary format. From these binary files it was possible to extractthe data frames, described in [2], one at a time.

3.2.1 The Server Simulation Program

The block diagram in Fig. 3.6 describes the flow of one of the simulationserver program developed for this project. In the simulation there are alwaystwo server programs running to simulate two PMUs. This server programconsists of four VIs that serve the only purpose of writing a string, in theform of a data frame, to the Global Variable VI.

The data frame was designed by IEEE so that measurement data could betransferred between networks without loosing reliability. That is why it was

chosen to let the server program send the entire data frame to the GlobalVariable VI so that the client program could run a CRC on the data toverify its authenticity. However in the simulation process the CRC was notexecuted on the data because the old data used had already been checkedusing the CRC algorithm mentioned in chapter 2.3.2.

3.2.2 The Client Simulation Program

Fig. 3.7 illustrates the flow of the simulation client program developed for

this project. This client program includes several VIs where few of themare database related VIs described later in this chapter. The main purposeof the client is to read the data from the Global Variable VI, verify it andpossibly 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

8/6/2019 Aml Thesis

43/105

3.2 Simulation 21

run String to Buffer.vi

get string from

Binary to String.vi

convert bin file with 1hour measurement data

to a string

divide string into

data frames and

call Buffer toQueue.vi

insert data frames

to a queue A

dequeue data

frames from queueA and write to

Global Variable.vi

while number of dataframes < 180.000

while stop = false

to sub LOOP

to main LOOP

waitwait

SERVER.vi

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

time difference between the data in string1 and string2 of the Global VariableVI. To rectify this the client sets an initial time stamp from the string withthe higher time stamp. The string with the higher time stamp is thenenqueued whereas the other is not enqueued until it has reached the initialtime 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 thedata to be viewed. This VI also allows the user to choose what type of datahe/she wants to monitor. The synchronization process ensures that the datamonitored from two different sources has the same time stamp.

8/6/2019 Aml Thesis

44/105


get data frames fromGlobal Variable.vi

call Buffer to Queue.vi

string1 to queue SQ1string2 to queue SQ2

dequeue data frames, extract

data from data frames into

cluster and enqueue tocluster queues CQ1 and CQ2

optional: runCompare

and Monitor.vi

review cluster queues and

synchronize data if necessary

dequeue clusters

and monitor data

while stop = false

while stop = false

CLIENT.vi

find Global Variable.vi

check if any data is instring1 AND string2 of

Global Variable.vi

data OK

no data

SQ1

CQ1 CQ2

SQ2

CQ1 CQ2

to chart

CQ1 andCQ2 in sync

wait

wait

Compare and Monitor.vi

Figure 3.7: Block diagram of the client simulation program

8/6/2019 Aml Thesis

45/105

3.2 Simulation 23

3.2.3 Simulation Results

3.2.3.1 Problem in Simulation

In the simulation process the string queues, SQ1 and SQ2 (see Fig. 3.7),behaved mysteriously. By this meaning that they were fully synchronizedin the beginning but as the program progressed the difference of the timestamps of their oldest elements went from 0 to 8 or even 9 seconds. As thereare 50 measurements in one second this difference was considerable and ofgreat concern. This also meant that when the data was being monitored thesynchronization process was constantly kicking in as the monitor queues,CQ1 and CQ2 (see Fig. 3.7), followed the string queues.

In order to find out the reason for this desynchronization, the main loops ofboth 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 bothloops varied between 40 to 50 ms on average and rarely went below 20 msas they were supposed to. A more thorough timing investigation revealedthat calling the Invoke Node VI (mentioned in chapter 3.1.2) was this timeconsuming. The LabVIEWR 8.2 Help on www.ni.com [3] partly explainsthis. It says, under Call By Reference Node Details:

At run time, there is a small amount of overhead in calling theVI that is not necessary in a normal subVI call. This overhead

comes from validating the VI reference and a few other book-keeping details.

Also because this project is about developing a client-server program thatis supposed to communicate across a network the same article says:

Calling a VI located in another LabVIEW application (acrossthe network) involves considerably more overhead.

Which should result in even greater run time across the network compared

to the simulation run time as the simulation was run locally.

Because of this delay the queues, at the servers, fill up and their oldestelements are removed to give space for new ones. In other words a loss ofdata is considerable and only about half of the data is transferred throughto the client.

8/6/2019 Aml Thesis

46/105


3.2.3.2 Possible Solution of Simulation Problem

The main cause of the delay problem is the fact that the server and theclient call the Invoke Node VI to write and read the data, respectively, inthe Global Variable VI. As this cannot be done every 20 ms the solutionmight be to send more than one measurement at a time. That is to transferat least five 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 different. The TOL of the main loop is now equal to nx20 ms, wheren is the number of data frames in the array to be transferred, but the TOLof the sub loop remains 20 ms to simulate the behavior of the PMU.

run String to Buffer.vi

get string from

Binary to String.vi

convert bin file with 1

hour measurement datato a string

divide string into data

frames and insert data

frames into array withshift registers

insert array of data

frames into a queue Aand clear array

dequeue array of

data frames from

queue A and write toGlobal Variable.vi

for i = (1:180.000)while stop = false

to sub LOOP

to main LOOP

waitwait

SERVER.vi

if i % n = 0

TRUEFALSE

TOL = 20 ms

TOL = nx20 ms

Figure 3.8: Block diagram of the server simulation program that transfers arraysof data frames

Also the Binary to String VI changes in such a way that elements are only

8/6/2019 Aml Thesis

47/105

3.3 Synchronization 25

inserted into queue A when the number of data frames in the array areequal to n.

The structure of the client remains mostly unchanged. Its main loop TOLincreases to nx20 ms as the TOL of the servers main loop. And insteadof retrieving strings from the Global Variable VI, it now retrieves arrays ofstrings with n elements. An extra for-loop was added in the main loop inorder to insert the data frames, from the array, to the cluster queues, CQ1and CQ2, one by one.

The cluster queues, CQ1 and CQ2, remain unchanged so that the Compareand Monitor VI needs no modification.

3.2.3.3 Simulation of the Modified Simulation Programs

The modifications done on the simulation programs proved to be very suc-cessful in the simulation process. The choice was to transfer an array of fivedata 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 mswhich 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 thatthey have to be synchronized to give any meaningful result. This is why agreat 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 inLabVIEWR were tested in the simulation process. Following is the sum-mation of these options where the first three are all possible solutions of abuffer system between the main client program and the monitor programs.

8/6/2019 Aml Thesis

48/105


3.3.1 Global Queues

The use of global queues was the first option tried in the simulation process.First the data frame is read from the Global Variable VI and then bufferedinto a global queue of a string type. Then the data frame is dequeued anddata is extracted from the data frame, put into a cluster and enqueuedto another global queue of a cluster type. When the user then wishes tomonitor the data this cluster queue is accessed from the second VI so thatthe data is enqueued at one end of the queue and dequeued at the other endat the same time as illustrated in Fig. 3.9.

Global Queue

Client

data

Monitor

data

Figure 3.9: Block diagram of two VIs accessing the same global queue

In the simulation process this did not seem to cause any conflicts and thedata was enqueued and dequeued at the same time without any problems.

3.3.2 Double Buffer System

Although using a single shared global queue did not seem to cause anyconflicts, the implementation of a double queue was also simulated. Thismethod is common amongst programmers where the idea is to avoid anyconflicts between programs. As illustrated in Fig. 3.10 the client programwrites data into one queue while the monitor program reads the data fromthe other queue.

Global QueuesClient

data

Monitor

data

Figure 3.10: Block diagram of two VIs accessing a double global queue

At first this method does not seem to be much more complicated thanusing only one buffer comparing Figs. 3.9 and 3.10. However from theprogrammers point of view this method is very difficult to implement. Thereason for this complexity is that it is necessary to control when each VI

8/6/2019 Aml Thesis

49/105


accesses the queues, when the queues should be flushed, and what is tohappen when the data is not being monitored and thus not dequeued.

In simulation this method gave a lot of problems and did not function verywell with the synchronization check so it was decided to go with the singlebuffer 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 dataframes in the purpose of being monitored, had to be accessed from two dif-ferent VIs at the same time. This was a concern because of the possibility of

a access violation. Normally in situations like this a designer would considerthe use of notifiers that allow only one VI to access another VI at a time.But in this case the two VIs had to access the data at the same time whichruled out the use of notifiers.

LabVIEWR offers the possibility of using shared variables in cases like this.The shared variables have built in buffer system so that the designer doesnot have to buffer the data specially. However the designer has no controlover these variables like reviewing the data without removing it from thebuffer or getting the status of the buffer. Also on the downside is the factthat 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 invery heavy programming or all data must be converted to the same type inorder to use arrays.

These restrictions of the shared variables as well as the negative resultswhen implemented in the simulation programs quickly ruled out the use ofthe shared variables for this project.

3.3.4 Timed Structures

One of the new features in LabVIEWR 8 is the timed structures. The timedstructures and their associated VIs are used to control the rate and priorityat which a timed structure executes its sub diagram, synchronize the starttime of timed structures, create timing sources, and establish a hierarchy oftiming sources.

8/6/2019 Aml Thesis

50/105


By using the timed loop of the timed structures it is possible to synchronizetwo or more signals. Making long story short, these timed structure VIswhere not applicable in this project as it seems that they are designed to

synchronize periodic signals which is not the case here. Therefore a furtherinspection 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 processbegins by determining the initial time stamp value. The initial time stampis 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 VariableVI reaches the initial time stamp, the data is enqueued. By doing this theoldest elements of both array queues will have the same time stamp and aretherefore synchronized.

3.3.6 The Synchronization Check

Since the time interval between the measured data is only 20 ms the smallestcomputer operation can cause the data to go out of synchronization duringlive monitoring. This is why the program has to be constantly verifying thatthe data is synchronized.

Every 20 ms the monitor program checks whether the measurements havethe same time stamp. Each time stamp has a SOC number and a FRACnumber defined in [9]. Table 3.1 describes what the synchronization al-gorithm does when the data has the same SOC number but not the sameFRAC number. Then the algorithm dequeues either queue 1 (data fromPMU 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 differ fromone 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 toget the same FRAC number.

8/6/2019 Aml Thesis

51/105


Table 3.1: The synchronization algorithm in pseudo code, part I

if SOC1 != SOC2 or FRAC1 != FRAC2

if SOC1 = SOC2

SOC sec = SOC2

if FRAC1 > FRAC2

while FRAC2 != FRAC1

dequeue queue 2

else

while FRAC1 != FRAC2

dequeue queue 1

Table 3.2: The synchronization algorithm in pseudo code, part II

elseif SOC1 > SOC2

SOC sec = SOC1

SOC frac = FRAC1

while SOC2 != SOC sec

dequeue queue 2

tmpFRAC = FRAC2

if SOC frac = tmpFRAC

continue to monitor

else

if tmpFRAC > SOC frac

while FRAC2 != SOC frac

dequeue queue 2

else


dequeue queue 1

When the algorithm has ensured that the next elements to be removed fromqueues 1 and 2 have the same time stamp then the data is printed on thescreen and the synchronization check is repeated.

8/6/2019 Aml Thesis

52/105


Table 3.3: The synchronization algorithm in pseudo code, part III

elseif SOC1 < SOC2SOC sec = SOC2

SOC frac = FRAC2

while SOC1 != SOC sec

dequeue queue 1

tmpFRAC = FRAC1

if SOC frac = tmpFRAC

continue to monitor

else

if tmpFRAC > SOC frac


dequeue queue 2

else


dequeue queue 1

3.4 Loop Timing

The time interval between measurements is only 20 ms, thus it is very im-portant that every iteration of the loop where the data is extracted andmonitored can be executed within those 20 ms. Should the iteration takemore time than 20 ms it would result in a notable delay. As the simulationprocess revealed the 20 ms time interval was to strict so that the TOL ofthe main loops was set to nx20 ms as each iteration transferred n numberof measurements using arrays.

Also it is important that every iteration of the clients and both of theservers loops should take exactly nx20 ms of execution time to preventany possible data loss. To ensure correct execution time LabVIEWR offersseveral 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, orfinish, when the millisecond timer value of the operating systemis a multiple of the millisecond multiple input. For instance, if

8/6/2019 Aml Thesis

53/105

3.5 Database 31

the VI is called with a millisecond multiple input of 10 ms, andthe millisecond timer value is 112 ms, then the VI will only wait8 more millisecond, at which time the millisecond timer value

will be 120 ms, which is a multiple of 10 ms. Using this VI totime a loop means that the loop will be synchronized with theoperating system millisecond timer value multiples [5].

synchronizedata

dequeueQ1

dequeueQ2

print toscreen

WAIT

20 ms

dequeueQ1

dequeueQ2

print toscreen

WAIT

20 ms

i i+1

Figure 3.11: Illustration of a loop timing using Wait Until Next ms Multiple VI

Fig. 3.11 shows an example of two loop iterations in the monitor program.The example shows that the two iterations do not include the same oper-ations but because of the wait function, both iteration have the same timeduration of exactly 20 ms.

Placement of the Wait Until Next ms Multiple VI in the program loop is alsoimportant as it is not desired that the waiting occurs between the dequeuingand printing the data to the screen. To ensure that it does not happen astructural sequence diagram can be used to force the waiting to occur beforedequeuing the queues which would be immediately followed by the printingto screen operation as in Fig. 3.11.

3.5 Database

Right in the beginning phases of this project it was decided to look intothe 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

difficult to be constantly monitoring the data. Only data reaching couple ofweeks back should be stored as older data was still to be stored in binaryformat.

Again LabVIEWR offers possible solutions to this problem with the Lab-VIEW Database Connectivity Toolset. The LabVIEW Database Connec-

8/6/2019 Aml Thesis

54/105


tivity Toolset is an add-on package for accessing databases and has to beinstalled separately.

3.5.1 Database Setup

Before it is possible to access or write data in a table, a connection to thedatabase must be established. The Database Connectivity Toolset supportsdifferent standards that use different methods of connecting to databases.These standards and methods will not be described in this project, only themethod 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 usingthe MicrosoftR ODBC Data Source Administrator where drivers can beregistered and configured to be available as data sources for the applicationto be used (MicrosoftR Access in this case). The ODBC driver selected herewas the MicrosoftR Access Driver.

Next a universal data link (UDL) has to b e created. The UDL containsinformation about what OLE DB provider is used (MicrosoftR OLE DB isthe default provider for the ODBC drivers), server information, user ID andpassword, default database, and other related information.

Finally a database file has to be available. There is no need to have MSAccess or any other database installed to use the Database ConnectivityToolset VIs. The LabVIEW.mdb file, which comes with the toolset, can berenamed and modified using the high-level VIs once the database connectionhas been established.

Many of the terms mentioned here are described in further detail in [10].

3.5.2 Database Limitations

Following are the limitations of the MS Access files (mdb files).

Maximum number of columns is 255. There is now row limitations but table size cannot exceed 1 Gb.

8/6/2019 Aml Thesis

55/105

3.5 Database 33

Maximum number of objects (tables, queries, etc.) in a database is32.768.

Maximum mdb file size is 2 Gb. However, because your database caninclude linked tables in other files, its total size is limited only byavailable storage capacity.

The 2 Gb limit should be plenty because if the amount data to be storedexceeds this limit one should consider using some other database like forexample Structural Query Language (SQL).

If only one mdb file is used to store the data a rough calculation estimatesthat one hour of data takes about 10 Mb of storage space which results in

the mdb file being capable of storing less than 10 days of data.

3.5.3 The Data Storage

Initially the idea was to store the entire IEEE data frame string in thedatabase. That would have been very convenient because the table wouldonly need one column that would include all the information for each mea-surement. However the VI developed for the simulation process to writedata 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 mainloop for one hour which resulted in only one third of the data written tothe database. This meant that writing data to database using the high-levelVIs from the database toolkit takes about 60 ms.

Because of this a decision was made to store the data every second, whichmeans an average value from 50 measurements. This also means that theIEEE string cannot be stored as it is not possible to find an average valueof a string. The data to be stored has to b e chosen from the string, table3.4 shows an example of the data chosen from the DTU PMUs.

For convenience all the data chosen to be stored in the database was con-verted to the same format, the single precision [32 bit real ( 6 digit preci-sion)].

Another problem arose as the phasors are complex numbers and there isno simple method available for computing the average value of a complex

8/6/2019 Aml Thesis

56/105


Table 3.4: The data that was chosen to be extracted from the IEEE string atthe DTU PMUs

SOC SOC time stamp defined in table 2.1 convertedfrom unsigned 32b to date/time format

Voltage Magnitude Extracted from PHASOR 1 in single precisionformat

Voltage Angle Extracted from PHASOR 1 in single precisionformat

Current Magnitude Extracted from PHASOR 2 in single precisionformat

Current Angle Extracted from PHASOR 2 in single precision

format

Frequency Scaled from FREQ defined in table 2.2 in singleprecision format

number. The decision was to take the root-mean-square (rms) value of themagnitudes, defined by (3.1).

Xrms =1

2

X2

0+ X2

1+ ...X2

49(3.1)

Calculating the average value of the angle is more complicated. This isbecause the angle constantly travels from 180 to 180 and if the anglechanges from 180 to 180 within one second then the average value forthat 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 themwould 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 offalling to 0 as illustrated in Fig. 3.12.

Table 3.5 lists the algorithm used to calculate the mean value of the an-gles. According to this algorithm the angle is only greater than 360 duringthe second where the angle changes from 360 to 0. When that secondpasses, the angle goes back to normal. The angle is also normalized withthe Quotient and Remainder VI resulting in a mean value between 0 and360.

8/6/2019 Aml Thesis

57/105

3.5 Database 35

Time [s]

Deg

rees

0 1

340

380 mean value= 360

Figure 3.12: Definition 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) < 0ANGLE(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 floor(tmp/360) = MEAN ANGLE

Finally the average values of the SOC time stamp and the frequency arecomputed using general averaging methods.

3.5.4 Improved Database VIs

As mentioned in the previous section the database VI developed for thesimulation process did not handle the 20 ms time interval and because ofthis delay a compromise was made which was to store average values of

8/6/2019 Aml Thesis

58/105


one second of data. Further inspections of why this delay occurs revealedhowever that the method used in simulation was not optimal. Fig. 3.13illustrates 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 whichmeant that the connection to the database was opened and closed every timea new data was written to the tables of the database. This is unnecessaryand can easily be avoided.

In the Global Variable method, described in chapter 3.1.2, a connection tothe Global Variable VI is established and then data can be written and readwhile conditions allow until the connection is closed. A similar method canbe used when writing data to the database. This method is illustrated inFig. 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 mainloop it can be run separately using its own while-loop where the data iswritten to the database. Then the VIs opening and closing the connectionto the database are only called once during the entire runtime of the program

8/6/2019 Aml Thesis

59/105

3.6 Summary 37

causing no delay. This means that using the method from Fig. 3.14 allowsall of the data to be written to the database. Despite being able to storeall 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 asdescribed in table 3.4.

A further and more detailed description of the database VIs is in chapter5.3.2.

3.6 Summary

In this chapter was a discussion of client-server programming methods. Thesimulation process performed during this project was described as well as thesynchronization algorithm used to synchronize data from two different PMUstations. Finally the database demands for the project were addressed.

8/6/2019 Aml Thesis

60/105


8/6/2019 Aml Thesis

61/105

Chapter 4

Electrical Data Analysis

One of the main objective of this project was to create a client-server pro-gram to give the possibility of viewing and analyzing electrical measurementdata from PMU stations on-line.

Unfortunately this project does not give much space for comprehensive elec-trical data analysis but following sections will aim to shed some light on theanalysis performed by the program developed for this project.

4.1 Phase Angle Difference

Amongst several measurements performed by the PMU is the phase anglemeasurement as the phase angle is always a part of the phasor defined inchapter 2.1.3. The voltage (V) and current (I) phasors are defined in (4.1)and (4.2) along with their phase angles and respectively.

V = (Vm/2)ej (4.1)I = (Im/

2)ej (4.2)

In (4.1) and (4.2) Vm and Im represent the voltage and current magnitudesrespectively. The client program developed offers the possibility of moni-

8/6/2019 Aml Thesis

62/105

40 Electrical Data Analysis

toring the voltage phase angle difference between two stations. It is alsopossible to monitor the voltage and current(s) phase angle difference at asingle PMU station. The difference,

, indicates the changes in the load

observed by the PMU.

As the client program can receive data from two PMU stations simultane-ously it is possible to compare measurements from both stations on-line.Although the voltage magnitude and frequency of the stations can be com-pared on-line then the voltage phase angle difference between the stations isof most importance. This is because of the relationship between the voltagephase angle difference and the complex power delivered by a transmissionline.

To demonstrate this relationship it is possible to consider a lossless trans-

mission line between two PMU stations. Although lines are never lossless inpractice, 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

andY

2 =

jC

2 S

where is the line length. The complex power (S2) delivered to PMU station2 is given by (4.3).

S2 = V2ej2

V1e

j1 V2ej2jX

+

jC

2V22 e

j22

=jV1V2e

j2j1 jV22 ej22X

+jC

2V22 e

j22 (4.3)

From (4.3) the real power delivered can be calculated as follows:

P2 = (S2) = V1V2 sin(1 2) V22

sin(22)

X Cl

2V22 sin(22)

8/6/2019 Aml Thesis

63/105

4.1 Phase Angle Difference 41

Also if (1 = ) and (2 = 0) then P2 is given by (4.4).

P2 =V1V2X

sin() W (4.4)

PMU 1

V1

= V1ejd1

PMU 2

V2

= V2ejd2

Z

Y/2Y/2

Figure 4.1: Equivalent circuit for a lossless transmission line between twoPMU 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 angledifference and thus it can be very interesting to monitor the phase angledifference in relation to the real power as well as the reactive power.

The calculations and approximations made here are valid for medium longtransmission lines in the range of 80 to 250 km. For longer lines the totalseries impedance is

Z = Zsinh()

and the shunt admittance is

Y

2=

Y

2

tanh(/2)

/2S

where

=

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 stationsat the same time, measuring at the same level (at both ends of a transmis-sion line) gives the most meaningful results. Thus adding more stations isunnecessary and can only complicate things.

8/6/2019 Aml Thesis

64/105

8/6/2019 Aml Thesis

65/105

8/6/2019 Aml Thesis

66/105

44 Electrical Data Analysis

8/6/2019 Aml Thesis

67/105

Chapter 5

Program Architecture

The greater part of the work in this project was to develop the client-serverprogram in LabVIEWR. Therefore it is important to report some of thework done here. This chapter will be dedicated to the description of theprograms developed during the project. This description will include a pro-gram manual describing the user interface of the program, the hierarchy of

the programs, block diagrams, flow charts and algorithms.

5.1 The Program Manual

In order to get a better comprehension on what the program is all aboutFig. 5.1 illustrates simplified overview of the client-server program, set upat DTU. What Fig. 5.1 shows is the two different set-ups of the GlobalVariable VIs belonging to both PMU stations. The Global Variable VI thatPMU 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 specifyan IPaddress to access the Global Variable VI and the client also needs tospecify 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-

8/6/2019 Aml Thesis

68/105

46 Program Architecture

global

variable

VI

global

variableVI

IEEEarray IEEEarray

PMU 1

SERVER VI

Array Queue

PMU 2

SERVER VI

Array Queue

PC

Array Queue Array Queue

Synchronizeand

Monitor

Database

Cluster Queue

Cluster QueueCluster Queue

Cluster Queue

CLIENT VI

Figure 5.1: Overview of the client-server program, set up at DTU

ered.

The connection between the client and the server must be verified.

This can be done with the LabVIEWR VIs Set and Get available fromwww.ni.com.

The PMUs LabVIEWR VIs must be running.

Paths locating the Global Variable VIs must be accurate in both theServer.vi and the Client.vi

IPaddresses of the servers and the client must be verified.

The database connection must be checked.

When this has all been checked the server VIs and the client VI can be runin no particular order.

8/6/2019 Aml Thesis

69/105

5.1 The Program Manual 47

5.1.1 The Server Manual

The front panel of the modified PMU COMMON.vi in Fig. 5.2 is the inter-face on the screen at the DTU PMU when it is running. The modificationsdone for the client-server program are the controls depicted in the SERVERoperations box. There the most important ones are the Live Stream dropdown menu and the IPaddress field.

Figure 5.2: The front panel of the modified PMU COMMON.vi at the servercomputer

In the Live Stream drop down menu the user can select one station to startthe Server VI that sends the data on-line to a Global Variable VI locatedat the computer specified by the IPaddress field. If the IPaddress field isleft 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 wherethe second one serves as a reference server that was developed exclusivelyfor the testing process. The reference Server VI can be used to implementphase angle difference or time delay specified with the PhaseDiff and Delay

fields respectively. The LEDs, Serv1 and Serv2, indicate if an error occursin the Server VIs.

When the one station option is selected a Server VI front panel pops upand a green LED, labeled Sending, lights up indicating that the data is beingwritten to the Global Variable VI.

8/6/2019 Aml Thesis

70/105


5.1.2 The Client Manual

The client interface was designed in such a way that the user does not have tothink about IPaddresses, VI paths or database connections. Thus makingthe interface simple and user friendly. To make sure that this design goal isachieved, the programs must be installed properly in the beginning.

Before running the client VI the PMU stations to be monitored must beselected from the drop down menus, Station 1 and Station 2, shown in Fig.5.3. The size of the data queues can also be changed in the IEEEQsize field.When the client is running, the View and Database drop down menus onlybecome active when the data retrieved from the Global Variable VIs hasbeen verified. This allows the user to store the data in database and/or

monitor the data on-line from a graph.

Figure 5.3: The front panel of the Client.vi

By selecting the option P and Q from the View menu the VI depictedin 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 differencebetween station 1 and 2. The lower graph then shows the voltage magnitude

and the frequency of station 1.

The View menu also offers two other options, CAM (short for compareand monitor) and PhDiff. By selecting the CAM option a similar VI asdepicted in 5.4 pops up. This VI offers the possibilities of monitoring oneof the following options at a time:

8/6/2019 Aml Thesis

71/105

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 PhDiff is selected a monitor pops up showing the voltage andcurrent phase angle differences from PMU stations 1 and 2.

8/6/2019 Aml Thesis

72/105


5.2 The Hierarchy

Figs. 5.5, 5.6 and C.1 illustrate the hierarchies of the programs developedduring this project. In these figures the double lined boxes include the mainVIs, normal lined boxes include sub VIs and VIs called by the main VIs, dot-dashed boxes indicate a drop-down menu and option numbers and dottedboxes represent VIs that were developed during the project but are notimportant for the program operation. The numbered boxes b eneath someof the VIs indicate that there are two of the VIs connected to the numbers,one for each PMU being monitored.

PMU_COMMON.viOther PMU VIs

PMU_SERIAL.viGlobal_Data.vi

NEWConverData.vi

NEWIEEE_CRC.vi

BuffArray.vi

SERVER

2nd Server.vi

2

SERVER.vi

ConvertManip.vi1

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 andare described in appendix A, Figs. A.1 and A.2. These VIs were slightlymodified during this project in relation to the server.vi.

The Global Data.vi and the Global info.vi are not to be confused with theGlobal Variable VIs as these VIs contain local global variables used by theserver- and the client-programs respectively. The other VIs in the hierarchyfigures 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 orderto give understanding of their functionality in the whole program.

8/6/2019 Aml Thesis

73/105

5.3 Description of the VIs 51

CLIENT.vi

ChkandBuff.viGetInitTime.viArraytoClusters.vi

Global_info.vi

VIEW DATABASE

1 2 3 10

CAM.vi PhDiff.vi PQ_Mon.vi WritetoDB.viNo DB

DatatoBuffer.vi

CRC_Chk.viDBandCAMbuff.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 inLabVIEWR 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 queuecontaining arrays of data frame strings and write the data to the GlobalVariable VI. Fig. 5.7 explains the program flow of the server.vi and Fig.5.8 shows the block diagram of the server.vi when it has located the GlobalVariable 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 transferredas a variant but not as a flattened string as in Fig. 3.3. By doing this, usingthe Flatten to String VI is avoided as it is only available in LabVIEW R 7.x.LabVIEWR 8.0 (used in this project) has a Flatten to String VI but that VIdoes not offer the output type string that is necessary when transferring

8/6/2019 Aml Thesis

74/105

8/6/2019 Aml Thesis

75/105

8/6/2019 Aml Thesis

76/105


Figure 5.9: The block diagram of the client VI, retrieving data from the GlobalVariable VIs

5.3.2 The Client VIs

Client.vi

The main purpose of the client.vi is to retrieve data, sent from two different

PMU stations, from the Global Variable VIs. Fig. 5.10 illustrates the flowof the client.vi and Fig. 5.9 shows the programs block diagram while in theprocess of retrieving data from the Global Variable VIs.

The client VI runs two while-loops in parallel during normal operation. Theupper loops purpose, in Fig. 5.9, is only to retrieve data, extract data

8/6/2019 Aml Thesis

77/105


CLIENT

0.0 Queues created

0.1 Establish connection to both Global Variable VIs

0.2 Check for data in both Global Variable VIs

while stop = false Case:0

0 Retrieve data from both Global

Variable VIs

Get initial time with GetInitTime.vi

1 Perform CRC on array1 and

buffer array1 to IEEEQ1 if

array1 has reached initial time

no yes

Both arrays reached initial time ?

Case:1

Are there any elements in

IEEEQ1 and IEEEQ2

no yes

Case:2.1

Dequeue IEEEQ1 -> DBandCAMbuff.vi

DBandCAMbuff.vi -> CAM1 and DBQ10

1

WAIT until next nx20 ms multiple2

goto Case:2.1 next

goto Case:1 next

Promt user to run:

Promt user to save

data to database

A: CAM.vi

B: PhDiff.vi

C: PQmon.vi

2 Perform CRC on array2 and

buffer array2 to IEEEQ2 if

array2 has reached initial time

Case:2.0

Dequeue IEEEQ2 -> DBandCAMbuff.viDBandCAMbuff.vi -> CAM2 and DBQ2

1 Perform CRC on

array1 and buffer

array1 to IEEEQ1

2 Perform CRC on

array2 and buffer

array2 to IEEEQ2

WAIT until next nx20 ms multiple3

1.0

while stop = false

RUNINP

ARA

LLEL

2.0Destroy Queues, Abort Vis, EXIT

TOL = nx20 ms

Figure 5.10: The flow chart of the client VI

and enqueue data to the appropriate queues. The lower loop then checksif the user wishes to monitor the data or store it in a database by runningappropriate VIs. The reason for doing this is b ecause that when the user

8/6/2019 Aml Thesis

78/105


chooses to run a monitor program, an Invoke Node VI is called which coulddelay the upper loop if it was placed there. That is unacceptable as theprocess 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 thehigher SOC value incremented by one second. The VI is only called onetime to determine the initial time of the values to be placed in the IEEEQs(see Fig. 5.10).

ChkandBuff.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 elementsinclude errors detected by the CRC algorithm then an error message isdisplayed in the source window (see Fig. 5.3. This VI also enqueues thearrays into the IEEEQs (see Fig. 5.10).

ChkandBuff.vi

Queue in

Queue size

INPUT

Station ID

Array in

msg

OUTPUT

Figure 5.11: Inputs and Output of the ChkandBuff.vi

ArraytoClusters.vi

The inputs and outputs of ArraytoClusters.vi are shown in Fig. 5.12. This

VI has a for-loop that extracts information from the array input into clus-ters that are enqueued to the CAM and DB queues (see Fig. 5.10) in eachfor-loop iteration. This means that for every array element dequeued fromthe IEEEQs, n elements are enqueued to the CAM and DB queues. Theinformation in the clusters generated depend on which PMU is being moni-tored, controlled by the PMU ID (Station ID) input. For the PMU stations

8/6/2019 Aml Thesis

79/105


located at DTU the cluster would have the same information as listed intable 3.4.

ArraytoClusters.vi

CAM Queue in

DB Queue in

INPUT

Station ID

Array in

#MON

OUTPUT

SOC

Figure 5.12: Inputs and Output of the ArraytoClusters.vi

CA

aml thesis

Documents