iPDC Report Kedar

Design and Implementation of Communication,
Storage & Archival of IEEEC37.118 Standard based
Wide Area Measurement System

Project Report
Submitted in partial fulﬁllment of the requirements for the degree of
Master of Technology

by
Kedar Khandeparkar
Roll No : M0911C04
under the guidance of
Prof. V.Z. Attar
College of Engineering, Pune
Prof. A.M. Kulkarni
Indian Institute of Technology, Bombay
Prof. S.A. Soman

Department of Computer Science & Engineering
College of Engineering, Pune

June 2011

DEPARTMENT OF COMPUTER ENGINEERING
AND INFORMATION TECHNOLOGY,
COLLEGE OF ENGINEERING, PUNE

CERTIFICATE

Certiﬁed 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 fulﬁlment 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
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 diﬀerent 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 ﬁnds 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 ﬁrst 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 beneﬁts
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. PMU´ are located at substation from where
s
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 PDC´ over low bandwidth con-
s
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 PMU´ or PDC´ is
s s
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 PMU´ are placed.
s

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- x
PMU -y/ PDC-z

CMD Frame- Send CFG Frame

CFG Frame

CMD Frame-Send Data Frame

Data Frame-1

Data Frame-2

Data Frame-n

Stat word change
detected
CMD Frame- Send CFG Frame

CFG Frame

CMD Frame-Send Data Frame

Data Frame-x

Data Frame-x+1

CMD Frame- Data Transmission off

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 ïme-stamped measured values¨ These measured values are simply
t .
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 ïme-alignedwith other incoming
t ¨
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

SYN (Seq=x)

Seq=y, ACK=x+1

Seq=x+1, ACK=y+1

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
PMU´. It is a versatile PDC software as it supports diﬀerent PMU standards such
s
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 speciﬁcally 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., Microsoft´ StreamInsight
s
CEP Platform, OSIsoft´ PI Historian, etc.) The openPDC will have a broad range
s

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 PDC´, and is available on Windows or UNIX/Linux systems.
s
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 MySQL´ InnoDB storage engine,
s
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 system´ ability to duplicate its stored
s
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 PMU´. iPDC at level 2 receives data from iPDC´ at
s s
level 1. Besides this it also accepts data from 2 other PMU´.
s

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
PMU´/iPDC’s act as servers when they are communicating with another iPDC whom
s
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 ´f the corresponding node in Lower Layer Details structure dou-
o
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 ´f o
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 ´tatus change pmupdcid´
s .
´tatus change pmupdcid´ a LL which maintains the idcodes of all PMU´ whose con-
s ıs s
figuration has beed changed. If the list is not empty, till the list is empty the config-
uration frame wont´ be sent. When a new Configuration frame of the corresponding
t
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 conﬁguration objects

3.1.3 iPDC Implementation Details
The code is distributed in the following ﬁles

• 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 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 conﬁguration request(char pmuid[], char protocol[])

• void* conﬁg 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

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().

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 iPDC´ on a UDP communication protocol.
s

• void* UL tcp()
Accepts TCP connections of iPDC on port TCPPORT.

• void* UL tcp connection(void * newfd)
Responsible for handling command frames from iPDC´ on a TCP communication
s
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´ received, then it calls data parser(). Based on the return value of
ıs
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 ónfiguration ´
c frame is
received, then it calls cfgparser(). It also sends the command frame to PMU to start
sending its data frames. If ómmand´
c frame 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´ received, then it calls data parser() present in file parser.c. Based
ıs
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
ónfiguration ´
c 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 ómmand ´
c 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

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.

If a changed cfg arrives at iPDC then, this function repaces the old entry in the file
cfg.bin with the new frame.

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

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 ´tatus change pmupdcid which is a linked list maintaining the ids of
s ´
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 ´tatus change pmupdcid ´ If so it removes its entry
s .
from the list.

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.

Performs copy of size bytes to destination array.

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.

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

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.

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 id´ from whom data frames would
´ s
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 id´ in ´ ´
s ı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 ´ an additional data structure that
ıs
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 ID´ of those PMU/iPDC whose CFG has changed
s
´tatus change pmupdcid ´he data structure defined to maintain the idcodes of PMU/iPDC
s t
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 *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 Conﬁguration Frame
30

struct data_frame {

unsigned char *soc;
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 ﬁles

• 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 ﬁle that contains the main(). It internally calls 2 functions


• void setup()

Functions in recreate.c


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 cfginsert(struct cfg frame *)






• ﬂoat decode ieee single(const void *v)



Functions in dallocate.c

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


global.h
It contains the mutex variables and other global variables to be used across all the
ﬁles.

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 ´ received, then it calls data parser(). If ónfiguration ´
´ ıs c frame is received,
then it calls cfgparser().

parser.c

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.

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.

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

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.

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

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

Performs copy of size bytes to destination array.

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 ´ an additional data structure that
ıs
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;
};

38
Figure 3.14: Data Structure for DBServer Conﬁguration Frame

struct data_frame {

unsigned char *soc;
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

Conﬁguration 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 diﬀerent 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 ﬁnd 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 PMU´ and can still be
s
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. Diﬀerent 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 ﬁeld 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

iPDC Report Kedar

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

Similaire à iPDC Report Kedar

Similaire à iPDC Report Kedar (20)

Dernier

Dernier (20)

iPDC Report Kedar