ELECTRIC POWER SYSTEM STATE

ESTIMATION
Project Work Report

Submitted in partial fulfillment of the requirements for the degree of

BACHELOR OF TECHNOLOGY
in
ELECTRICAL AND ELECTRONICS ENGINEERING

by

ADITYA S MILIND R NARAYANAN S

07EE04 07EE33 07EE37

Under the guidance of

Dr. UDAYKUMAR R.Y.

Professor

DEPARTMENT OF ELECTRICAL AND ELECTRONICS ENGINEERING

NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA
SURATHKAL- 575025
April, 2011

i
 DECLARATION

We hereby declare that the Project Work Report entitled Electric Power System State
Estimation which is being submitted to the National Institute of Technology Karnataka,
Surathkal for the award of the Degree of Bachelor of Technology in Electrical and
Electronics Engineering is a bonafide report of the work carried out by us. The material
contained in this Project Work Report has not been submitted to any University or Institution for
the award of any degree.

1) 07EE04 Aditya S _____________

2) 07EE33 Milind R _____________

3) 07EE37 Narayanan S ____________

Place: NITK, SURATHKAL

Date: 28/04/2011

ii
DEPARTMENT OF ELECTRICAL AND ELECTRONICS
ENGINEERING
NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA,
SURATHKAL

CERTIFICATE

This is to certify that the B.Tech Project Work Report entitled “Electric Power
System State Estimation” submitted by:

1) 07EE04 Aditya S
2) 07EE33 Milind R
3) 07EE37 Narayanan S

as the record of the bonafide work carried out by them, is accepted as the B.Tech
Project Work Report submission in partial fulfillment of the requirements for the
award of degree of Bachelor of Technology in Electrical and Electronics
Engineering.

Under the guidance of

Dr. Udaykumar R.Y. Dr. K.P. Vittal

Guide Head of Department

iii
 ACKNOWLEDGEMENT

We would like to express our sincere gratitude to our honorable guide

Dr.Udaykumar R.Y., Department of Electrical and Electronics Engineering for his
total guidance and complete association in the making of our B. Tech Project. We
thank him for his overall supervision as the project guide. We also thank him for his
valuable suggestions to refer new topics and latest papers which in fact proved to be
a valuable activity. We are grateful to Dr. K.P. Vittal, Head of the Department of
Electrical and Electronics Engineering, for making all the facilities available. We
also thank all the laboratory staff for providing us with all the required resources for
successful completion of the project.

iv
 ABSTRACT

State estimation is the process of determining an acceptable probable future state of a system
in the face of noisy and incomplete output measurements. State Estimation takes all the
telemetry seen so far and uses it to determine the underlying behavior of the system at any
point in time. It includes fault detection and isolation and continuous system parameter
estimation.

In the power transmission network, substation buses are equipped with measuring devices to
sense voltage at, and real power, reactive power and current through every line from that bus.
All these are relayed to load dispatch centers. As only a fraction of these measurements are
essential for analysis of the power system, the remaining measurements are harnessed to
generate confidence values that determine the acceptability of a measurement.

A neural network is a massively parallel distributed processor made up of simple processing

units, which has a natural propensity for experiential knowledge and making it available for
use.In more practical terms neural networks are non-linear statistical data modeling or decision
making tools. They can be used to model complex relationships between inputs and outputs or
to find patterns in data.

The very probabilistic nature of state estimation makes it ideally suited to be implemented by
neural networks. The neural network is tasked with optimizing the parameters used for
statistical processing of noisy values. The learning element of the neural network allows the
state estimator to assign weights to the memory – ensuring that better estimates are
considered.

v
 TABLE OF CONTENTS
D E C L A R A T I O N............................................................................................................................... ii
CERTIFICATE .......................................................................................................................................... iii
ACKNOWLEDGEMENT ......................................................................................................................... iv
ABSTRACT ................................................................................................................................................. v
INTRODUCTION....................................................................................................................................... 2
1.1 ELECTRICITY IN INDIA’S GROWTH ........................................................................................... 2
1.2 MEASUREMENTS & MEASURING DEVICES.............................................................................. 2
1.3 SCADA AND THE SMART GRID ..................................................................................................... 3
1.4 TRANSMISSION AND DISTRIBUTION .......................................................................................... 4
1.5 STATE ESTIMATION ........................................................................................................................ 5
LITERATURE SURVEY ........................................................................................................................... 6
BASIC CONCEPTS AND DESIGN .......................................................................................................... 7
3.1 STATE ESTIMATION ........................................................................................................................ 7
3.1.1 TOPOLOGY PROCESSORS ........................................................................................................... 9
3.1.2 OBSERVABILITY ANALYSIS ..................................................................................................... 12
3.1.3 STATE ESTIMATION SOLUTION ............................................................................................. 14
3.1.4 BAD DATA PROCESSING ............................................................................................................ 15
IMPLEMENTATION AND RESULTS.................................................................................................. 16
CONCLUSION AND FUTURE SCOPE ................................................................................................ 22
REFERENCES .......................................................................................................................................... 23
APPENDIX A: CODE SNIPPET ............................................................................................................ 25

vi
1
 CHAPTER - 1

INTRODUCTION

1.1 ELECTRICITY IN INDIA’S GROWTH

Electricity is the prime mover of growth and is vital to the sustenance of a modern economy.
Hence the growth of the power sector and management of energy is critical for India's
development. The power sector in India is undergoing dramatic transformation with the
restructuring and unbundling of vertically integrated utilities and setting up of Regulatory
Commissions. India is world’s 6th largest energy consumer, accounting for 3.4% of global
energy consumption. Due to India’s economic rise, the demand for energy has grown at an
average of 3.6% per annum over the past 30 years. Electricity losses in India during transmission
and distribution are extremely high, about 28.44% (2008-09). India needs to tide over a peak
power shortfall of 13% between 5pm and 11pm by reducing losses due to theft and pilferage.
Due to shortage of electricity, power cuts are common throughout India and this has adversely
effected the country’s economic growth.

1.2 MEASUREMENTS & MEASURING DEVICES

To effectively monitor the power system condition, specialized measurement devices are
required, especially due to high potentials involved in electricity transmission. Direct
measurement of high voltages is possible up to about 200 kV, and several forms of voltmeters
have been devised which can be connected directly across the test circuit. High Voltages are
also measured by stepping down the voltage by using transformers and potential dividers. The
spark-over of sphere gaps and other gaps are also used, especially in the calibration of meters in
high voltage measurements. Transient voltages may be recorded through potential dividers and
oscilloscopes. Lightning surges may be recorded using the Klydonograph. At the circuit level
there are various techniques that can be used to measure current: Shunt resistor, Hall Effect
current sensor transducers, Transformer, Magneto resistive Field Sensors. Instrument
transformers are used for measuring voltage and current in electrical power systems, and
for power system protection and control. Where a voltage or current is too large to be
2
conveniently used by an instrument, it can be scaled down to a standardized, low value.
Instrument transformers isolate measurement, protection and control circuitry from the high
currents or voltages present on the circuits being measured or controlled.

1.3 SCADA AND THE SMART GRID

Supervisory Control and Data Acquisition (SCADA) are centralized systems that monitor and
control large arrays of systems. The control aspect is performed via Remote Terminal Units
(RTU) or Programmable Logic Controllers (PLC). Data is acquired from the RTUs and PLCs
and comprises the meter readings, equipment status reports. The acquired data is compiled for
the user to make the necessary supervisory decisions.

At present, SCADA systems are hardware PC based and possess a distributed architecture
through LAN. Open (non-proprietary) Databases like Oracle, Sybase etc are used. All the user
terminals are workstations. SCADA systems in the near future will involve novel concepts like
parallel processing, grid computing for large data storage, fault tolerance systems.

A smart grid, also known as an intelligent grid is an electricity network that employs
digital technology. It delivers electricity using two-way digital communications which could
save energy; reduce costs and increase reliability and transparency if the risks inherent in
executing massive information technology projects are avoided. This innovation is planned to
overlay the ordinary grid with an information and net metering system that uses smart meters.

Smart grids are necessitated for the following reasons:

 Open loop controls and human intervention inadequate for real time control actions
 Fast acting phenomena such as instability – angular/voltage requires closed loop controls
which detects and controls
 Online monitoring of parameters on substation equipment and immediate communication for
corrective maintenance Warehousing and data mining to facilitate MIS on maintenance
plans, resources deployment, disturbance analysis etc.
 Event based architecture to direct actions based on the event information for corrective
action.

3
1.4 TRANSMISSION AND DISTRIBUTION
The electricity is transported to load locations from a power station to a transmission subsystem.
Therefore we may think of the transmission system as providing the medium of transportation
for electric energy. The transmission system may be subdivided into the bulk transmission
system and the sub-transmission system. The functions of the bulk transmission are to
interconnect generators, to interconnect various areas of the network, and to transfer electrical
energy from the generators to the major load centers. This portion of the system is called "bulk"
because it delivers energy only to so-called bulk loads such as the distribution system of a town,
city, or large industrial plant. The function of the sub-transmission system is to interconnect the
bulk power system with the distribution system. Transmission circuits may be built either
underground or overhead. Underground cables are used predominantly in urban areas where
acquisitions of overhead rights of way are costly or not possible. They are also used for
transmission under rivers, lakes and bays. Overhead transmission is used otherwise because, for
a given voltage level, overhead conductors are much less expensive than underground cables.
The transmission system is a highly integrated system. It is referred to the substation equipment
and transmission lines. The substation equipment contains the transformers, relays, and circuit
breakers. Transformers are important static devices which transfer electrical energy from one
circuit with another in the transmission subsystem. Transformers are used to step up the voltage
on the transmission line to reduce the power loss which is dissipated on the way. A relay is
functionally a level-detector; they perform a switching action when the input voltage (or current)
meets or exceeds a specific and adjustable value. A circuit breaker is an automatically operated
electrical switch designed to protect an electrical circuit from damage caused by overload or
short circuit. A change in the status of any one component can significantly affect the operation
of the entire system. There are three possible causes for power flow limitations to a transmission
line. These causes are thermal overload, voltage instability, and rotor angle instability. Thermal
overload is caused by excessive current flow in a circuit causing overheating. Voltage instability
is said to occur when the power required to maintain voltages at or above acceptable levels
exceeds the available power. Rotor angle instability is a dynamic problem that may occur
following faults, such as short circuit, in the transmission system. It may also occur tens of
seconds after a fault due to poorly damped or undamped oscillatory response of the rotor motion.

4
1.5 STATE ESTIMATION
State estimation is the process of determining an acceptable probable future state of a system in
the face of noisy and incomplete output measurements. Proposed by Prof. Fred Schweppe et al at
the MIT EECS division, State Estimation takes all the telemetry seen so far and uses it to
determine the underlying behavior of the system at any point in time. It includes fault detection
and isolation and continuous system parameter estimation.

In the power transmission network, substation buses are equipped with measuring devices to
sense voltage at, and real power, reactive power and current through every line from that bus. All
these are relayed to load dispatch centers. As only a fraction of these measurements are essential
for analysis of the power system, the remaining measurements are harnessed to generate
confidence values that determine the acceptability of a measurement.

A neural network is a massively parallel distributed processor made up of simple processing

units, which has a natural propensity for experiential knowledge and making it available for use.
In more practical terms neural networks are non-linear statistical data modeling or decision
making tools. They can be used to model complex relationships between inputs and outputs or to
find patterns in data.

The very probabilistic nature of state estimation makes it ideally suited to be implemented by
neural networks. The neural network is tasked with optimizing the parameters used for statistical
processing of noisy values. The learning element of the neural network allows the state estimator
to assign weights to the memory – ensuring that better estimates are considered.

5
 CHAPTER - 2
LITERATURE SURVEY
In [1], A. Monticelli introduces and describes the basic concepts of state estimation.
Being an invited paper on the subject, it is a comprehensive treatise, and functions as a base for
most of the ideas in this project, in general.

[2] provides an in-depth perspective on Topology Processing. The need for dynamic
topology processing is recognized, and they describe their method in considerable detail. By
using these ideas as a spring board, the idea of using P-buses emerged as an effective way to
reduce the amount of data to be processed on each resample.

[4] introduces observability in general, and numerical observability in particular. After

learning about the process, we decided that floating point computation adds a severe load on the
processor, and that the advantages are over weighed by the disadvantages. Thus our aims shifted
towards topological observability.

[6] gives a beautiful introduction to topological observability and allows us to obtain

forests of full rank. Further processing from this stage was unclear from this paper.

We turned to [3] [7] [8] for the handling of forests of full rank, and to obtain maximal
observable subnetwork.

State Estimation is a highly mathematical procedure which is applied to electrical

engineering. As it is intrinsically mathematical and large scale, it is highly dependant upon the
state of the art computational techniques available or being used at that time. From the time of its
original proposition by Fred Schweppe, the computational science has come a long way and
hence the renewed interest in State Estimation. Recent developments in electrical engineering
like Smart Grid, SCADA have encouraged further study of this subject.

6
 CHAPTER – 3
BASIC CONCEPTS AND DESIGN

3.1 STATE ESTIMATION

State estimation is an integral part of power system control for stability and reliability. It is a
large scale, highly computationally intensive process, due to the sheer scale of the system being
analyzed and the very non-linear nature of the equations being solved. There has been much
interest of late in investigation of computational techniques that lend themselves to efficient
implementation on digital systems. One class of such techniques is inspired by natural
computational processes and is called Computational Intelligence (CI) of which Neural
Networks are part. We are interested in application of neural networks in the state estimation
process. The inherently non linear nature of Artificial Neurons is eminently suited to solve non-
linear algebraic equations such as those expressing power flows.

Power system state estimation (PSSE) is a technique for determining the system state from a
model of the power system network and redundant system measurements. The ability of the state
estimator to achieve a high level of efficiency and numerical robustness is of paramount
importance in today’s eclectic utility industry.

State estimation is interesting to engineers for at least two reasons:

 Often an engineer needs to estimate system states in order to implement a state feedback
controller. For example, the electrical engineer needs to estimate the winding currents of a
motor in order to control its position. The aerospace engineer needs to estimate the attitude of
a satellite in order to control its velocity. The economist needs to estimate economic growth
in order to control unemployment. The medical doctor needs to estimate blood sugar levels in
order to control heart and respiration rates.
 Often an engineer needs to estimate the system states because those states are interesting in
their own right. For example, if an engineer wants to measure the health of an engineering
system, it may be necessary to estimate the internal condition of the system using a state
estimation algorithm. An engineer might want to estimate satellite position in order to more
7
intelligently schedule future satellite activities. An economist might want to estimate
economic growth in order to make a political point. A medical doctor might want to estimate
blood sugar levels in order to evaluate the health of a patient.

In conventional state estimation, network real-time modeling is decomposed into: 1) the

processing of logical data (the statuses of switching devices) and 2) the processing of analog
data (e.g., power flow, power injection, and voltage magnitude measurements). During
topology processing, the statuses of breakers/switches are processed using a bus-
section/switching-device network model.

Observable islands are handled with full state estimation including bad data analysis. State
estimation can be extended to the rest of the system of interest through the addition of
pseudo-measurements based on load prediction and generation scheduling. In executing state
estimation for this augmented system, however, care must be taken to avoid corrupting the
states estimated from telemetry data. Hence, the state estimator is used to build the model for
the observable part of the network and optionally to attach a model of the unobservable part
to it. With adequate redundancy level, state estimation can eliminate the effect of bad data
and allow the temporary loss of measurements without significantly affecting the quality of
the estimated values. State estimation is mainly used to filter redundant data, to eliminate
incorrect measurements, and to produce reliable state estimates, although, to a certain extent,
it allows the determination of the power flows in parts of the network that are not directly
metered. Not only do traditional applications such as contingency analysis, optimal power
flow, and dispatcher training simulator rely on the quality of the real-time network model
obtained via state estimation, but the new functions needed by the emerging energy markets
will do so even more.

8
State Estimation is not a standalone process. It requires preprocessing, which is also required for
other power system applications and simulations. Conveniently expressed as a set of sequential
steps, the constituent elements of a state estimation package are:

3.1.1 TOPOLOGY PROCESSORS

The power grid consists of many devices which can be broadly categorized into Generators,
Active loads, Passive loads, Transformers, Circuit breakers, Transmission lines, and Shunt
components. Most power systems employ the 1.5 CB protection scheme – which means every 2
devices are connected to the system through 3 CBs. The status of these CBs influences the
connection of these devices to the network, and hence the way they interact with and influence
the network – thus determining the network topology. The Topology processor should thus be
able to provide the electrical equivalent representation of the physical connections i.e. the
bus/branch oriented model.

The following basic results are expected from a conventional topology processor

Identification of busses in the system, and elimination of de-energized busses.

Identification of equipment (transformers, loads, generators, transmission lines, shunts etc.)

connected to the energized busses.
9
Determination of observable islands in the system.

Designation of Bus-types (PQ, PV, slack)

The process of determining the network topology involves 3 sequential steps

Bus Configuration – determining busses by the analysis of CB statuses.

Network Configuration – establishing the energized network islands and the busses that belong
to them.

Construction of equipment to bus tables

NETWORK TOPOLOGY PROCESSOR (NTP)

Conventional network topology processing identifies energized, de-energized, and grounded

electrical islands and is performed before state estimation and other related functions. In this
conventional approach, state estimation assumes that the topology is correct and proceeds to
estimate the states and identify analog bad data whenever redundancy allows it. A complete
description of the network model and the location of metering devices in terms of bus-sections
and switching-devices is assumed to be available from a database. The NTP transforms the bus-
section/switching-device model into the bus/branch model and assigns metering devices to the
components of the bus/branch network model identified. Hence, in more conventional
implementations, the real-time modeling of a power network usually follows a six-step
procedure involving: 1) data gathering; 2) network topology processing; 3) observability
analysis; 4) state estimation; 5) processing of bad data; and 6) identification of network model.
Step 1) assumes a bus-section/switching-device model. Steps 2) and 3) assume that switching
device status is correct. Step 4) additionally assumes that the parameters are correct. Step 5)
processes bad data assuming that they are caused by analog measurements. The first task of the
NTP is to convert raw analog measurements to the appropriate units and to verify operating
limits, the rate of change of operating variables, the zero flows in open switching devices, and
zero voltage differences across closed switching devices. Next, bus sections are processed to
determine the connectivity in bus section groups, which are sets of bus sections that become a
single bus when all switches and breakers are considered closed. n addition to switching devices,

10
substations are associated with terminals of branch devices (e.g., transmission lines,
transformers, phase shifters, and series devices), shunt devices (e.g., capacitors, reactors,
synchronous condensers, static VAr compensators, loads and generators), and metering devices
(e.g., power and current flow meters, power and current injection meters, and voltage magnitude
meters) as well. The connection of these devices in a bus/branch model requires the
determination of the network buses. Bus section processing consists of merging bus sections of a
bus section group into one or more network buses (buses of the bus/branch network model).
Once such network buses are formed, data structures (pointers and links) are built to associate
them with branch and shunt devices.

In the tracking mode, the NTP updates the parts of the power network affected by status changes.
Only bus section groups where changes have occurred are processed and the associated data
structures are updated accordingly. Switching device status changes can modify both the way bus
sections are grouped into network buses and the association of branch and shunt devices with
network buses. The location of metering devices may be affected as well. Thus, the new data
structures relating network buses to various devices (branch, shunt, and metering) are compared
with the corresponding structures saved from the previous run. Simple plausibility checks are
then performed for changed bus section groups using Kirchhoff's laws. There are cases in which
changes in a bus section group also affect network connectivity (e.g., cases when a bus splits or a
branch device switches from one bus to other). In these cases, the data structures describing
network connectivity and network islands are updated by NTP in tracking mode. The benefits of
the tracking mode are not limited to the topology processor itself: in the case of minor changes,
or when no changes occur, matrix structures (including the optimal pivoting order) used in other
applications can be reused up to a certain point, although eventually the cumulative effect of
changes will require a complete matrix refactorization.

Depending on the results of the state estimation, bad analog/status data can be removed or, if
redundancy does not permit a safe decision, the suspect area is kept in the bus-section/switching-
device model level for further evaluation during state estimation of the entire network.

11
3.1.2 OBSERVABILITY ANALYSIS

The output of the topology processor is used to determine the feasibility of the process of State
Estimation. There are mathematical criteria to determine if the measurement set has sufficient
number of variables for the SE block to function. Sometimes only certain parts of a power
system are found to be observable. These are called observable islands. Each Observable island
will contain a slack bus. The unobservable parts will have to be supplemented with additional
measurement devices. Observability analysis also makes it possible to find the best points for
introducing the additional meters. Also it is possible to introduce calculated values as meters in
unobservable areas, called pseudo measurements. Observability analysis also deals with the
extent of error introduced due to pseudo measurements.

If there are enough measurements and they are well distributed throughout the network in such a
way that state estimation is possible, the network is said to be observable. If a network is not
observable, it is still useful to know which portion has a state which can be estimated, i.e., it is
important to determine the observable islands. In the observable parts of a network, measurement
redundancy is defined as the ratio of the number of measurements to the number of states; in
most practical cases the redundancy is in the range 1.7–2.2. A critical measurement is a
nonredundant measurement, i.e., a measurement that when removed turns the network
unobservable. There are three principal types of algorithms for observability analysis:
topological; numerical; and hybrid.

Extended Observable Islands

The inclusion of breakers, switches, zero impedance branches, and branches with unknown
impedances in the generalized state estimation model has motivated the following extended
definitions of islands and observable islands.

An island is a contiguous part of a network with bus sections as nodes and lines, transformers,
open switches, closed switches, and switches with unknown status as branches.

An observable island is an island for which all branch flows can be calculated from the available
measurements independent of the values adopted for reference pseudomeasurements.

12
Topological Observability Analysis

The concept of topological observability was originally proposed for networks represented by
bus/branch models and is linked to the idea of maximal spanning tree, which is a tree that
contains every node in the graph representing a network. To each branch of a maximal spanning
tree is assigned a measurement. A measurement assignment satisfies:

1) different branches are always assigned to different measurements; 2) if the flow in a branch is
measured the branch is assigned to that measurement; 3) a branch with unmeasured flow is
assigned to an injection measurement at a node incident to the branch. Although it is generally
agreed that the topological approach can be extended to handle the additional states and
pseudomeasurements of the generalized state estimation, further research is still needed (The
same can be said regarding the consideration of current magnitude measurements.)

Topological observability does not necessarily guarantee solvability of the state estimation
problem.

Numerical Observability Analysis

The numerical observability algorithm below was designed to handle networks that are totally or
partially represented at the physical level. The basic modifications regarding the algorithm for
networks modeled at the bus/branch level is the addition of new state variables and new pseudo
measurements. The extended algorithm is also based on the presence of zero pivots that may
occur during triangular factorization of the gain matrix. The difference is that the gain matrix
will include additional information as well as new states, and since power flows are also state
variables, zero pivots may occur in connection with these variables as well. When this happens,
state variables corresponding to these zero pivots are added as pseudomeasurements with
arbitrary values, just as in the bus/branch model. Irrelevant measurements are again identified,
i.e., injection measurements with incident branches with estimated flows being a function of the
arbitrary values assigned to the pseudo measurements added (nonzero flows) are considered
irrelevant.

13
3.1.3 STATE ESTIMATION SOLUTION

The core of the system, it derives the state of the system from the given electrical network. In
electrical systems, the state is usually a vector of Potentials (V) and Phase angles (delta) w.r.t the
slack bus. Since the phase angle of the slack bus is defined to be zero, the order of a state vector
is 2n – 1, where n is the number of buses in an observable island. Using this state, all the system
values are determined.

State estimation program is a mathematical tool which based on the network connectivity
information, network parameters, the analog measurement which is redundant in nature,
estimates the state of the given power system i.e., computes the voltage magnitude and angle at
each and every bus.

Voltage magnitude at all buses can be easily measured. Angle measurement at all buses is
extremely difficult as the angle is relative in nature and simultaneous voltage waveform at each
bus is required at one point.

Because of the redundancy in measurement, state estimation will potentially be able to

- Detect the missing data

- Correct the erroneous data

- Correct the errors involved in the metering, analog to digital conversion

- Correct the non simultaneous measurement to simultaneous flow

The basic set of equations:

( )

( )

( )

( )

14
Z: Measurement vector

X: Vector of state variables

w : Measurement error vector

Weighted Least Square Problem:

Minimize J(x) = [z – h(x)]T W[z-h(x)]

G(x). ε = HT (x).W.ε

H(x) = [make proper equations]

3.1.4 BAD DATA PROCESSING

With all the properties that are both predicted as well as measured, we are now in a position to
find errors and hence determine outliers from the expected value. Generally the cause of a gross
error would be a misconnection, such as a phase sequence error; or an instrument defect; or bad
maintenance. Bad data processing quickly detects suspicious measurements which can be
corrected for better telemetry.

An essential requirement of the Bad data processing is redundancy of a sufficiently high degree.
The greater the amount of redundant data, with greater certainty can a suspicious measurement
be identified correctly.

It may occur that the errors affecting state estimates are not compatible with their standard
deviations. Most frequently, this happens due to the presence of bad data among the measured
quantities. Alternatively, the proposed model may be unfit to explain the measured quantities. In
either case, it is important to determine a plausible explanation, or a set of plausible explanations,
for the observed data inconsistency.

15
 CHAPTER - 4
IMPLEMENTATION AND RESULTS
Our topology processor:

Our literature survey revealed that this component has many different implementations, with few
commonalities. One important aspect was how it dealt with a changing electrical network. Those
that required complete refactorization of the entire jacobian, are called static state estimators.
They suffer from a serious disadvantage in real power transmission networks when several
changes are taking place during a short time, due to the already considerable amount of
computation involved with factorization. Dynamic topology processors (or tracking topology
processors) overcome this problem, using a variety of techniques to minimize the processing
required for each change.

Input:
The input to our topology processor is in the form of files. They are:
 One contains a list of devices in the network. A device inventory. (show structure).
 Another contains the device terminal connections listing one at a time. (show struct).
Both directions are included (if A-> B, then B-> A) will be present too. Connection Data.

Output:
The output of our topology processor is stored in memory as a set of data structures.
 Admittance Matrix (Ybus)
 Power injection vector
 Line data – contains similar information to Ybus, but in a different form.

Our novel topology processor uses a variety of data structures to efficiently parse the network.
The important ones are described below:

16
Devices:
1) Devices

They can only be of certain types, they are:

enum dev_type //device type.

{
UNKNOWN = -1,
GND = 0, // Ground.
G = 1, // Generator.
CB = 2,// circuit breaker.
TL = 3,// Tranamission line.
TR = 4,// Transformer.
T3R = 5,//3 winding Transformer
SI = 6,// Shunt Admittance.
AL = 7,// Active load.
PL = 8,// Passive load
EB = 9 // Electrical Bus
};

Each device has some unique properties of its own, apart from the basic ones.

class device
{
public:
dev_type type;
int num;
int mva;
std::string description;
};

class passive_device : public device

{
17
 public:
std::complex<float> impedance;
};

class breaker : public device

{
public:
bool closed;

};

class elec_bus : public device

{
public:
int nTerms;
};

class active_device : public device

{
public:
std::complex<float> power;
};

2) Node
Each device has either 1 or 2 terminals. To identify a particular terminal of a particular
device, we use node.

Code:

class node
{
public:
int terminal;
device* tdev;
bool operator==(const node& b) const;
18
 };

The reason we have used a pointer member to device is that many different terminals are
part of the same device. Hence to emphasize the uniqueness of the device among its set
of terminals, a pointer is used.

We could have used a reference. However it has to be initialized at definition, and it

cannot be changed to refer to another device, an operation crucial to our code (see
Data_purifier).

3) Device Connection
The fundamental unit of connections in our project is a device connection. It denotes the
electrical connection between two different nodes.

CB#1.1-TR#2.2

The two nodes before and after the hyphen are called F (from) and T (to) respectively. As
electrical AC connections are bidirectional, we include F-T and T-F also. The reason for
this is that the search operation requires a hash map, and retaining both variations makes
it simple to search using the hash map.

The class dev_conn encapsulates the connection behavior

class dev_conn
{
public:
node F;
node T;
dev_conn(node Fa, node Ta) : F(Fa),T(Ta);
bool operator==(const dev_conn& b) const;
dev_conn operator~() const;
};

19
Mechanism:

Circuit breakers are the most important for topology processing. They determine a
network topology and configuration. Our observation is that buses generally have a
number of circuit breakers connected, to retain flexibility in the energisation. The 1.5 CB
scheme is one other reason for this practice.

Taking advantage of this fact, we have designated those connections between Circuit
Breakers as Physical Buses or Pbuses. These Pbuses are generated by the function
getPbus. They are identified and copied separately, to be handled separately. These
Pbuses do not contain equivalent connections (~dev_conn). These equivalent connections
are checked for existence, but not copied. By this method we can cut down on the number
of connections to be processed when a topology change is to take place.

The next step is the generation of Electrical buses (or Ebuses). An Ebus is a list of nodes
all of which are found to be at the same electrical potential. Any two nodes can be
compared using the function checkElecConn. It checks for the following conditions:

 If they are the same terminal

 If they form 2 sides of a device connection found in connection data
 If they are terminals of the same CB

The Ebuses, processed, will contain some terminals whose device’s other terminal is also
part of the same one. These are inaccessible from outside and completely trivial. These
are removed by the function ebusCollapse.

Once the Ebuses are slimmed down, each CB terminal that has survived the collapse is
one of the terminals of an Electrical bus. The next step is changing all bus CB terminal
references into Ebus references. Ebus terminal numbers are simply the list item number
of the CB terminal that the Ebus contains. The existing data is converted to this more

20
usable form by the function dataPurifier. CB-CB connections are omitted. Connections
between non-CB devices are copied as-is.

The data is now ready for the final processing, to convert into an electrical network. This
stage results in the formation of
 Ybus
 Pinj
 Vector<line>

The final processing is done in a fairly straightforward manner. Starting at an Ebus

terminal, we pick the next device it is connected to, and depending on its properties take
appropriate action. The link ends when a 1 terminal device is encountered, a breaker is
open, another Ebus is reached.
 Transmission line, Transformer : add impedance to link impedance. Transmission
line number is retrieved and used for vector<line>. Continue following
 Generator, Load: Assign injection. Link end
 Breaker: if closed, continue following; if open, set impedance=-1, link end
 Shunt impedance: add impedance, link end
 Ebus: get the ebus number. Link end

If the link terminates in an Ebus, then the admittance is found, and is assigned to
Ybus[starting_ebus][ending_ebus]. It is also added Ybus[starting_ebus][starting_ebus].
The injection (if any) is added to Pinj[starting_ebus].

If the link does not terminate in an ebus, then the admittance is added to
Ybus[starting_ebus][starting_ebus] only. These are in accordance with the definition of
the Admittance Matrix.

21
 CHAPTER - 5
CONCLUSION AND FUTURE SCOPE
In this project, we have implemented Observability using algorithms in [3], [6], [7], [8]. We
intend to make a wider study of the techniques available and make a more robust
implementation. While developing our new topology processor, we ran into problems of
unprecedented difficulty and requiring uncommon insight. Bad Data processing is a statistical
technique which examines the state estimator output and finds the error between the seen output
and expected output. Weights are assigned to each of these measurements based on their
deviation from the expected value as per the state estimator. These weights are constantly
updated and the measurements with higher weights are considered.

22
REFERENCES
[1] A. Monticelli, Fellow, IEEE, “Electric Power System State Estimation”, Proceedings
of the IEEE, vol. 88, no. 2, February 2000.

[2] Mauro Prais, Anjan Bose, Department of Electrical Engineering, Arizona State
University, “A Topology Processor That Tracks Network Modifications Over Time”, IEEE
Transactions on Power Systems, Vol. 3, No. 3, August 1988.

[3] G. R. Krumpholz, K. A. Clements, and P. W. Davis, “Power system observability: A

practical algorithm using network topology,” IEEE Trans. Power App. Syst., vol. 99, pp.
1534–1542, July/Aug. 1980.

[4] A. Monticelli and F. F. Wu, “Network observability: Identification of observable islands

and measurement placement,” IEEE Trans. Power App. Syst., vol. 104, pp. 1042–1048, May
1985.

[5] K. A. Clements and B. F. Wollenberg, “An algorithm for observability determination in

power system state estimation,” in Proc. IEEE/PES Summer Meeting, Paper A75 447-3, San
Francisco, CA, July 1975.

[6] Nucera, R.R.; Gilles, M.L.; ABB Power Autom. Inc., Palo Alto, CA, “Observability
analysis: a new topological algorithm”, Power Systems, IEEE Transactions on May 1991

[7] K. A. Clements, G. R. Krumpholz, and P. W. Davis, "Power system state estimation

with measurement deficiency: an algorithm that determines the
maximal observable subnetwork," Paper 82 WM 043-8, IEEE PES Winter Meeting 1982, to
appear in IEEE TrIan. 2.

[8] K. A. Clements, G. R. Krumpholz, and P. W. Davis, "Power system state estimation

residual analysis: an algorithm using network topology," IEEE Trans. Pas, Vol. PAS-100,
No. 4, pp 1779-1787, April 1981.

[9] F.C. Schweppe and J. Wildes, "Power System Static State Estimation, Part I: “Exact
Model", IEEE Trans. on Power App. Syst., Vol. PAS-89, pp. 120-125, Jan. 1970.

[10] “Optimal State Estimation: Kalman, H-infinity, and Nonlinear Approaches”: Dan
Simon, Professor, Cleveland State University, Department of Electrical and Computer
Engineering.

[11] “Power System State Estimation and Contingency Constrained Optimal Power Flow -
A Numerically Robust Implementation” by Slobodan Paji´c, A Dissertation Submitted to the
Faculty of the Worcester polytechnic institute in partial fulfillment of the requirements for
the Degree of Doctor of Philosophy in Electrical and Computer Engineering.
23
[12] “High Voltage Engineering” - J R Lucas 2001

[13] On Indian Power Sector: http://indianpowersector.com/

24
 APPENDIX A: CODE
File: Definitions.hpp

#include <iostream>
#include <vector>
#include <list>
#include <complex>
#include "EnumString.h"

enum dev_type //device type.

{
UNKNOWN = -1,
GND = 0, // Ground.
G = 1, // Generator.
CB = 2,// circuit breaker.
TL = 3,// Tranamission line.
TR = 4,// Transformer.
T3R = 5,//3 winding Transformer
SI = 6,// Shunt Admittance.
AL = 7,// Active load.
PL = 8,// Passive load
EB = 9 // Electrical Bus
};

Begin_Enum_String( dev_type ) //device type.

{
Enum_String( UNKNOWN );
Enum_String( GND ); // Ground.
Enum_String( G ); // Generator.
Enum_String( CB );// circuit breaker.
Enum_String( TL );// Tranamission line.
Enum_String( TR );// Transformer.
Enum_String( T3R );//3 winding Transformer
Enum_String( SI );// Shunt Admittance.
Enum_String( AL );// Active load.
Enum_String( PL );// Passive load
Enum_String( EB ); // Electrical Bus
}
End_Enum_String;

class myexception: public std::exception

{
public:
virtual const char* what() const throw()
{
return "Device Not found in device table";
}
};

class device
{
public:
25
 dev_type type;
int num;
int mva;
std::string description;
static device* find(dev_type typ, int numb)
{
extern std::vector<device*> inventory;
std::vector<device*>::iterator device_iter;

for(device_iter=inventory.begin();device_iter!=inventory.end();device_iter++)
{
if((*device_iter)->type == typ && (*device_iter)-> num == numb)
return *device_iter;
}
if(device_iter == inventory.end())
{
myexception devicenotfound;
throw devicenotfound;
}
}

int nTerm()
{
switch(type)
{
case G:
case AL:
case PL:
case SI:
return 1;
break;
case TR:
case TL:
case CB:
return 2;
break;
case T3R:
return 3;
break;
default:
return 0;
}
}

bool operator==(const device& b) const

{
return type==b.type&&num==b.num ? true : false;
}

device(dev_type typ,int numb,int mvaa,std::string descr)

: type(typ),num(numb),mva(mvaa),description(descr)
{}
};

class node
{
public:
26
 int terminal;
device* tdev;
bool operator==(const node& b) const
{
return tdev==b.tdev && terminal==b.terminal ? true : false;
}

node get_other_term()
{
if(tdev->nTerm() == 2)
{
node similar;
similar.tdev = tdev;
similar.terminal = (terminal == 1 ? 2 : 1);
return similar;
}
}

bool operator< (const node& b) const

{
if(tdev->type < b.tdev->type)
return true;
else if(tdev->type > b.tdev->type)
return false;
else
{
if(tdev->num < b.tdev->num)
return true;
else if(tdev->num > b.tdev->num)
return false;
else
return terminal < b.terminal;
}
}
};

class dev_conn
{
public:
node F;
node T;
dev_conn(node Fa, node Ta) : F(Fa),T(Ta) {} //Needed due to
reference having to be initialized at definition
bool operator==(const dev_conn& b) const
{
return F==b.F && T==b.T ? true : false;
}
dev_conn operator~() const
{
dev_conn b(T,F);
return b;
}

};

std::ostream& operator<<(std::ostream& out, node a);

std::ostream& operator<<(std::ostream& out, dev_conn ab);
27
class passive_device : public device
{
public:
std::complex<float> impedance;
passive_device(dev_type typ,int numb, int mvaa, std::string desc, std::string G,
std::string B)
: device(typ,numb,mvaa,desc) ,
impedance((float)atof(G.c_str()),(float)atof(B.c_str()))
{}
};

class breaker : public device

{
public:
bool closed;
breaker(int numb, int mvaa,std::string desc, std::string isclosed)
: device(CB,numb,mvaa,desc)
{closed = (bool)(atoi(isclosed.c_str())!=0);}

};

class elec_bus : public device

{
public:
int nTerms;
elec_bus(int numb)
: device(EB,numb,0,""), nTerms(0)
{}
};

class active_device : public device

{
public:
std::complex<float> power;
active_device(dev_type typ,int numb, int mvaa,std::string desc, std::string
P,std::string Q)
: device(typ,numb,mvaa,desc) ,
power((float)atof(P.c_str()),(float)atof(Q.c_str()))
{}
};

class line
{
public:
int num;
elec_bus *Fbus,*Tbus;
std::complex<float> impedance;
};

class adjacency
{
public:

};
typedef std::list<std::list<node> >::iterator lististnode_itr;
typedef std::list<node>::iterator listnode_itr;
28
File: EnumString.h

// EnumString - A utility to provide stringizing support for C++ enums

// Author: Francis Xavier Joseph Pulikotil
//
// This code is free software: you can do whatever you want with it,
// although I would appreciate if you gave credit where it's due.
//
// This code is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

#ifndef ENUMSTRING_HEADER
#define ENUMSTRING_HEADER

/* Usage example

// WeekEnd enumeration
enum WeekEnd
{
Sunday = 1,
Saturday = 7
};

// String support for WeekEnd

Begin_Enum_String( WeekEnd )
{
Enum_String( Sunday );
Enum_String( Saturday );
}
End_Enum_String;

// Convert from WeekEnd to string

const std::string &str = EnumString<WeekEnd>::From( Saturday );
// str should now be "Saturday"

// Convert from string to WeekEnd

WeekEnd w;
EnumString<WeekEnd>::To( w, "Sunday" );
// w should now be Sunday
*/

#include <string>
#include <map>
#include <cassert>

// Helper macros

#define Begin_Enum_String(EnumerationName) \
template <> struct EnumString<EnumerationName> : \
public EnumStringBase< EnumString<EnumerationName>, EnumerationName > \
{ \
static void RegisterEnumerators()
// {

#define Enum_String(EnumeratorName) \
29
 RegisterEnumerator( EnumeratorName, #EnumeratorName );
// }

#define End_Enum_String \
}

// The EnumString base class

template <class DerivedType, class EnumType>
class EnumStringBase
{
// Types
protected:
typedef std::map<std::string, EnumType> AssocMap;

protected:
// Constructor / Destructor
explicit EnumStringBase();
~EnumStringBase();

private:
// Copy Constructor / Assignment Operator
EnumStringBase(const EnumStringBase &);
const EnumStringBase &operator =(const EnumStringBase &);

// Functions
private:
static AssocMap &GetMap();

protected:
// Use this helper function to register each enumerator
// and its string representation.
static void RegisterEnumerator(const EnumType e, const std::string &eStr);

public:
// Converts from an enumerator to a string.
// Returns an empty string if the enumerator was not registered.
static const std::string &From(const EnumType e);

// Converts from a string to an enumerator.

// Returns true if the conversion is successful; false otherwise.
static const bool To(EnumType &e, const std::string &str);
};

// The EnumString class

// Note: Specialize this class for each enumeration, and implement
// the RegisterEnumerators() function.
template <class EnumType>
struct EnumString : public EnumStringBase< EnumString<EnumType>, EnumType >
{
static void RegisterEnumerators();
};

// Function definitions

template <class D, class E>

typename EnumStringBase<D,E>::AssocMap &EnumStringBase<D,E>::GetMap()
{
30
 // A static map of associations from strings to enumerators
static AssocMap assocMap;
static bool bFirstAccess = true;

// If this is the first time we're accessing the map, then populate it.
if( bFirstAccess )
{
bFirstAccess = false;
D::RegisterEnumerators();
assert( !assocMap.empty() );
}

return assocMap;
}

template <class D, class E>

void EnumStringBase<D,E>::RegisterEnumerator(const E e, const std::string &eStr)
{
const bool bRegistered = GetMap().insert( typename AssocMap::value_type( eStr, e )
).second;
assert( bRegistered );
(void)sizeof( bRegistered ); // This is to avoid the pesky 'unused variable' warning
in Release Builds.
}

template <class D, class E>

const std::string &EnumStringBase<D,E>::From(const E e)
{
for(;;) // Code block
{
// Search for the enumerator in our map
typename AssocMap::const_iterator i;
for(i = GetMap().begin(); i != GetMap().end(); ++i)
if( (*i).second == e )
break;

// If we didn't find it, we can't do this conversion

if( i == GetMap().end() )
break;

// Keep searching and see if we find another one with the same value
typename AssocMap::const_iterator j( i );
for(++j; j != GetMap().end(); ++j)
if( (*j).second == e )
break;

// If we found another one with the same value, we can't do this conversion
if( j != GetMap().end() )
break;

// We found exactly one string which matches the required enumerator

return (*i).first;
}

// We couldn't do this conversion; return an empty string.

static const std::string dummy;
return dummy;
31
}

template <class D, class E>

const bool EnumStringBase<D,E>::To(E &e, const std::string &str)
{
// Search for the string in our map.
const typename AssocMap::const_iterator itr( GetMap().find( str ) );

// If we have it, then return the associated enumerator.

if( itr != GetMap().end() )
{
e = (*itr).second;
return true;
}

// We don't have it; the conversion failed.

return false;
}

#endif

32
File: inventory_read.cpp
#include <string>
#include <sstream>
#include <fstream>
#include <vector>
#include <algorithm>
#include "definitions.hpp"
#include "EnumString.h"

using namespace std;

vector<active_device> listActDev;
vector<passive_device> listPassDev;
vector<breaker> listBreaker;
vector<elec_bus> listElecbus;

void getDeviceList(string filename, vector<device*>& inventory)

{
dev_type enumconv(string aa);
ifstream connreader;
connreader.open(filename.c_str());

string conn;
getline(connreader,conn);

while(connreader.good())
{
getline(connreader,conn);
if(conn.empty()) break;
//cout<<conn;
stringstream cba(conn);
string aa;

//Device Type
getline(cba,aa,',');
dev_type a=UNKNOWN;
remove(aa.begin(), aa.end(),' '); //trim space
assert(EnumString<dev_type>::To(a,aa) != 0);
if(a==UNKNOWN) break;
dev_type thetype = a;

//Device number
getline(cba,aa,',');
int thenum=atoi(aa.c_str());

//MVA
getline(cba,aa,',');
int themva = atoi(aa.c_str());

//Description
getline(cba,aa,',');
string thedescr = aa;

//Special Characteristic 1 : Real component OR CB status

getline(cba,aa,',');
string spchar = aa;

33
 //Special Characteristic 2 : Imaginary component
getline(cba,aa,',');
string spchar2 = aa;

switch(thetype)
{
case AL:
case PL:
case G:
{
active_device
curra(thetype,thenum,themva,thedescr,spchar,spchar2);
listActDev.push_back(curra);
break;
}
case TL:
case TR:
case SI:
{
passive_device
currb(thetype,thenum,themva,thedescr,spchar,spchar2);
listPassDev.push_back(currb);
break;
}
case CB:
{
breaker currc(thenum,themva,thedescr,spchar);
listBreaker.push_back(currc);
break;
}
}
}
connreader.close();

for(vector<active_device>::iterator i= listActDev.begin() ; i != listActDev.end();

i++)
inventory.push_back(&(*i));

for(vector<passive_device>::iterator i= listPassDev.begin() ; i !=
listPassDev.end(); i++)
inventory.push_back(&(*i));

for(vector<breaker>::iterator i= listBreaker.begin() ; i != listBreaker.end();

i++)
inventory.push_back(&(*i));

34
File:devconn_read
#include <sstream>
#include <string>
#include <fstream>
#include <algorithm>
#include "definitions.hpp"

using namespace std;

dev_type enumconv(string aa)

{
if(aa=="G")
return G;
else if(aa=="CB")
return CB;
else if(aa=="TR")
return TR;
else if(aa=="TL")
return TL;
else if(aa=="T3R")
return T3R;
else if(aa=="PL")
return PL;
else if(aa=="AL")
return AL;
else if(aa=="SI")
return SI;
else
return UNKNOWN;
}

void connections_populate(string filename, vector<dev_conn>& data)

{
ifstream connreader;
extern vector<device*> inventory;
connreader.open(filename.c_str());
while(connreader.good())
{
string conn;
getline(connreader,conn);
if(conn.empty())
break;
stringstream cba(conn);
string aa;
//F
getline(cba,aa,',');
remove(aa.begin(), aa.end(), ' '); //trim space
dev_type a;
EnumString<dev_type>::To(a,aa);
if(a==UNKNOWN) break;
getline(cba,aa,',');
int b=atoi(aa.c_str());

//find the damn device in the inventory table.

device* curr = device::find(a,b);
//device ca;
//ca.type = a;
35
 //ca.num = b;

getline(cba,aa,',');
b=atoi(aa.c_str());

node da;
da.tdev = curr;
da.terminal = b;
//T
getline(cba,aa,',');
remove(aa.begin(), aa.end(), ' '); //trim space
EnumString<dev_type>::To(a,aa);
if(a==UNKNOWN) break;
getline(cba,aa,',');
b=atoi(aa.c_str());

//ca.type = a;
//ca.num = b;
device* curra = device::find(a,b);

getline(cba,aa);
b=atoi(aa.c_str());

node ea;
ea.tdev = curra;
ea.terminal = b;
dev_conn fa(da,ea);
data.push_back(fa);
}
connreader.close();
}

36
File:GetYbus.cpp
#include <complex>
#include <list>
#include <map>
#include "definitions.hpp"

using namespace std;

//ZERO or ONE indexing??? It seems inconsistent right now!

void formElectricalNetwork(list<list<node> > Ebus, map<node,node> newerdata,

complex<float> Ybus[][100], vector<complex<float> >& Pinj, vector<line>& listLines)
//It takes almost all data processed until now
{
Pinj.resize(Ebus.size());
bool followLink(node next, complex<float>& inj, complex <float>& impedance, int&
termInWhichEbus, int& lineNumber);
for(lististnode_itr iteri = Ebus.begin(); iteri != Ebus.end(); iteri++) //Iterate
through the list of Ebuses
{
int i = distance(Ebus.begin(), iteri); //Current Ebus.. e.g. Ebus
1 .. (no there is no simpler way)
i++;
int num_ebus_terms = iteri->size(); //
elec_bus* currebus = static_cast<elec_bus*>(device::find(EB,i));
for(int j = 1; j <= num_ebus_terms; j++)
{
node curr_ebus_term;
curr_ebus_term.tdev = currebus;
curr_ebus_term.terminal = j;
node curr_conn_to = newerdata[curr_ebus_term];
complex<float> injection(0,0),Z(0,0),Y(0,0);
int termInWhichEbus = 0, lineNum = 0;
typedef dev_type termination_type;

while(followLink(curr_conn_to,injection,Z,termInWhichEbus,lineNum))//////check
{
node next_node = curr_conn_to.get_other_term();
curr_conn_to = newerdata[next_node];
}

if(injection != (complex<float>)0 && Z != (complex<float>)0)

{
//later
}
else if(Z != (complex<float>)0 && termInWhichEbus == 0)
{
Y = (complex<float>(1,0))/Z;
Ybus[i][i] -= Y;
}
else if(injection != (complex<float>)0 && Z == (complex<float>)0)
{
Pinj[i] += injection;
}

else if(injection == (complex<float>)0 && Z != (complex<float>)0)

{
37
 line thisline;
thisline.num = lineNum;
thisline.Fbus = currebus;
thisline.Tbus =
static_cast<elec_bus*>(device::find(EB,termInWhichEbus));
thisline.impedance = Z;
listLines.push_back(thisline);
Y = (complex<float>(1,0))/Z;
Ybus[i][termInWhichEbus] = Y;
Ybus[i][i] -= Y;
}
}
}
}

//How to ensure that SI is added to Y11 only, and not any other Y1n?

bool followLink(node next, complex<float>& inj, complex <float>& impedance, int&

termInWhichEbus, int& lineNumber)
{
device* x = next.tdev;
if(x->type == G) // || x->type == PL)
{
inj += static_cast<active_device*>(x)->power;
return false;
}
else if(x->type == AL)
{
inj -= static_cast<active_device*>(x)->power;
return false;
}
else if(x->type == SI)
{
impedance += static_cast<passive_device*>(x)->impedance;
return false;
}
else if(x->type == TR)
{
impedance += static_cast<passive_device*>(x)->impedance;
return true;
}
else if(x->type == TL)
{
passive_device* xa = static_cast<passive_device*>(x);
impedance += xa->impedance;
lineNumber = xa->num;
return true;
}
else if(x->type == CB)
{
if(static_cast<breaker*>(x)->closed)
return true;
else
{
impedance = 0;
return false ;
}
38
 }
else if(x->type == EB)
{
termInWhichEbus = static_cast<elec_bus*>(x)->num;
return false;
}
}

39
File:dataPbus.cpp

#include <fstream>
#include <algorithm>
#include "definitions.hpp"
#include "EnumString.h"

using namespace std;

void getPbus(vector<dev_conn>& data, vector<dev_conn>& Pbus) // Pbus is a connection of

circuit breakers.
{
for(unsigned int i=0;i < data.size();i++)
{
if ((data[i].F.tdev->type == CB) && (data[i].T.tdev->type == CB)) // if
both devices are CBs,
{
vector<dev_conn>::iterator itr = data.begin();
itr = find(data.begin()+i,data.end(),~data[i]);
if(data.end() != itr)// no new struct for Pbus, instead, double
checking has to be done.
Pbus.push_back(*itr); // when checking, check for ~a also.
}
}
}

void printPbus(vector<dev_conn> Pbus, string filepbus)

{
ofstream pbusnice;
pbusnice.open(filepbus.c_str());
for(vector<dev_conn>::iterator i=Pbus.begin();i!=Pbus.end();i++)
pbusnice<<(*i)<<endl;
pbusnice.close();
}

40
File: getEbus.cpp

#include <iterator>
#include <list>
#include <map>
#include <fstream>
#include "definitions.hpp"

using namespace std;

extern std::vector<dev_conn> Pbus;

bool checkElecConn(node a, node b);

void pbustoebus(const vector<dev_conn>& Pbus, list<list<node> >& Ebus)

{
list<node> Electricalbus;
for (size_t i=0 ; i<Pbus.size() ; i++ )
{
lististnode_itr in1=Ebus.end(),in2=Ebus.end();
dev_conn curr = Pbus[i];
bool spliced = false, added = false;
for(lististnode_itr j=Ebus.begin();j!=Ebus.end();j++)
{
list<node>& currbus=*j;
bool justadded=false;
for(listnode_itr k=currbus.begin();k!=currbus.end();k++)
{
if(checkElecConn(curr.F,*k)||checkElecConn(curr.T,*k))
{
if(in1==Ebus.end())
{
currbus.push_back(curr.F);
currbus.push_back(curr.T);
}
added=true;
justadded=true;
break;
}
}
if(in1==Ebus.end() && added) //if it has not been found
in any ebus before this one
{
in1 = j;
//added=false;
continue;
}
else if(justadded)
{
in2 = j;
//break; //DONT BREAK! Ebuses have to be examined!
in1->splice(in1->end(),*in2);
j--;
Ebus.erase(in2);
in2 = Ebus.end();
}

41
 }
in1 = Ebus.end();

if(!added)
{
Electricalbus.push_back(curr.F);
Electricalbus.push_back(curr.T);
Ebus.push_back(Electricalbus);
Electricalbus.clear();
}
}
}

bool checkElecConn(node a, node b)

{
if(a==b)
return true;
else if(a.tdev == b.tdev && a.tdev->type == CB)
{
device* temp = a.tdev;
breaker* tempa = (breaker*)(temp);
if(tempa->closed)
return true;
else
return false;
}
else
return false;
}

void addEbuses(list<list<node> > ebus, vector<device*>& inventory)

{
extern vector<elec_bus> listElecbus;
int numb=0;
for(lististnode_itr i = ebus.begin();i != ebus.end(); i++)
{
numb+=1;
elec_bus currbus(numb);
listElecbus.push_back(currbus);
}
for(vector<elec_bus>::iterator i = listElecbus.begin();i!=listElecbus.end();i++)
inventory.push_back(static_cast<device*>(&(*i)));
}

node Ebusbelong(list<list<node> > ebus,node CBa) // Returns the Ebus the CB terminal
belongs to
{
bool found=false;
int aba = 0;
for(lististnode_itr i = ebus.begin();i != ebus.end(); i++)
{
aba++;
int abb = 0;
42
 for(listnode_itr j = i->begin();j != i->end(); j++)
{
abb++;
if(*j == CBa)
{
node belongnode;
belongnode.tdev = device::find(EB,aba);//j->tdev;
belongnode.terminal = abb;
return belongnode;
}
}
}
if(!found)
{
node nonode;
nonode.terminal =0;
return nonode;
}

void outerify(list<list<node> >& Ebus)

{
for(lististnode_itr i = Ebus.begin();i != Ebus.end(); i++) //for every ebus
{
for(listnode_itr j = i->begin(); j != i->end(); j++) // for every node in
the ebus
{
breaker* as = static_cast<breaker*>(j->tdev);
if(as->closed)
*j=(j->get_other_term());
}
}
}

void purifier(vector<dev_conn> data, list<list<node> > ebus, map<node,node>& newerdata)

{
vector<dev_conn>::iterator i = data.begin();
for(;i != data.end(); i++)
{
bool fiscb = (i->F.tdev->type == CB);
bool tiscb = (i->T.tdev->type == CB);

if(!fiscb && !tiscb) ////If the neither F nor T of the

connection is a CB
newerdata.insert(pair<node,node>(i->F,i->T)); //add the connection
else if(fiscb && !tiscb)
{
if(Ebusbelong(ebus,i->F).terminal !=0)
{
node newF(Ebusbelong(ebus,i->F));
newerdata.insert(pair<node,node>(newF,i->T));
}
else
{
newerdata.insert(pair<node,node>(i->F,i->T));
43
 }
}
else if(!fiscb && tiscb)
{
if(Ebusbelong(ebus,i->T).terminal !=0)
{
node newT(Ebusbelong(ebus,i->T));
newerdata.insert(pair<node,node>(i->F,newT));
}
else
{
newerdata.insert(pair<node,node>(i->F,i->T));
}
}
}
}

void ebus_collapse(list<list<node> >& Ebus) //Needs only Ebus

{
void exportEbus(list<list<node> > Ebus, string filename);
for(lististnode_itr i = Ebus.begin();i != Ebus.end(); i++) //for every ebus
{
//-----------------------------------------------------------------------
investigate
for(listnode_itr j = i->begin(); j != i->end(); j++) // for every node in
the ebus
{
cout<<"comparing "<<*j;

for(listnode_itr k = j; k != i->end(); k++) // compared with every

other node in the ebus
{
if(j==k)
continue;
cout<<" with "<<*k<<endl;
if(*j == *k)
{
cout<<"Erasing .. "<<*k<<" as duplicate of "<<*j<<endl;
k=i->erase(k);
k--;
}
if(k==i->end())
break;
}
if(j==i->end())
break;
}
//-----------------------------------------------------------------------
exportEbus(Ebus,"ebuses_half_slimmed.txt");
for(listnode_itr j = i->begin(); j != i->end(); j++) // for every node in
the ebus
{
cout<<j->tdev->num<<"\t"<<j->terminal<<endl;

for(listnode_itr k = j; k != i->end(); k++) // compared with every

other node in the ebus
{
44
 if(j==k)
continue;
bool founda = j->tdev == k->tdev;
cout<<"";
if(j->tdev == k->tdev && j->terminal != k->terminal) // if
they are two terminals of the same device
{
cout<<"Erasing .. "<<*j<<" and "<<*k<<endl;
j=i->erase(j); //Remove
j--;
k=i->erase(k); //Both!
k--;
}
if(k==i->end())
break;
}

}
}
}

void exportEbus(list<list<node> > Ebus, string filename)

{
ofstream ebusout;
ebusout.open(filename.c_str());
string temp;
int ebnum=0;
for(lististnode_itr i=Ebus.begin();i!=Ebus.end();i++)
{
ebnum++;
ebusout<<"Ebus"<<ebnum<<" Terminals"<<endl;

for(listnode_itr j=i->begin();j!=i->end();j++)
ebusout<<(*j)<<endl;

ebusout<<endl;
}
ebusout.close();
}

45
File: observability.cpp
#include <vector>
#include <iostream>
#include <fstream>
#include <string>
#include "definitions.hpp"

using namespace std;

void exportLines(vector<line> lineList,string filename)

{
ofstream linnaeus;
linnaeus.open(filename.c_str());
for(vector<line>::iterator i = lineList.begin(); i!= lineList.end();i++)
{
linnaeus<<i->Fbus->num<<","<<i->num<<","<<i->Tbus->num<<endl;
}
linnaeus.close();
}

46
File:main.cpp
#include <string>
#include <list>
#include <exception>
#include <map>
#include "definitions.hpp"
#include "EnumString.h"

using namespace std;

void connections_populate(string filename, vector<dev_conn>& data);

void getPbus(vector<dev_conn>& data, vector<dev_conn>& Pbus);
void pbustoebus(const vector<dev_conn>& Pbus, list<list<node> >& Ebus);
void addEbuses(list<list<node> > ebus, vector<device*>& inventory);
void purifier(vector<dev_conn> data, list<list<node> > ebus, map<node,node>& newerdata);
void ebus_collapse(list<list<node> >& Ebus);
void outerify(list<list<node> >& Ebus);
void getDeviceList(string filename, vector<device*>& inventory);
void formElectricalNetwork(list<list<node> > Ebus, map<node,node> newerdata,
complex<float> Ybus[][100], vector<complex<float> >& Pinj, vector<line>& listLines);
//void getMeasurements(string filename, vector<measurement>& listMeas);
void exportLines(vector<line> lineData, string measFileName);
void printPbus(vector<dev_conn> Pbus, string filepbus);
void exportEbus(list<list<node> > Ebus, string filename);

vector<device*> inventory;
vector<dev_conn> data,Pbus; // Master list of all connections.

list<list<node> > Ebus;

complex<float> Ybus[100][100];
vector<complex<float> > Pinj;
vector<line> listLines;

map<node,node> newerdata;
int main()
{
string inv_filename = "device_inventory_final.csv";
getDeviceList(inv_filename,inventory);
string conn_filename = "dev_conn_final.csv";
connections_populate(conn_filename,data);

getPbus(data,Pbus);
printPbus(Pbus,"pbuses.txt");
pbustoebus(Pbus,Ebus);
addEbuses(Ebus,inventory);
exportEbus(Ebus,"ebuses_unslimmed.txt");
ebus_collapse(Ebus);
outerify(Ebus);
exportEbus(Ebus,"ebuses_slimmed.txt");
purifier(data,Ebus,newerdata);
formElectricalNetwork(Ebus,newerdata,Ybus,Pinj,listLines);
exportLines(listLines,"linelist.csv");
}

47
std::ostream& operator<<(std::ostream& out, node a)
{
out<<EnumString<dev_type>::From(a.tdev->type)<<","<<a.tdev->num<<","<<a.terminal;
return out;
}

std::ostream& operator<<(std::ostream& out, dev_conn ab)

{
out<<ab.F<<","<<ab.T;
return out;
}

48
 APPENDIX B: OUTPUT SCREEN

Data:
Device_inventory.csv
Device Device Real Imag
Type Number MVA Description SpChar SpChar
G 1 500 GENERATOR 1.3 0.13
CB 1 750 BREAKER 1
CB 2 750 BREAKER 1
CB 3 750 BREAKER 1
CB 4 750 BREAKER 1
CB 5 750 BREAKER 1
CB 6 750 BREAKER 1
CB 7 750 BREAKER 1
CB 8 750 BREAKER 1
CB 9 750 BREAKER 1
CB 10 750 BREAKER 1
CB 11 750 BREAKER 1
CB 12 750 BREAKER 0
CB 13 750 BREAKER 0
CB 14 750 BREAKER 1
CB 15 750 BREAKER 1
CB 16 750 BREAKER 1
CB 17 750 BREAKER 1
49
CB 18 750 BREAKER 1
TL 1 500 LINE 0.05 0.32
TL 2 500 LINE 0.05 0.32
TL 3 500 LINE 0.05 0.32
TL 4 500 LINE 0.05 0.32
G 2 500 GENERATOR 1.3 0.13
G 3 500 GENERATOR 1.3 0.13
TR 1 500 TRANSFORMER 0.01 0.1
TR 2 500 TRANSFORMER 0.01 0.1
TR 3 500 TRANSFORMER 0.01 0.1
AL 1 350 MOTOR 1 0.2
AL 2 250 MOTOR 0.8 0.3

Dev_conn_final.csv
G 1 1 CB 1 1
CB 1 1 G 1 1
CB 1 2 CB 2 1
CB 1 2 CB 9 1
CB 2 1 CB 1 2
CB 2 1 CB 9 1
CB 2 2 TR 1 1
TR 1 1 CB 2 2
TR 1 2 CB 3 1
CB 3 1 TR 1 2
CB 3 2 TL 1 1
TL 1 1 CB 3 2
TL 1 2 CB 4 1
CB 4 1 TL 1 2
CB 4 2 TR 2 1
TR 2 1 CB 4 2
TR 2 2 CB 5 1
CB 5 1 TR 2 2
CB 5 2 CB 6 1
CB 5 2 CB 7 2
CB 5 2 CB 8 1
CB 6 1 CB 5 2
CB 6 1 CB 7 2
CB 6 1 CB 8 1
CB 6 2 G 2 1
G 2 1 CB 6 2
CB 7 1 TL 2 2

50
CB 7 2 CB 5 2
CB 7 2 CB 6 1
CB 7 2 CB 8 1
CB 8 1 CB 5 2
CB 8 1 CB 6 1
CB 8 1 CB 7 2
CB 8 2 AL 1 1
AL 1 1 CB 8 2
TL 2 2 CB 7 1
TL 2 1 CB 12 2
CB 12 2 TL 2 1
CB 12 2 CB 14 1
CB 12 2 CB 13 2
CB 9 1 CB 1 2
CB 9 1 CB 2 1
CB 9 2 TL 4 1
TL 4 1 CB 9 2
TL 4 2 CB 10 2
TL 4 2 CB 11 1
CB 10 1 CB 15 2
CB 10 1 CB 13 1
CB 10 2 TL 4 2
CB 10 2 CB 11 1
CB 11 1 CB 10 2
CB 11 1 TL 4 2
CB 11 2 CB 12 1
CB 12 1 CB 11 2
CB 13 1 CB 10 1
CB 13 1 CB 15 2
CB 13 2 CB 12 2
CB 13 2 CB 14 1
CB 13 2 TL 2 1
CB 14 1 CB 13 2
CB 14 1 CB 12 2
CB 14 1 TL 2 1
CB 14 2 TL 3 1
CB 15 1 AL 2 1
AL 2 1 CB 15 1
CB 15 2 CB 10 1
CB 15 2 CB 13 1
TL 3 1 CB 14 2
TL 3 2 CB 16 1
51
CB 16 1 TL 3 2
CB 16 2 TR 3 1
TR 3 1 CB 16 2
TR 3 2 CB 17 1
CB 17 1 TR 3 2
CB 17 2 CB 18 1
CB 18 1 CB 17 2
CB 18 2 G 2 1
G 2 1 CB 18 3

Pbuses
CB 2 1 CB 1 2
CB 9 1 CB 1 2
CB 9 1 CB 2 1
CB 6 1 CB 5 2
CB 7 2 CB 5 2
CB 8 1 CB 5 2
CB 7 2 CB 6 1
CB 8 1 CB 6 1
CB 8 1 CB 7 2
CB 14 1 CB 12 2
CB 13 2 CB 12 2
CB 15 2 CB 10 1
CB 13 1 CB 10 1
CB 11 1 CB 10 2
CB 12 1 CB 11 2
CB 15 2 CB 13 1
CB 14 1 CB 13 2
CB 18 1 CB 17 2

Ebuses
Ebus1 Terminals

CB,2,2

CB,1,1

CB,9,2

Ebus2 Terminals

52
CB,6,2

CB,5,1

CB,7,1

CB,8,2

Ebus3 Terminals

CB,14,2

CB,12,2

CB,13,2

Ebus4 Terminals

CB,15,1

CB,13,1

CB,12,1

Ebus5 Terminals

CB,18,2

CB,17,1

53