Design and Implementation of Communication,Storage & Archival of IEEEC37.118 Standard based

Wide Area Measurement System

Project Report

Submitted in partial fulfillment of the requirements for the degree of

Master of Technology

by

Kedar KhandeparkarRoll No : M0911C04

under the guidance of

Prof. V.Z. AttarCollege of Engineering, Pune

Prof. A.M. KulkarniIndian Institute of Technology, Bombay

Prof. S.A. SomanIndian Institute of Technology, Bombay

Department of Computer Science & EngineeringCollege of Engineering, Pune

June 2011

DEPARTMENT OF COMPUTER ENGINEERING

AND INFORMATION TECHNOLOGY,

COLLEGE OF ENGINEERING, PUNE

CERTIFICATE

Certified that this project, titled “Design and Implementation of Communi-

cation, Storage & Archival of IEEE C37.118 based Standard based Wide

Area Measurement System” has been successfully completed by Kedar Khandeparkar

(M0911C04).

And is approved for the partial fulfilment of the requirements for the degree of “M.Tech.

Computer Engineering”.

SIGNATURE SIGNATURE

Prof. V.Z. Attar Dr. Jibi Abraham

Project Guide Head

Department of Computer Engineering Department of Computer Engineering

and Information Technology, and Information Technology,

College of Engineering Pune, College of Engineering Pune,

Shivajinagar, Pune-5. Shivajinagar, Pune-5.

SIGNATURE

Prof. S.A Soman

Project Co-Guide

Department of Electrical Engineering

Indian Institute of Technology, Bombay

Powai, Mumbai-76.

ii

Acknowledgements

I would like to express my sincere thanks and gratitude to my guide Prof. V.Z. Attar

Prof. A.M. Kulkarni and Prof. S.A.Soman for the constant motivation and valuable

guidance they provided me throughout the course of the project. I am highly indebted

to them for giving me this opportunity to work under them for this M.Tech project and

also clarifying my doubts and for bringing into perspective, the different aspects of the

project topic. They constantly encouraged me by giving suggestions and criticisms on my

work. Working under them has been a great learning experience for me.

iii

Abstract

With information and measurement technology evolving rapidly within the electric

power industry, wide-area measurement is deemed to be the key technology to improve

power system reliability. Phasor Measurement Unit (PMU) deployment for Wide Area

Measurement System (WAMS) results in large amount of data being generated every

second across the PMU network. Currently, many transmission operators do not have the

ability to process, store, and utilize this data. This report gives the overview of WAMS

and its components. It also gives the design and implementation details of PMU-PDC and

PDC-PDC communication over TCP and UDP. This design enable PDC to handle data

from PMUs or other PDCs that are IEEEC37.118 synchrophasor standard compliant.

The working of storage & archival of PMU/PDC data in MySQL database has also been

explained in the report. Storage enables post analysis that can reveal useful information

of the PMU data patterns.

iv

Contents

Abstract iv

List of Figures vii

1 Introduction 1

1.1 Smart Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Organization Of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Wide Area Measurement System 3

2.1 Components of Wide Area Measurement System . . . . . . . . . . . . . . . 3

2.1.1 Phasor Measurement Unit . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1.2 PMU Standards . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2 Phasor Data Concentrator . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 WAMS Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Design Model 12

3.1 iPDC WAMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1 iPDC Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2 iPDC Working . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.3 iPDC Implementation Details . . . . . . . . . . . . . . . . . . . . . 20

3.2 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.1 DbServer Working . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.2 DbServer Implementation Details . . . . . . . . . . . . . . . . . . . 34

4 Experiments & Results 41

4.1 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Conclusion & Future Work 45

v

6 Bibliography 46

vi

List of Figures

2.1 Trandmission Order of IEEE C37.118 Frame . . . . . . . . . . . . . . . . . 5

2.2 UDP Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 TCP Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Summarized PDC Product Comparison Chart . . . . . . . . . . . . . . . . 11

3.1 WAMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 iPDC Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 PMU - iPDC communication . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Data Frame Arrival at iPDC . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.5 Configuration Frame Arrival at iPDC . . . . . . . . . . . . . . . . . . . . . 18

3.6 Connection Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.7 Recreate configuration objects . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.8 Data Structure for Configuration Frame . . . . . . . . . . . . . . . . . . . 30

3.9 Data Structure Data Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.10 Data Structure PMU Status Change . . . . . . . . . . . . . . . . . . . . . 31

3.11 Data Structure Source Device Details . . . . . . . . . . . . . . . . . . . . . 32

3.12 Data Structure Destination Device Details . . . . . . . . . . . . . . . . . . 32

3.13 DBServer Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.14 Data Structure for DBServer Configuration Frame . . . . . . . . . . . . . . 38

3.15 Data Structure for DBServer Data Frame . . . . . . . . . . . . . . . . . . . 39

3.16 iPDC Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Resource Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Case1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Case2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4 Case3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.5 Case4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.6 Resources Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

vii

Chapter 1

Introduction

Power is produced by creating a force to spin a large electric generator. The generator

produces electricity which is then transferred into the power grid system. These generators

are powered through many different sources. In damns, water is used to spin the wheels.

Many are spun by steam power generated by nuclear power, or by burning coal or gas.

Regardless of how the power is produced, all of these production plants and facilities are

connected to the national power grid. Their power is then transferred through high voltage

transmission lines to a control center. These Transmission lines, when interconnected with

each other, become high voltage transmission networks. These are typically referred to

as power grids.

Control centers then transfer the power to different regions or areas. The control

facilities are run by experts who monitor the needs of the different areas and regions under

their control. They transfer power from areas of low demand to areas of high demand

to ensure that all areas have the power that they need to operate. Usually power is

transferred by simply flipping a switch which automatically transfers the power. Power

transferred out of the control center goes to substations. These substations can be either

regional or in residential neighborhoods, depending on the amount of people in an area.

Before the electricity can be delivered to a community to be used in homes and businesses,

it is necessary to reduce the current. This reduction of the current is referred to as stepping

down the current. After the current is stepped down at the substation it is pumped into

power lines.

1.1 Smart Grid

A SMART Grid is an intelligent, digitized electricity system providing an energy net-

work that delivers electricity in an optimal way from source to consumption, enabling

better energy management, minimizing power disruptions and transporting only the re-

quired amount of power. SMART Grid in large, sits at the intersection of Energy, IT and

Telecommunication Technologies. Much like computers and routers manage the flow of

bits on the Internet, SMART Grid technologies use information to optimize the flow of

electricity. Smart Grid enables better energy management. It can also serve as a platform

1

for innovation in energy services, which gives customers more information about their en-

ergy footprint and ways to manage their electricity consumption. Without Smart Grids,

if there is a breakdown at local substation, the utility usually finds out when customers

call to complain. Placing a networked sensor inside a transformer or along wires could

locate and report a problem, or prevent it from happening in the first place. SMART

Grid features include Phasor Measurement Technique, Wide Area Measurement (WAM),

Self healing Grids, Probabilistic and Dynamic Stability Assessment etc.

This report contains the design and implementaion details of commu-

nication, storage & archival of IEEEC37.118 Standard based Wide Area Measurement

System. The organization of the report is given below.

1.2 Organization Of the Report

1. Chapter 2 describes in brief the WAMS & its components.

2. Chapter 3 describes Design and Implementation details of iPDC.

3. Chapter 4 describes Experimnents & Results.

4. Chapter 5 discusses future work that is to be done.

2

Chapter 2

Wide Area Measurement System

In 1995 the U.S. Department of Energy (DOE) launched the Wide Area Measurement

System (WAMS) Project to determine the information needs of the emerging power sys-

tem and to develop guidelines for deploying the technology to meet those needs. It is one

of the features of the Smart Grids. WAMS evolved as an advanced measurement tech-

nology to collect information not available from contemporary supervisory control and

data acquisition (SCADA) technology. A noteworthy contribution made by the WAMS

technologies was demonstrated during the failure of the Western power system on Au-

gust 10, 1996. The results of this breakup, when compared to the dynamic information

being provided by WAMS led to several strategic undertakings by the electric utilities.

The data fully supported that there is an over-reliance on the current models and that

the models were inadequate in predicting system response. One of the greatest benefits

realized was that the data contained precursors, which if had been properly analyzed,

could have allowed proactive switching of generating resources. This could have either

eliminated or drastically reduced the impact of the initial line failure.

WAMS and SCADA Comparison

1. SCADA can provides steady, low sampling density, and non synchronous information

of the network, according to which the dispatching and controlling center cannot

know the dynamic operation states of the system exactly.

2. WAMS enables us to observe the power system synchronously in more elaborate

time scale, and analyze the power system with some new methods.

2.1 Components of Wide Area Measurement System

Wide Area Measurement System has two components

1. Phasor Measurement Unit (PMU)

2. Phasor Data Concentrator (PDC)

3

2.1.1 Phasor Measurement Unit

2.1.1.1 Introduction

They are devices which use synchronization signals from the global positioning system

(GPS) satellites and provide the phasor voltages and currents measured at a given substa-

tion. GPS is accurate to within 1 microsecond at any location on earth. A 1-microsecond

error translates into 0.021or a 60 Hz system and 0.018or a 50 Hz system and is certainly

more accurate than any other application. PMUs are located at substation from where

high voltage transmission lines are drawn. The input of PMU is connected to the output

of three phase power/current transformer. It has a GPS receiver which obtains synchro-

nized time. Frames generated by PMU contain the measurements along with the GPS

time stamp at which the measurements were made.

2.1.1.2 PMU Standards

1. IEEE 1344 Standard

IEEE 1344 was proposed in 1995. It uses Network Time Protocol (NTP) format for

time synchronization. There are four frame type defines in this standard. They are

Configuration, Data and Command frame & Header. This format does not support

the analog measurements.

2. The PDCStream

BPA PDCStream protocol was developed by one of the WAMS network owners and

it specifies how the data from PMU is to be stored at PDC. It also specifies secure

transport of data to other PDC. The PDCStream protocol specifies two frames,

a descriptor frame and data frame. The descriptor frame is sent every minute.

The descriptor frame is similar to the configuration frame specified within IEEE

Standard 1344 in that it provides the information necessary for parsing the data

frame.

3. The PDCxchng

PDCxchng protocol was developed by one of the WAMS network owners for trans-

mission of compiled phasor measurements between PDCs over low bandwidth con-

nections. The protocol uses a format that is incompatible with the IEEE standards.

Because of this reason use of this protocol is very limited.

4. IEEE C37.118 standard

IEEE C37.118 is widely adopted by all the vendors. It is the upgraded version of

IEEE 1344 protocol and was proposed in 2005. There are Four frame type define in

this standard. They are:

4

• Command Frame

• Configuration Frame

• Data Frame

• Header Frame

All the four type of frames have some common fields and the frames are transmitted

in Big-Endian format.

Command Frame is received by PMU/PDC in order to take a particular action.

Figure 2.1: Trandmission Order of IEEE C37.118 Frame

This frame always be sent by a PDC to PMU. The command frame may be a request

for configuration or data frames or on/off the data transmission.

Configuration frame contains the information and processing parameters of the

PMU. Like phasor, analog, frequency and digital value of PMU.

Data frame provides information regarding phasor data, analog data and the state

of the digital inputs on each channel. It also defines the frequency, angle, over-

current, under-voltage and rate of frequency change.

Header frame is human readable/ASCII information about the PMU, the data

sources, scaling, algorithms, analog filters used, or other related information.

2.1.2 Phasor Data Concentrator

It is a node in a system where phasor data from the number of PMUs or PDCs is

correlated and fed out as a single stream to other applications. The tasks performed by

a PDC include :-

• Collection of all the phasor measurement from different phasor measurement sites

where PMUs are placed.

5

• Synchronization of all the phasor measurements from different sources.

• Packaging of all the phasor measurements with same timestamp and send to the ad-

vanced applications(Real-Time Wide Area Monitoring, Real-Time Wide Area Con-

trol, Real-Time Wide Area Protection).

• The PDC provides additional functionalities as well. It performs various quality

checks on the phasor data and inserts appropriate flags into the correlated data

stream. It checks disturbance flags and records files of data for analysis.

2.1.2.1 Applications

These are some applications where PDC plays a important role

• Real Time Monitoring and Analysis -

The main objective of the real time monitoring and anlaysis application is to monitor

the real-time power angle difference between two different areas which could give

the system operator the views and feel of the system’s strength and power flow. It

also includes wide area Real Time Grid Dynamics Monitoring.

• Real Time Control -

The real time control application uses phasor measurements as the basic input. The

real phasor measurements are sent by PDC to control application. The applicaton

uses one or more algorithms to determine if the system is close to a stability limit.

If a power swing exceeds limits, the control application would take some predefined

action that prevent the whole system to crash.

• Real Time Adaptive Protection -

The Real Time Adaptive Protection or wide area protection is used to save the

system from partial or total blackout in operational situations when no particular

equipment is faulted or operated outside its limitations. The protection system

reacts to an emergency by taking additional switching actions to restrict the impact

of a wrong operation.

• Data Archiving -

The Data Archiver of Wide area measurements is used for reviewing the system

performance in the previous days or post analysis . This application enables operator

to analyze data recorded in two ways they are Phasor Analysis and Disturbance

Analysis.

6

2.2 Communication

PDCx, PDCy denotes the PDC installed on machine x and y respectively.

1. Initially, PDCx will send a command frame to PMUy/PDCz to send its configuration

frame.

2. PMUy/PDCz will reply with the configuration frame.

3. PDCx will then send another command frame to PMUy/PDCz to start sending the

data frames.

4. PMUy/PDCz will then start sending the data frames.

5. If PDCx detects any change in data sent by PMUy/PDCz which it can know from

the bits in the STAT word of the data frame, it will send a command frame to

PMUy/PDCz to send its changed configuration frame.

6. PMUy/PDCz will then send the changed configuration frame.

7. The PDCx will then send command frame to PMUy/PDCz to start the transmission

of data frames.

8. PMUy/PDCz will then start sending the data frames.

PMU-PDC can communicate with each other over TCP or UDP protocols. UDP is an

unreliable communication protocol. The UDP server in client-server model is stateless. It

does not retain the connection state. UDP does not handle packet loss. Thus if a packet

is lost or corrupted then it cannot be retained. It is mostly used to transfer real time

streaming data such as videos where timely delivery is more critical.

TCP is a reliable communication protocol. The TCP server in client-server model is

stateful. It maintains state information of all client connections. TCP handles packet

loss, error control, retransmission of the lost packets etc. For every packet sent there is

an acknowledge(ACK) packet sent by the receiver. There is a three way handshake to

establish and terminate the connection between the client and server. A connection is

initiated by a SYN packet and terminated by FIN packet.

7

PDC- xPMU -y/ PDC-z

CMD Frame- Send CFG Frame

CFG Frame

CMD Frame-Send Data Frame

Data Frame-2

Data Frame-n

Data Frame-1

Stat word change detected

Data Frame-x+1

Data Frame-x

CMD Frame- Data Transmission off

CMD Frame- Send CFG Frame

CFG Frame

CMD Frame-Send Data Frame

Figure 2.2: UDP Communication

2.3 WAMS Implementations

1. openPDC

The open source phasor data concentrator (openPDC) is a system that is used to

manage, process and respond to dynamic changes in fast moving streaming phasor

data. More specifically, the openPDC can process any kind of data that can be

described as time-stamped measured values. These measured values are simply

numeric quantities that have been acquired at a source device and are typically

called points, signals, events, time-series values or measurements. Examples of

measurements include temperature, voltage, vibration, location, luminosity and,

of course, phasors. When a value gets measured, an exact timestamp is taken,

typically using a GPS-clock for accuracy - the value, along with its timestamp, is

then streamed to the openPDC where it can be time-alignedwith other incoming

measurements so that an action can then be taken on a complete slice of data that

was all measured at the exact same moment in time.

8

PDC-x PMU-y/PDC-z

Seq=y, ACK=x+1

Seq=x+1, ACK=y+1

SYN (Seq=x)

CMD Frame- Send CGF Frame

ACK

CFG Frame

ACK

CMD Frame- Send Data Frame

ACK

Data Frame -1

ACK

Data Frame -n

ACK

Figure 2.3: TCP Communication

Its an Open Source software developed in Visual .NET but not free

for commercial use at it requires approval from Tennesse Valley Authority(TVA).

It run on Windows operating system. Each PDC can support approximately 120

PMUs. It is a versatile PDC software as it supports different PMU standards such

as IEEEC37.118, IEEE1344, PDCStream, Macrodyne etc. Its space utilization rate

is 1.5 GB/hr (36 GB a day) and measurement archival rate is 150 million/hr(3.6

billion a day). The openPDC is based on the SuperPDC which was developed by

the Tennesse Valley Authority starting in 2004.

Although the system was specifically developed to manage real-time

streaming synchrophasors and generate time-sorted concentrated data streams using

standard protocols, its completely modular based design makes the system a gen-

eral purpose distributed stream processing engine. This adaptive system design also

makes it simple to integrate the openPDC with other systems that you may want to

use to help manage and archive streaming event data (e.g., Microsofts StreamInsight

CEP Platform, OSIsofts PI Historian, etc.) The openPDC will have a broad range

9

of uses outside of synchrophasors where real-time streaming measured data needs to

be processed and archived, for example: consumer energy usage (smart-grid), seis-

mic metering, high-speed location tracking, fast changing temperature monitoring,

surveillance applications, network traffic processing, etc.

2. enhanced Phasor Data Concentrator(ePDC)

ePDC is an open, platform independent software system, unlike hardware-based or

proprietary legacy PDCs, and is available on Windows or UNIX/Linux systems.

ePDC runs on standard platforms that are currently supported by your IT staff.

The ePDC (designed by Ken Martin and product of Electric Power Group), ad-

dresses every operational challenge that can be encountered in the real world of

synchrophasor deployments - PMU un-synchs, data errors, communication issues,

etc. Right from enhancements like being able to reconfigure and update in real

time (while simultaneously operating) to automatic detection and reconfiguration if

a PMU configuration is changed or a new PMU is added.

3. SYNC 4000 Phasor Data Concentrator

SYNC 4000 developed by Kalki Technologies can also function as a high performance

and scalable synchro-phasor data concentrator and protocol conversion gateway for

Wide Area Monitoring applications. It is capable of collecting phasor data streamed

from any IEEE C37.118 compliant phasor measurement unit via Ethernet and aggre-

gates all the C37.118 input streams, performs data validation and time alignment,

and transmitsC37.118 super packets to multiple clients. It can also

perform protocol conversion from C37.118 to a number of common power system

protocols, for interfacing with SCADA, EMS or other third party applications. User

friendly tools for configuration and diagnostics make engineering, system integration

and commissioning quick and easy. The SYNC 4000 PDC can collect data streams

from up to 100 PMUs simultaneously at rates of 60 samples/sec. The SYNC 4000

is based on standard quad-core server hardware. The SYNC 4000 is designed with

scalability and performance as the key objectives. The current generation SYNC

4000 can handle up to 1000 PMUs.

10

Figure 2.4: Summarized PDC Product Comparison Chart

2.4 Database

Of the available open source databases, MySQL & PostgreSQL are the widely popular

one. From the information available in the the Wikipedia some of the features of both have

been listed. Both PostgreSQL and MySQL support Not-Null, Unique, Primary Key. For-

eign Key constraints are supported by PostgreSQL and MySQLs InnoDB storage engine,

but not other engines. MySQL supports stored procedures, PostgreSQL supports stored

functions, which are in practice very similar. Both PostgreSQL and MySQL support

triggers. Replication is a database management systems ability to duplicate its stored

data for the purposes of backup safety and is one way to prevent database downtime.

PostgreSQL and MySQL both support replication. But support for MySQL is found to

be more compared to the PostgreSQL.

11

Chapter 3

Design Model

3.1 iPDC WAMS Architecture

Figure 3.1: WAMS Architecture

This architecture enables iPDC to receive data either from a PMU or any other PDC.

However both PMU and PDC from which the data is being received need to be IEEE

C37.118 Standard compliant. It is a hybrid architecture. As shown in the Figure 3.1,

iPDC at level1 accepts data from PMUs. iPDC at level 2 receives data from iPDCs at

level 1. Besides this it also accepts data from 2 other PMUs.

12

3.1.1 iPDC Design

The client server architecture is common in networks when two entities are commini-

cating with each other. In WAMS too, of the two entities(PMU and iPDC) that are

communicating with each other one has to be client and the other a server. The PMU

being a receiver of command frames which serve as requests is a server. It listens for com-

mand frames from iPDC. PMU can communicate either in TCP or UDP communication

protocol on two different ports. On receiving command frames, it replies to the iPDC

with data or configuration frames according to the type of request.

Figure 3.2: iPDC Design

iPDC functionality is bifurcated as server and client.

iPDC as a Client - When iPDC receives data or configuration frames its acts as a client.

When acting as a client, it creates a new thread for each PMU or a PDC from whom it

is going to receive data/configuaration frames. This thread would establish connection

between the two communication entities. It handles both TCP and UDP connections.

The first frame that the server(PMU/iPDC) would receive is the command for sending the

configuration frame. When the server replies with the configuration frame, iPDC(client)

13

would generate another request to start sending the data frames. On receiving such a

command frame, the server starts sending the data frames. If there is some change in the

status bits of data frame which the client(iPDC) notices, it would take an action. For

example if it notices a bit 10 has been set, it would internally send a command to server

to send the latest configuartion frame.

iPDC as a Server- When iPDC receives command frames from another iPDC it would

acts as a server. There would be two reserved ports one for UDP and other for TCP on

which the PDC would receive command frame requests. Thus iPDC now plays the role of

PMU waiting for command frames. Figure 3.7 shows the both the parts of iPDC, client

& server.

3.1.2 iPDC Working

PMUs/iPDC’s act as servers when they are communicating with another iPDC whom

they are sending the data/configuration frames. The iPDC receiving data in this case

acts as a client. However when the same iPDC sends data to another iPDC, it would act

as a server. This pattern will be repeated in the WAMS topology with one peer acting as

server and its counterpart a client.

The iPDC when acting as a server binds to 2 ports UDPPORT and TCP-

PORT. It would be listening for UDP connections on UDPPORT and TCP connections on

TCPPORT. The iPDC can then send the combined configuration frames to any number

of other iPDC’s. Both the communicating peers authenticate each other. iPDC authenti-

cates for each received packets irrespective of communcation protocols used(TCP/UDP).

When the iPDC starts for the first time the user is prompted to enter iPDC Idcode, UDP

Port, TCP Port and Database Server IP. The ports enable iPDC to receive requests from

other iPDC and to send the combined data and configuration frames. Database Server IP

is the IP address of the machine where the process dbserver is running. The default port

on which dbserver is listening for data is 9000 and it is a UDP server. The data which

the iPDC receives would also be directed to dbserver for storage in MySQL database.

14

Figure 3.3: PMU - iPDC communication

The user is provided with the following options at iPDC

• Enter iPDC Setup

• Add a Source Device

• Remove a Source Device

• Turn OFF the data Transmission

• Turn ON the data Transmission

• Request Configuration frame

• Add a Destination Device

• Remove a Destination Device

• iPDC Connection Table

Enter iPDC Setup

This is the first pop up window that would ask the user to enter the iPDC setup

information. It includes UDP & TCP ports on which the iPDC would receive command

frame requests from other iPDC’s. The two ports should be different. The combined data

and configuration frames would be sent on these ports. iPDC Idcode & IP address of the

machine where the data would be stored in MySQL database is also entered.

15

Add a Source Device

This would make an entry in the file ipaddress.txt for each newly added PMU. Before

making the entry it would check if there is already a connection with the same node. If

so, no entry is made. Otherwise a new thread would be created for connection with the

device based on type of the protocol that have been selected by user (TCP/UDP). Also

a new node of the type Lower Layer Details would be created.

Remove a Source Device

This would display the user with available PMU node entries and would prompt the

user to enter the details of node to be removed. When user enters the correct details, the

PMU node entry would be removed from the fie ipaddress.txt. Also the corresponding

Lower Layer Details node would be removed from doubly LL. A signal would be sent to

the thread that handles this connection. On receival of the signal the thread would close

the socket and exit.

Turn OFF the data Transmission

This would display the user with available PMU entries and would prompt the user

to enter the details of node whose data transmission is to be put off. When user en-

ters the correct details, the command frame would be sent to that node. The flag

data transmission off of the corresponding node in Lower Layer Details structure dou-

bly LL would be set.

Turn ON the data Transmission

This would display the user with available PMU entries whose data transmission has

been put off and would prompt the user to enter the details of node whose data trans-

mission is to be put on. When user enters the correct details, the command frame to

put off data tramsission would be sent to that node. The flag data transmission off of

the corresponding node in Lower Layer Details structure doubly LL would be reset to 0.

Figure 3.4 shows how the iPDC works when a data frame is received.

16

Figure 3.4: Data Frame Arrival at iPDC

Request Configuration frame

This would display the user with available PMU entries and would prompt the user

to enter the details of node to whom the configuration frame request is to be sent. When

user enters the correct details, the command frame to send the configuration frame would

be sent to that node. Figure 3.5 shows how the iPDC works when a configuration frame

is received.

17

Figure 3.5: Configuration Frame Arrival at iPDC

Add a Destination Device

An entry is made in the file upperpdc ip.txt. Also a node of the type Upper Layer Details

is created. It includes ip, port and protocol details of other iPDC. iPDC when act-

ing as a server may get connection requests on 6000 and 6001 ports for UDP and TCP

repectively. The received command frames are authenticated against the entries in the

Upper Layer Details doubly LL. If the command frame is for configuration frame then,

check is made if there are no Idcodes in the status change pmupdcid.

status change pmupdcidıs a LL which maintains the idcodes of all PMUs whose con-

figuration has beed changed. If the list is not empty, till the list is empty the config-

uration frame wontt be sent. When a new Configuration frame of the corresponding

ID codes arrives then its entry is removed from the list. After the list is empty cre-

ate cfgframe() is called that creates combined configuration frame from configuration

objects. Then the flag UL upper pdc cfgsent in the corresponding Upper Layer Details

node of the PDC is set. If the command frame is for data then, UL upper pdc datasent

is set and UL data transmission off in the corresponding Upper Layer Details node of

the iPDC is reset. The functions dispatch() in align sort() will send the combined

data on one of the sockets by checking the variables UL use udp, UL upper pdc cfgsent

and UL data transmission off. If the command frame is for data transmisssion off then

UL data transmission off in the corresponding Upper Layer Details node is set.

18

Remove a Destination Device

This would remove the iPDC entry from the file upperpdc ip.txt. Also the correspond-

ing node of the type Upper Layer Details would be removed from the doubly LL.

iPDC Connection Table

This would display the connections tables showing PMU and iPDC details to which

the iPDC is connected. There may be case when the iPDC terminates. In that case all the

Figure 3.6: Connection Tables

configuration objectsin memory will be lost. To handle this case the file cfg.bin contains

all the configuration frames. When the iPDC is restarted the file is read line by line and

configuration objects are recreated in the memory.

19

Figure 3.7: Recreate configuration objects

3.1.3 iPDC Implementation Details

The code is distributed in the following files

• iPDC.c

• ipdcGui.c

• ipdcGui.h

• recreate.c

• recreate.h

• connections.c

• connections.h

• new pmu or pdc.c

• new pmu or pdc.h

• parser.c

• parser.h

20

• dallocate.c

• dallocate.h

• align sort.c

• align sort.h

• global.h

iPDC.c

It is the file that contains the main(). It internally calls 2 functions

• void recreate cfg objects()

• void setup()

ipdcGui.c

It is the file that contains all the GUI functions for iPDC

• int isNumber(char *s)

• void destroy (GtkWidget *widget, gpointer udata)

• void display pdc detail (GtkButton *widget, gpointer udata)

• void about ipdc (GtkButton *widget, gpointer udata)

• void ipdc help (GtkButton *but, gpointer udata)

• void validation result (char *msg)

• void ipdc colors ()

• void pdc details (GtkButton *button, gpointer udata)

• void fill pdc details ()

• int validation pdc detail (GtkButton *button, gpointer udata)

• void add pmu (GtkButton *but, gpointer udata)

• int add pmu validation (GtkButton *but, gpointer udata)

• void cmd or remove pmu (GtkButton *but, gpointer udata)

• int cmd or remove pmu validation (GtkButton *but, gpointer udata)

21

• void add new pdc (GtkButton *but, gpointer udata)

• int new pdc validation (GtkButton *but, gpointer udata)

• void remove pdc (GtkButton *but, gpointer udata)

• int remove pdc validation (GtkButton *but, gpointer udata)

• void connection table (GtkButton *but, gpointer udata)

Functions in recreate.c

• void recreate cfg objects()

• void init cfgparser(unsigned char st[])

• void recreate Connection Table()

Functions in connections.c

• void setup()

• void sigchld handler()

• void* UL udp()

• void* UL tcp()

• void* UL tcp connection(void * newfd)

• void PMU process UDP(unsigned char *,struct sockaddr in,int sockfd)

• void PMU process TCP(unsigned char tcp buffer[],int sockfd)

Functions in new pmu or pdc.c

• int add PMU(char pmuid[], char ip[], char port[], char protocol[])

• void* connect pmu tcp(void *temp)

• void* connect pmu udp(void *temp)

• int remove Lower Node(char pmuid[], char protocol[])

• void* remove llnode(void*)

• int put data transmission off(char pmuid[], char protocol[])

• void* data off llnode(void* temp)

22

• int put data transmission on(char pmuid[], char protocol[])

• void* data on llnode(void* temp)

• int configuration request(char pmuid[], char protocol[])

• void* config request(void* temp)

• int add PDC(char ip[], char protocol[])

• int remove PDC(char ip[], char port num[], char protocol[])

• void display CT()

• void create command frame(int type,int pmuid,char *)

• int checkip(char ip[])

Functions in parser.c

• void cfgparser(unsigned char [])

• int remove old cfg(unsigned char[])

• void dataparser(unsigned char[])

• int check statword(unsigned char stat[])

• void add pmuid from status change list(unsigned char idcode[])

• void remove id from status change list(unsigned char idcode[])

• unsigned int to intconvertor(unsigned char [])

• void long int to ascii convertor (long int n,unsigned char hex[])

• void copy cbyc(unsigned char dst[],unsigned char *s,int size)

• int ncmp cbyc(unsigned char dst[],unsigned char src[],int size)

• void byte by byte copy(unsigned char dst[],unsigned char src[],int index,int n)

• unsigned long int to long int convertor(unsigned char array[])

• uint16 t compute CRC(unsigned char *message,char length)

23

Functions in dallocate.c

• void free cfgframe object(struct cfg frame *cfg)

• void free dataframe object(struct data frame *df)

• void free 2darray(char** array, int x)

Functions in align sort.c

• void time align(struct data frame *df)

• void assign df to TSB(struct data frame *df,int index)

• void dispatch(int index)

• void sort data inside TSB(int index)

• void clear TSB(int index)

• void create dataframe(int index)

• void create cfgframe()

global.h

It contains the mutex variables and other global variables to be used across all the

files.

Detailed Description

recreate.c

• void recreate cfg objects()

recreate cfg objects() is present in the file recreate.c. When parsing the configu-

ration frame, along with configuration objects creation the configuration frame is

also written into file cfg.bin. If ./server aborts the configuration objects in the

memory would be lost. So on restarting the ./server this function call would read

the file cfg.bin and recreate configuration objects in memory. For this it calls

init cfgparser().

• void init cfgparser(unsigned char st[])

It is called by recreate cfg objects(). The function recreate cfg objects() reads file

’cfg.bin’ line by line. Each line is a pre-stored cfg objects. For each line read,

init cfgparser(line) is called which creates the objetcs in the memory.

• void recreate Connection Table()

24

connections.c

• void setup()

setup() is present in the file connections.c. It creates 2 sockets for UDP and TCP

each. Separate ports for each are maintained, UDPPORT for UDP and TCPPORT

for TCP so that the PMU can communicate using any communication protocol.

It creates 2 threads by calling void* UL udp and void* UL tcp. Threads that are

created are in NON-DETACHED mode. There is one more thread created by calling

void* ADD PMU PDC(). This is a prompt to user provided with a set of options

like add PMU etc. There is another socket created that binds to a port DBPORT

(default 9000). IP specified by the user when the PDC is started. This socket is to

send the data to a machine where dbserver is running.

• void sigchld handler()

• void* UL udp()

Handles UDP connections on port UDPPORT. Responsible for handling command

frames from iPDCs on a UDP communication protocol.

• void* UL tcp()

Accepts TCP connections of iPDC on port TCPPORT.

• void* UL tcp connection(void * newfd)

Responsible for handling command frames from iPDCs on a TCP communication

protocol.

• void PMU process UDP(unsigned char *,struct sockaddr in,int sockfd)

It checks the type of frame that has been received and calls appropriate parser.

If data frameıs received, then it calls data parser(). Based on the return value of

the data parser() take appropriate action such as if stat bit 10 is 1 then send the

command frame to PMU to send its configuration frame. If configuration frame is

received, then it calls cfgparser(). It also sends the command frame to PMU to start

sending its data frames. If commandframe is received the action to be taken is not

handled.

• void PMU process TCP(unsigned char tcp buffer[],int sockfd)

It checks the type of frame that has been received and calls appropriate parser.

If data frameıs received, then it calls data parser() present in file parser.c. Based

on the return value of the data parser() take appropriate action such as if stat bit

10 is 1 then send the command frame to PMU to send its configuration frame. If

configuration frame is received, then it calls cfgparser() present in file. It also sends

25

the command frame to PMU to start sending its data frames. If command frame is

received the action to be taken is not handled.

new pmu or pdc.c

• Explained under General working of iPDC

int add PMU(char pmuid[], char ip[], char port[], char protocol[]), int remove PDC(),

void add PMU(), void* connect pmu tcp(), void* connect pmu udp(), void add PMU Node(),

void remove Lower Node(), void* remove llnode(void*), void put data transmission off(),

void* data off llnode(void* temp),

void put data transmission on(), void* data on llnode(void* temp), void configura-

tion request(), void* config request(void* temp), void display CT()

• void create command frame(int type,int pmuid,char *)

This would create 3 kinds of command frames, Command to send the CFG, Com-

mand to send the data ,Command to put off the data transmission.

• int checkip(char ip[]) This function checks if the Ip address entered by the user

is a valid IP address.

parser.c

• void cfgparser(unsigned char [])

Similar to init cfgparser(frame) except the frame is now the frame that actually

comes from PMU over TCP/UDP. It parses and creates objects in memory.

• int remove old cfg(unsigned char[])

If a changed cfg arrives at iPDC then, this function repaces the old entry in the file

cfg.bin with the new frame.

• void dataparser(unsigned char[])

Parses the data frame and creates data objects in memory. It first checks the

configuartion objects that to find a match for a corresponding id. Then separates

the fields of the data frame and creates data objects. Since there are no separaters

for the data in data frame the corresponding configuration object gives these details.

For examples it contains the number of pmu data,phnmr, annmr etc. These numbers

can be used to separate the data frame by a fixed number of bytes. For example if

cfg objects says phnmr = 2, and format is rectangular for phasor, then we allocate

memory for 2 phasors and separate 16 characters from the existing data frame

from the current pointer position(As phasor with rectangular format and assuming

data coming hexadecimal form each phasor measurement in the data frame would

8 characters in length).

26

• int check statword(unsigned char stat[])

stat word in the data frame is the most important. It indicates the status of the data

block in the data frame. Hence we check the bits of of sts word. As per the error

indications mentioned in the IEEEC37.118 Standard for each bit in the stat word

we make a print on console. It reurn the bit numbers as errors.The programmer has

reserved bits 03-00 whose value as 1111 or Fındicates the data has not arived for

that PMU. This is set and is useful when a iPDC sends a combined data frame to

other iPDC.

• void add pmuid from status change list(unsigned char idcode[])

If the error is pertaining to configuration change of PMU/iPDC then we add the

its entry to a status change pmupdcid which is a linked list maintaining the ids of

all PMU/iPDC under the current iPDC whose status related to configuration has

been changed.

• void remove id from status change list(unsigned char idcode[])

When a new configuration frame is received and there is call to cfgparser(), there is

a call within this cfgparser() for a remove id from status change list(char idcode[]).

It looks if its idcode is in the list status change pmupdcid . If so it removes its entry

from the list.

• unsigned int to intconvertor(unsigned char [])

Converts the binary 2 byte unsigned character value to equivalent int.

• void long int to ascii convertor (long int n,unsigned char hex[])

Converts the unsigned long int value to a 4 byte unsigned character value.

• void copy cbyc(unsigned char dst[],unsigned char *s,int size)

Performs copy of size bytes to destination array.

• int ncmp cbyc(unsigned char dst[],unsigned char src[],int size)

Performs comaprison of size bytes of both arrays.

• void byte by byte copy(unsigned char dst[],unsigned char src[],

int index,int n)

Performs copy of size bytes to destination array from its index position to index +

n.

• unsigned long int to long int convertor(unsigned char array[])

Converts the binary 4 byte unsigned character value to equivalent unsigned long int.

• uint16 t compute CRC(unsigned char *message,char length) Calculates

checksum of a frame of size length.

27

dallocate.c

• void free cfgframe object(struct cfg frame *cfg)

Since we dynamically allocate memory to cfg objetcs we need to free it once our

task is done. This function does the same.

• void free dataframe object(struct data frame *df)

Since we dynamically allocate memory to data objetcs we need to free it once our

task is done. This function does the same.

• void free 2darray(char** array, int x)

Frees 2D Arrays that were allocated memory using malloc().

align sort.c

• void time align(struct data frame *df)

We use Circular queue to align the data frame objects as per their soc and fracsec.

The size of circular queue is defined as MAXTSB. This function finds the corrects

TSB[] and calls assign df to TSB() by passing the index of the TSB to which the

data frame object df is to be assigned to. Also if all TSB[] buffers are full it calls

dispatch(rear), clear TSB(rear), assign df to TSB(df,rear) in the same order.

• void assign df to TSB(struct data frame *df,int index)

It assigns df data frame object to the TSB[index] at the end of list as indicated by

struct data frame *first data frame. It traverses the end of the list of data frame

objects and then assigns df to the *dnext of last data frame object. Also if the

TSB[] is used for the first time it allocates memory to the member variables of the

TSB[index] and fills the ıdlistwith the pmu/pdc ids from whom data frames would

arrive.

• void dispatch(int index)

It internally calls void sort data inside TSB(index), void create dataframe(index),

clear TSB(index) in the same order.

• void sort data inside TSB(int index)

This function will sort the data frame object LL as per the ids in ıdlistLL.

• void clear TSB(int index)

This will clear TSB[index] member variables to 0 .

• void create dataframe(int index)

This will create combined data frame to be sent to a Destination PDC when a

command frame is received.

28

• void create cfgframe()

This will create combined configuration frame to be sent to a Destination PDC when

a command frame is received.

Data Structures Used

• Data Structure for Configuration Frame

cfg frame, for each pmu, channel names, dgnames, format are the data structures

defined for the configuration frame. format ıs an additional data structure that

has been defined. It simplifies the task of distinguishing the measurements as float-

ing/fixed, polar/rectangular. As per IEEEC37.118 Synchrophasor Standard, format

field in configuration frame is 2 bytes (4 characters in hexadecimal). See figure 3.8.

• Data Structure for Data Frame

data frame and data for each pmu are the data structures defined for data frames.

See figure 3.9

• Data Structure to store IDs of those PMU/iPDC whose CFG has changed

status change pmupdcid the data structure defined to maintain the idcodes of PMU/iPDC

whose configuration has been changed. Id remaining in the memory till new Con-

figuration object for that idcode arrives. See figure 3.10

• Data Structure to store Source Device Details

Lower Layer Details is the data structure defined to maintain the the details of

source devices from which iPDC receives the data. See figure 3.11

• Data Structure to store Destination Device Details

Upper Layer Details is the data structure defined to maintain the the details of

destination devices to which iPDC sends the data. See figure 3.12

29

struct cfg_frame {

unsigned char *framesize;

unsigned char *idcode;

unsigned char *soc;

unsigned char *fracsec;

unsigned char *time_base;

unsigned char *num_pmu;

struct for_each_pmu **pmu;

unsigned char *data_rate;

struct cfg_frame *cfgnext;

}*cfgfirst;

struct for_each_pmu{

unsigned char *stn;

unsigned char *idcode;

unsigned char *data_format;

struct format *fmt;

unsigned char *phnmr;

unsigned char *annmr;

unsigned char *dgnmr;

struct channel_names *cnext;

unsigned char **phunit;

unsigned char **anunit;

unsigned char **dgunit;

unsigned char *fnom;

unsigned char *cfg_cnt;

};

struct channel_names {

unsigned char **phnames;

unsigned char **angnames;

struct dgnames *first;

};

struct dgnames {

unsigned char **dgn;

struct dgnames *dg_next;

};

struct format{

unsigned char freq;

unsigned char analog;

unsigned char phasor;

unsigned char polar;

};

Figure 3.8: Data Structure for Configuration Frame30

struct data_frame {

unsigned char *framesize;

unsigned char *idcode;

unsigned char *soc;

unsigned char *fracsec;

int num_pmu;

struct data_for_each_pmu **dpmu;

struct data_frame *dnext;

};

struct data_for_each_pmu {

unsigned char *stat;

int phnmr;

int annmr;

int dgnmr;

struct format *fmt;

unsigned char **phasors;

unsigned char **analog;

unsigned char *freq;

unsigned char *dfreq;

unsigned char **digital;

};

Figure 3.9: Data Structure Data Frame

struct status_change_pmupdcid {

char idcode[5];

struct status_change_pmupdcid *pmuid_next;

}*root_pmuid;

Figure 3.10: Data Structure PMU Status Change

31

struct Lower_Layer_Details {

unsigned int pmuid;

char ip[16];

int port;

char protocol[4];

int sockfd;

int up; //used only in tcp

struct sockaddr_in llpmu_addr;

pthread_t thread_id;

int data_transmission_off;

int pmu_remove;

int request_cfg_frame;

struct Lower_Layer_Details *next;

struct Lower_Layer_Details *prev;

}*LLfirst,*LLlast;

Figure 3.11: Data Structure Source Device Details

struct Upper_Layer_Details {

char ip[16];

int port;

char protocol[4];

int sockfd;

struct sockaddr_in pdc_addr;

int config_change;

int UL_upper_pdc_cfgsent;

int UL_data_transmission_off;

int address_set;

struct Upper_Layer_Details *next;

struct Upper_Layer_Details *prev;

}*ULfirst,*ULlast;

Figure 3.12: Data Structure Destination Device Details

32

3.2 Database Design

3.2.1 DbServer Working

iPDC when receives data/configuartion frames would also direct the frames to another

process called DBServer. DBServer may run on the same machine or a remote machine.

This process acts as database server. Among the various known opensource databases,

MySQL has been used for storing the PMU/iPDC data. The process would have a

parser to parse configuration and data frames. After parsing, configuration and data

frames entries would be stored in the iPDC MySQL database. If a configuration frame

for a newly added PMU arrives, it would be inserted in the configuration tables. If

configuration frame for a previously added PMU arrives, then the previous entry in the

tables is updated. The data frames are inserted as they come. This data which is stored

in the tables can then be used for later analysis. The data from the database is archived

periodically. See figure 3.13.

Figure 3.13: DBServer Process

33

3.2.2 DbServer Implementation Details

The code is distributed in the following files

• dbServer.c

• recreate.c

• recreate.h

• connections.c

• connections.h

• parser.c

• parser.h

• dallocate.c

• dallocate.h

• global.h

dbServer.c

It is the file that contains the main(). It internally calls 2 functions

• void recreate cfg objects()

• void setup()

Functions in recreate.c

• void recreate cfg objects()

• void init cfgparser(unsigned char st[])

Functions in connections.c

• void setup()

• void DB udp()

• void* DB udphandler(void * udp BUF)

• void DB process UDP(unsigned char* udp BUF)

34

Functions in parser.c

• void cfgparser(unsigned char [])

• void cfginsert(struct cfg frame *)

• int remove old cfg(unsigned char[])

• void dataparser(unsigned char[])

• int check statword(unsigned char stat[])

• unsigned int to intconvertor(unsigned char [])

• unsigned long int to long int convertor(unsigned char array[])

• float decode ieee single(const void *v)

• void copy cbyc(unsigned char dst[],unsigned char *s,int size)

• int ncmp cbyc(unsigned char dst[],unsigned char src[],int size)

Functions in dallocate.c

• void free cfgframe object(struct cfg frame *cfg)

• void free dataframe object(struct data frame *df)

• void free 2darray(char** array, int x)

global.h

It contains the mutex variables and other global variables to be used across all the

files.

Detailed Description

recreate.c

Same as described above in recreate.c

connections.c

• void setup()

This function created MySQL database connection and also binds to UDP port

9000.

35

• void DB udp()

It receives the udp data from iPDC, creates a thread by calling DB udphandler()

and passes the data to it.

• void* DB udphandler(void * udp BUF) Internally it calls DB process UDP().

• void DB process UDP(unsigned char* udp BUF)

It checks the type of frame that has been received and calls appropriate parser. If

data frame ıs received, then it calls data parser(). If configuration frame is received,

then it calls cfgparser().

parser.c

• void cfgparser(unsigned char [])

Similar to init cfgparser(frame) it parses and creates objects in memory.

• void cfginsert(struct cfg frame *)

Insert/Update the configuration frame in the configuration tables.

• int remove old cfg(unsigned char[])

If a changed cfg arrives at iPDC then for a PMU, this function repaces the old entry

in the file cfg.bin with the new frame.

• void dataparser(unsigned char[])

Parse the data frame an insert into the data tables of iPDC database.

• int check statword(unsigned char stat[])

stat word in the data frame is the most important. It indicates the status of the data

block in the data frame. Hence we check the bits of of sts word. As per the error

indications mentioned in the IEEEC37.118 Standard for each bit in the stat word

we make a print on console. It reurn the bit numbers as errors.The programmer has

reserved bits 03-00 whose value as 1111 or Fındicates the data has not arived for

that PMU. This is set and is useful when a PDC sends a combined data frame to

other iPDC.

• unsigned int to intconvertor(unsigned char [])

Converts the binary 2 byte unsigned character value to equivalent int.

• unsigned long int to long int convertor(unsigned char array[])

Converts the binary 4 byte unsigned character value to equivalent long int.

• float decode ieee single(const void *v)

Converts the binary 4 byte unsigned character value to equivalent float value.

36

• void copy cbyc(unsigned char dst[],unsigned char *s,int size)

Performs copy of size bytes to destination array.

• int ncmp cbyc(unsigned char dst[],unsigned char src[],int size)

Performs comaprison of size bytes of both arrays.

dallocate.c

Same as describe above.

Data Structures Used

• Data Structure for Configuration Frame

cfg frame, for each pmu, channel names, dgnames, format are the data structures

defined for the configuration frame. format ıs an additional data structure that

has been defined. It simplifies the task of distinguishing the measurements as float-

ing/fixed, polar/rectangular. As per IEEEC37.118 Synchrophasor Standard, format

field in configuration frame is 2 bytes (4 characters in hexadecimal). See figure 3.14.

• Data Structure for Data Frame

data frame and data for each pmu are the data structures defined for data frames.

See figure 3.15.

37

struct cfg_frame {

unsigned int framesize;

unsigned int idcode;

unsigned long int soc;

unsigned long int fracsec;

unsigned long int time_base;

unsigned int num_pmu;

struct for_each_pmu **pmu;

unsigned int data_rate;

struct cfg_frame *cfgnext;

}*cfgfirst;

struct for_each_pmu{

unsigned char stn[17];

unsigned int idcode;

char data_format[3];

struct format *fmt;

unsigned int phnmr;

unsigned int annmr;

unsigned int dgnmr;

struct channel_names *cnext;

float **phunit;

float **anunit;

unsigned char **dgunit;

unsigned int fnom;

unsigned int cfg_cnt;

};

struct channel_names {

unsigned char **phnames;

unsigned char **angnames;

struct dgnames *first;

};

struct dgnames {

unsigned char **dgn;

struct dgnames *dg_next;

};

struct format{

char freq;

char analog;

char phasor;

char polar;

};

Figure 3.14: Data Structure for DBServer Configuration Frame38

struct data_frame {

unsigned char *framesize;

unsigned char *idcode;

unsigned char *soc;

unsigned char *fracsec;

int num_pmu;

struct data_for_each_pmu **dpmu;

struct data_frame *dnext;

};

struct data_for_each_pmu {

unsigned char *stat;

int phnmr;

int annmr;

int dgnmr;

struct format *fmt;

unsigned char **phasors;

unsigned char **analog;

unsigned char *freq;

unsigned char *dfreq;

unsigned char **digital;

};

Figure 3.15: Data Structure for DBServer Data Frame

Script db.sql gives the DDL statements to create the schema. In the MySQL database

named openPDC there are 9 tables namely:-

• MAIN CFG TABLE

• SUB CFG TABLE

• PHASOR

• ANALOG

• DIGITAL

• PHASOR MEASUREMENTS

• ANALOG MEASUREMENTS

• FREQUENCY MEASUREMENTS

• DIGITAL MEASUREMENTS

39

Configuration frames entries are stored in MAIN CFG TABLE, SUB CFG TABLE,

PHASOR, ANALOG, DIGITAL. Data frames entries are stored in PHASOR MEASUREMENTS,

ANALOG MEASUREMENTS, FREQUENCY MEASUREMENTS,

DIGITAL MEASUREMENTS. Figure 3.16 shows the functional dependencies of the

tables.

Figure 3.16: iPDC Database

40

Chapter 4

Experiments & Results

4.1 Test Cases

iPDC application was tested at different levels in WAMS toplology. Its performance

interms of memory usage & CPU utilization was noted. The hardware details of machines

on which iPDC was installed is listed in the table 4.1.

Figure 4.1: Resource Details

41

1. Test Case 1

This is a basic test with only 2 levels. level 0 contains 4 PMU Simulators & level 1

contains 1 iPDC. In this test, iPDC was receiving the data from four PMU simula-

tors. Figure 4.2 shows the setup.

Figure 4.2: Case1

2. Test Case 2

In this case we have taken three levels. Level 0 contains 5 PMU Simulators, level 1

contains 2 iPDCs and level 2 contains 1 iPDC. One iPDC from level 1 was receiving

data from 3 PMU Simulators & other iPDC was receiving data from 2 PMU Simu-

lators. The level 2 iPDC was receiving data from both iPDCs of level 1. It was also

receiving data from level 2 PMU Simulator. Figure 4.3 shows the setup.

Figure 4.3: Case2

42

3. Test Case 3

This setup is same as described in the Test Case 2 except in this case the level 2

iPDC is sending the data to database server running on the same machine. We

have analyzed the load on the system when the database server is on same machine.

When the database server was run on remote machine the load & performance of

the system was found to be the same as in the test case 2. Figure 4.4 shows the

setup.

Figure 4.4: Case3

4. Test Case 4

In order to find the maximum capacity of iPDC we had run 40 PMU Simulators at

level 0 & 1 iPDC at level 1. However the results show that only 25% of resources

were utilized. So iPDC can handle even more number of PMUs. Figure 4.5 shows

the setup.

43

Figure 4.5: Case4

Resources usage of the machine on which topmost iPDC was run is listed in the Figure

( 4.6)

Figure 4.6: Resources Usage

44

Chapter 5

Conclusion and Future Work

Conclusion

PMU-PDC communication over UDP/TCP provides the user with an option to se-

lect between fast and unreliable delivery of packets with UDP and reliable delivery with

TCP. MySQL has an advantage over other open source databases like PostgreSQL in

performance & support. iPDC was able to handle data from 20 PMUs and can still be

improved to increase this number. Use of Linux OS and other open source tools in the

development of iPDC has provided easy portability of software on Real Time Operating

Systems like RTLinux, RTai etc. Use of RTOS can necessarily further speed up operation

carried out by iPDC in real time compared to the normal Linux OS. As iPDC has been

released under General Public License(GPL), more contributions can be expected from

the free and open source community.

Future Work

The future work will involve the following:

1. Need to study and implement iPDC on RTOS and check its performance & scala-

bility in Real Time.

2. An upper time bound need to be kept for the packtes received at iPDC.

3. Different aspects of security in WAMS need to studied and implemented.

4. Study of how iPDC can serve as an input to real time control & decision making

need to be done.

5. On field testing of iPDC application need to be done to know its performance &

limitations.

6. iPDC has to be updated to support more PMU standards.

45

Chapter 6

Bibliography

1. Ken Martin, “IEEE Standard for Synchrophasors for Power Systems” IEEE Std

C37.118 -2005, Revision of IEEE Std 1344-1995.

2. “Real Time Wide-Area Monitoring, Control and Protection” EIPP Real Time Task

Team, White Paper DRAFT 3: Wide Area Monitoring-Control Phasor Data Re-

quirements.

3. Andrew Armenia, “A Flexible Phasor Data Concentrator Design Leveraging Existing

Software Technologies” IEEE Transactions on Smart Grid, vol. 1, no. 1, June 2010.

4. Moustafa Chenine, “Investigation of Communication Delays and Data Incomplete-

ness in Multi-PMU Wide Area Monitoring and Control Systems“, the Swedish Cen-

tre of Excellence in Electric Power Engineering ELEKTRA project 36005.

5. Yingchen Zhang, Richard ”Wide-Area Frequency Monitoring Network (FNET) Ar-

chitecture and Applications“, IEEE IEEE Transactions on Smart Grid, vol. 1, no.

2, september 2010.

6. M.D. Hadley, J.B. McBride, T.W. Edgar, ”Securing Wide Area Measurement Sys-

tems”, June 2007 Prepared for U.S. Department of Energy.

46