56

CHAPTER 3
GENERATION SYSTEM RELIABILITY
EVALUATION SERVICES

3.1

INTRODUCTION
In power system generation planning, many design and operational

criteria and techniques have been developed to resolve the conflict between
economic and reliability constraints. The objective of generation planning is
to provide sufficient generating units for the future in such a way that the
investment and operating costs are minimized, while satisfying the system
load

requirements

with

specified

reliability

under

the

operating,

environmental and financial constraints encountered. The planning procedure

for the expansion of generating capacity by adding new units, based on the
criterion that a certain risk level should not be exceeded, is selected largely by
economic considerations.

Generating capacity adequacy evaluation is

performed to evaluate the ability of the system generation capacity to meet the
total system load. Billinton and Huang (2005) illustrated two computer
programs that have been developed to conduct basic generating capacity
adequacy evaluation.

The described simulation program provides the

opportunity to extend the basic reliability indices normally calculated using an

analytical program to include index probability distributions.
A wide range of methods have been developed to perform
generating capacity adequacy evaluation. Analytical methods represent the
system by mathematical models and evaluate the reliability indices using

57

direct numerical solutions.

Simulation methods estimate the reliability

indices by simulating the actual process and random behaviour of the system.
There are a number of basic reliability indices to assess generation
capacity adequacy. The loss of load expectation (LOLE) is the expected
number of days (hours) in a specified period in which the daily peak load
exceeds the available generating capacity. The loss of energy expectation
(LOEE) is the expected unsupplied energy due to generating inadequacy. The
loss of load frequency (LOLF) is the expected frequency of encountering a
generation deficiency in a given period (Billinton and Allan 1984). The
different reliability indices are obtained using different load models. The
authors have discussed the misconceptions of estimation a LOLE index in
hours and LOLE index in days and the wrong interpretation on reciprocal of
the LOLE is being considered as LOLF. They have illustrated the analytical
and simulation programs using well known test systems, IEEE-RTS and
RBTS.
3.2

GENERATING UNIT RELIABILITY MODEL

ANALYTICAL METHODS
The most important input quantities required in generation system

reliability analysis are the capacity and the failure probabilities of individual
generating units. If a simple two-state model is assumed for the operation of
a unit, its failure probability is given by its unavailability U, which can be
expressed in terms of the unit failure rate

and repair rate as shown in

Equation (3.1).

(3.1)

where

U = unit unavailability
= unit failure rate
= unit repair rate

58

Unit unavailability is also known conventionally as forced outage

rate (FOR), although the value is not a rate.

The FOR is defined in

Equation (3.2) as given below.

FOR

Forced outage hours

In - service hours Forced outage hours

(3.2)

The FOR calculated for a long period of time (e.g. 365 days), is the
same index as the unavailability defined in Equation (3.1). The FOR is a
good approximation for the two-state model. The next step in building a
generation model is to combine the capacity and availability of the individual
unit to estimate available generation in the system.

The result of this

combination will be a capacity model, where each generating unit is

represented by its nominal capacity, Ci and its unavailability, Ui (or FOR).
The capacity or the outage capacity, X is considered to be a random variable
in power system reliability analysis.

The capacity or outage capacity is

discrete and obeys an exponential distribution.

The unit model is the

probability table of a generator units capacity state. The probability model of

a two-state generator model has only two states; in operation or on outage.
There are 2n possible different capacity states.

The individual state

probability can be described in Equation (3.3).

P(X x i )

1 q
q

x i Ci
xi 0

(3.3)

The cumulative state probability (the distribution function) can be

obtained by summing up the individual state probability for all capacity less
than xi. Equation (3.4) gives the cumulative state probability.

59
0

P(X x i )

q
q

xi 0
0 x i Ci
xi Ci

(3.4)

There will be a forced outage rate for every capacity Ci, and the
individual state probability and cumulative state probability are summarized
in Equations (3.5) and (3.6) respectively.
P(X= xi) = p(xi) where i = 0,1,2, ..

(3.5)

P(x k ) P(X x k )

(3.6)

i k

p(x i )

From these equations, the Capacity Outage Probability Table

(COPT) that represents the probability of different capacity outages of the
system can be generated.
3.2.1

Recursive Algorithm
A capacity outage probability table (COPT) is an array of the

capacity levels and their probabilities of existence. It is used in the loss of

load method and can be formed using a recursive algorithm. The recursive
algorithm for adding two state generating units is given by Equation (3.7).
This equation shows the cumulative probability of a certain capacity outage
state of X MW calculated after one unit of capacity C MW, with a forced
outage rate U, is added

P(X)

(1 U) P (X)

(U)P (X C)

(3.7)

where P (X) and P(X) are the cumulative probability of the capacity outage
state of X MW before and after the unit is added.

60

Equation (3.7) is modified as shown in Equation (3.8) for

generating units with derated states.

P(X)

n
i 1

where

p i P' (X Ci )

(3.8)

n = number of unit states

Ci = capacity outage of state i for the unit being added
pi = probability of existence of the unit state i.
The capacity outage probability table is complete after all the

generating units are added.

3.2.2

Load Model Representation

The load in a power system in any period of time is a stochastic

process, which is difficult to describe with a simple mathematical formula.

Different models are created, starting from primary load data and according to
the need to calculate reliability. Primary load data will provide a minimum
amount of data that is needed to establish an hourly chronological load
profile.

Most primary load data consist of the percentage of maximum

monthly load or weekly load in a year, the load in 24 hours in a typical day in
each season and the maximum load in each day in a week.

With the

percentages of these data available and the annual peak load known, the
hourly chronological load profile can be established.
The quantification of reliability is an important aspect of generation
system reliability assessment. The measurement used to quantify reliability
of a generation system is given by various reliability indices. These reliability
indices are used to assess the reliability performance of a generation system
against some predetermined minimum requirements or reliability standards,
compare alternative designs, identify weak spots and determine ways for

61

correction in the generation system and to be integrated with costs and

performance considerations for decision making. These indices are better
understood as estimates of system-wide generation adequacy and not as
absolute measures of system reliability.
Generally, system reliability evaluations can be divided into
deterministic and probabilistic. The most common deterministic indices are
the Reserve Margin and the largest set in the system.

An important

shortcoming of these methods is that they do not account for the stochastic
nature of system behaviour. Probabilistic methods can provide more
meaningful information to be used in design and resource in planning and
allocation (Prada 1999). There are two approaches that use probabilistic
evaluation. The analytical methods represent the system by mathematical
models and use direct analytical solutions to evaluate reliability indices from
the model.

As for the Monte Carlo simulation, reliability indices are

estimated by simulating the actual random behaviour of the system. So of the

commonly used probabilistic reliability indices are Loss of Load Probability
(LOLP), Loss of Load Expectation (LOLE), Loss of Energy Probability
(LOEP), Loss of Energy Expectation (LOEE), Expected Energy Not Served
(EENS), and Loss of Load Frequency (LOLF) and Loss of Load Duration
(LOLD). Most of these indices are basically expected values of a random
variable. Expectation indices provide valid adequacy indicators which reflect
various factors such as system component availability and capacity, load
characteristics and uncertainty, system configurations and operational
conditions, etc., (Billinton and Li 1994).
Loss of load occurs when the system load exceeds the generating
capacity available for use. Loss of Load Probability (LOLP) is a projected
value of how much time, in the long run, the load on a power system is
expected to be greater than the capacity of the available generating resources.

62

It is defined as the probability of the system load exceeding the available

generating capacity under the assumption that the peak load of each day lasts
all day (Endrenyi 1978). LOLP is based on combining the probability of
generation capacity states with the daily peak probability so as to assess the
number of days during the year in which the generation system may be unable
to meet the daily peak (Khatib 1978). LOLP can be calculated considering
the daily peak loads for 1 year duration or sometimes on each hours load for
a 24 hours day. The mathematical formula for calculation of LOLP is shown
in Equation (3.9).

LOLP

P[C A

C j ] P[L C j ]
j

where

pj t j
100

Probability

Expected load

CA

Available generation capacity

Cj

Remaining generation capacity

pj

Probability of capacity outage

tj

Percentage of time when the load exceeds Cj

(3.9)

Alternatively, a load duration curve consists of daily peak loads

arranged in descending order can be used to measure LOLP for long term
generation capacity evaluation. The assumption used in this case is that the
peak load of the day would last all day.
Capacity outage less than the amount of reserves will not contribute
to a loss of load. When a particular capacity outage is greater than the
reserve, the risk in this case will be pj x tj.
It must be noted that an LOLE expectation index is more often used
than the LOLP probability index in practical applications. The relationship
between LOLE and LOLP is shown in Equation (3.10).

63

LOLE = LOLP x T
where

(3.10)

T = 365 days (if the load model is an annual continuous load

curve with day maximum load; the LOLE unit is in days per
year)

T = 8760 hours (if the load model is an hourly load curve; the
LOLE unit is in hours per year)

LOLP is used to characterize the adequacy of generation to serve

the load on the bulk power system; it does not model the reliability of the
power delivery system transmission and distribution where the majority of
outages actually occur (Kueck et al 2004). The LOLP is like a rule of thumb
to give an indication of the reserve margin of 20% or 25%. But it gives a
better indication or measure of reliability than the reserve margin index as it
takes into account system characteristics such as individual generator
reliability, load unpredictability, and unit derations.
3.2.3

Loss of Load Method

The generation model is convolved with the load model as shown

in Figure 2.3. The load model used depends on the required reliability index.
One common load model represents each day by the daily peak load, while
another one represents the load using the individual hourly load values. If the
daily peak loads are arranged in descending order, the formed cumulative load
model is called the daily peak load variation curve. The load duration curve is
created by arranging the hourly load values in descending order. In the loss
of load method, the daily peak load (or hourly values) are combined with the
capacity outage probability table to obtain the expected number of days (or
hours) in the given period in which the daily peak load (or hourly load)
exceeds the available capacity. The index in this case is designated as the loss
of load expectation (LOLE). The LOLE is given by:

64

LOLE

n
k 1

where

Pk t k

k 1

(t k

t k 1 )Pk

(3.11)

n is the total number of capacity outage states

pk is the individual probability of the capacity outage state
Pk is the cumulative probability

of the capacity outage state

tk is the number of time units when there is a loss of load
The relationship between load, capacity and reserve is shown in
Figure 3.1. When the load duration curve is used, the shaded area represents
the energy that cannot Ek be supplied in a capacity outage state k. The
probable energy curtailed in this case is pk Ek. The loss of energy expectation
(LOEE) is given by:

LOEE

n
K 1

Figure 3.1

p E
k k

(3.12)

Relationship Between Capacity and Load and Reserve

65

The LOEE can be normalized using the total energy under the load
duration curve as shown in Equation (3.13).
n

LOEE p.u

(3.13)

pk E k / E
K 1

EIR

= 1 LOEEp.u

(3.14)

An index designated as the energy index of reliability (EIR) can be

calculated using the above Equation (3.14).
Loss of energy method is another measure for generation reliability
assessment. The measure of interest in this case is the ratio of the expected
energy not served (EENS) during some long period of observation to the total
energy demand during the same period. The loss of energy index gives a
more real representation of the system than the LOLP index. It will show the
severity of an event by giving a higher value for more serious events than for
marginal failures, even if their probabilities and frequencies are the same.
However, the true loss of energy cannot be accurately computed on the basis
of the cumulative curve of daily peaks (Endrenyi 1978). As a result, the Loss
of Energy index is seldom used for reliability evaluations of for generation
capacity planning.
Currently, research has been focused to represent the estimation of
generation system reliability indices as services over the Web and hence the
evaluation of generation adequacy using SOAP communication based service
oriented model has been derived.

As requirements are emerging due to

deregulation policies, automation and launching of reliability estimation

services are becoming inevitable to address the large size of power system
problems and to handle the critical conditions during power system

66

operations. The reliability services thus implemented should be anytime and

anywhere accessible.
3.3

WEB ENABLED AUTOMATION OF POWER SYSTEM

RELIABILITY ESTIMATION SERVICES
The power system service developers to host their services need a

reliable service provider who will be able to provide execution environments

for all types of applications developed in the heterogeneous environment.
They should be capable of uploading the power system services, modify them
and test them without any constraints in order to provide reliable Web enabled
services to the service consumers.

The service provider should allow the

service developers to deploy their services in off-line mode in the appropriate

application server or the developers should be allowed to deploy dynamically
while the application server is running.
An innovative Web enabled model is proposed to upload reliability
estimation services, which will automate the process of deployment in the
application server. This process enables the application server to start up
automatically and accepts the client requests. The step by step implementation
details of the proposed model are explained with appropriate code segments
to deploy the specific reliability estimation service and to make the
application server readily available to respond to the clients.
STEP 1: Creation of custom annotations for uploading reliability estimation
services at the specified server.
@Target(value={ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface Upload
{

67

String className();
String contextRoot();
String urlPattern();
}
@interface RunAtServer
{
String applicationServer();
}
@interface InputData
{
String powerSystem();
int noOfBuses();
}
STEP 2: Initialization of elements within the custom annotations and make
the annotations as class level annotations.
The service developer is expected to provide the values for the
elements of the custom annotations while uploading a service to a specific
server with a sample power system data as a test case.
@Upload(className="LolpServlet", contextRoot="lolp",
urlPattern="LolpService")
@RunAtServer(applicationServer="tomcat")
@InputData(powerSystem="ieee-rts", noOfBuses=24)
public class AnnotatedClass { }
The @Upload annotation indicates that the loss of load probability
service provided by LolpServlet.class is to be uploaded to the application
server tomcat as specified in the @RunAtServer annotation.

The

annotation @InputData refers to the stored power system data in the service

68

provider, which is ieee-rts.xml data file that represents the power system
data for the IEEE Reliability Test System with 24 buses.
STEP 3

Creation of client application through which the service

developer uploads the reliability estimation services.

STEP 3.1 :

Reading the values associated with the elements of the custom

annotations.

Annotation [] classAnnotations = AnnotatedClass.class.getAnnotations();

for(Annotation annotation : classAnnotations) {
if (annotation instanceof Upload)
{
Upload u = (Upload) annotation;
String classname = u.className();
String urlpattern = u.urlPattern();
String contextroot = u.contextRoot();
}
else if(annotation instanceof RunAtServer)
{
RunAtServer ras = (RunAtServer) annotation;
String appServer = ras.applicationServer();
}
else if(annotation instanceof InputData)
{
InputData id = (InputData) annotation;
String inputDataFile = id.powerSystem();
int size = id.noOfBuses();
}
}

69

STEP 3.2 :

Configuration of appropriate directory structure and contents for

creation of reliability service Web archive file lolp.war. The
code segment for creation of Web archive file is given in
Appendix 1. The Web archive file lolp.war file is created and
the same is to be uploaded to the service provider.

STEP 3.3 :

Establish the connection to the service provider and upload the

lolp.war file along with the name of the context root and the
identification of the application server.
Socket soc = new Socket(127.0.0.1, 5000);
File f3 = new File(warfile);
FileInputStream fis3 = new FileInputStream(f3);
byte [] buf = new byte[(int) f3.length()];
fis3.read(buf, 0, buf.length);
fis3.close();
OutputStream os = soc.getOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(os);
oos.writeObject(appServer);
oos.writeObject(contextroot);
oos.writeObject(buf);

STEP 3.4:

Upload the data file ieee-rts.xml for the IEEE Reliability Test
System for 24 Buses to the service provider.
String data_file = inputDataFile+".xml";
File f4 = new File(data_file);
FileInputStream fis4 = new FileInputStream(f4);
byte [] dataBuffer = new byte[(int) f4.length()];
fis4.read(dataBuffer, 0, dataBuffer.length);
fis4.close();
oos.writeObject(data_file);
oos.writeObject(dataBuffer);

70

STEP 4

Creation of server application which will receive the war file,

necessary information regarding context root, the data file name
and the data itself in a byte sequence form and will store them in
the appropriate directories of the application server.

The server application has to listen and accept the client request at a
specific port.

The code segment of the server application to store the

lolp.war file for deployment and the necessary data file in the appropriate
directories on the server side is given in Appendix 2. The server is listening
at port 5000 for reliability estimation service requests from the clients.
STEP 4.1 :

To enable the specified application server to start automatically

if it is in shutdown mode. A socket connection is established to
the application server to test whether it is in the start up mode or
in the shutdown mode.
Socket s = null;
if(appServer.equals("tomcat")) {
try {
s = new Socket("127.0.0.1", 8080);
}catch(SocketException e) {
Runtime rt = Runtime.getRuntime();
Process p2 = rt.exec("cmd /c start test.bat");
}
}

The test.bat file contains the commands to set up the initial

properties required to start up the Tomcat Web server and initiates the start up
procedure. The Tomcat server is executing as a separate process in this case.
Since the war file had already been uploaded to the sharable directory, the
LolpServlet service is being deployed in the server within the directory whose

71

name is specified in the string contextRoot and is ready to listen to the client
requests. Using the contextRoot and urlPattern given in the annotations, i.e.,
lolp and LolpService respectively, the URL to be used to access the
service is http://localhost:8080/lolp/LolpService.
3.4

SOAP COMMUNICATION MODEL FOR LAUNCHING

POWER SYSTEM RELIABILITY SERVICES
If the power system planners do not want to disclose the planning

data, they may request the service provider to launch the reliability estimation
services on the client side itself and then the services can be invoked using
reflection. The implementation of the reliability estimation service is added
as an attachment to the SOAP message and the same will be received on the
client side and using reflection, the services can be invoked. At some times,
when the client invokes a service at a critical condition, which needs an
immediate action to be taken based on the response of the service in order to
avoid abnormalities, the client is allowed to set a priority value to the required
service. When the server receives the request with the priority value set and if
it is not able to provide service immediately, the server could be capable of
launching an instance of the requested service on the client side. In order to
keep the integrity and security of the service, the services which are to be
launched should be self destructive so that requester cannot copy or modify
the downloaded service whose response is needed to take decision in time to
avoid any abnormality.
An innovative concept of Reliability Estimation as a Service
(REaaS) is introduced by the way of including the implementation i.e.,
definition of reliability estimation methods which have been described in the
service endpoint interfaces as binary attachments to the SOAP envelope. The
SOAP envelope with the service itself as binary attachment has been sent as a
response from the service provider to the clients as and when the specific

72

services are required. The SOAP response is parsed on the client side and the
attached service is extracted, launched and invoked using a reflective
middleware. Thus the concept of Reliability Estimation as a Service is
achieved.
The SOAP communication is emerging as a standard way to
send XML documents over the Internet from different platforms and thus
enhancing the interoperability of Web services. The SOAP with Attachment
API for Java (SAAJ) conforms to the Simple Object Access Protocol
specification and the SOAP with Attachments specification. The block
diagram representation of the proposed SOAP communication model for
launching power system reliability estimation services is given in Figure 3.2.

SOAP
Request

Power System
clients

SOAP
Response

Power system
reliability estimation
service provider with
custom Message
Receiver

getService()
(execute)

launchService()
(download)

Reliability estimation service as attachment with

SOAP Response

Figure 3.2 SOAP Communication Model with Launching Services

The power system reliability estimation service is included in the
SOAP message as attachment in the proposed model. The message receiver
associated with the regular message exchange pattern is to be customized in
order to decide whether the service is to be executed within the service
provider or an instance of the required service is bundled to transport and to
be launched on the client machine based on the priority value set by the client.

73

The reliability service provider uses request-response message exchange

pattern, in which both request and response are XML based SOAP envelopes
created using AXIS based Object Model (AXIOM) i.e., OMElement
references. The power system reliability estimation service provider has two
methods whose signatures are as follows:

public OMElement getService(OMElement request);

public OMElement launchService(OMElement request);

The parameter to the method getService() contains the name of the

service to be invoked, priority of the service to be executed and the data
required for estimating the reliability indices. The priority values between 1
and 10 are considered with an assumption that if the priority value set is
above 7, the client is in urge to have the service in order to take the decision
in time. The SOAP request to the reliability estimation service provider for
estimating the LOLP and LOLE indices is as follows:
<power:lolpService xmlns="http://power">
<power:priority>4</power:priority>
<power:serviceType>execute</power:serviceType>
<generator_system>
<totalcapacity>3405</totalcapacity>
<generator_group>
<groupId>1</groupId>
<unitId>U12</unitId>
<unitType>OilorSteam</unitType>
<numofUnits>5</numofUnits>
<unitSize>12</unitSize>
<forcedOutageRate>0.02</forcedOutageRate>

74

<mttf>2940</mttf>
<mttr>60</mttr>
<scheduledMaintenance>2</scheduledMaintenance>
</generator_group>
</generator_system>
<load_system>
<maximum_load>2850</maximum_load>
<week>
<weekid>1</weekid>
<percentageofpeak>86.2</percentageofpeak>
<actualpeakload>2456.7</actualpeakload>
</week>
</load_system>
</power:lolpService>
The SOAP request payload is not expected to contain the reliability
estimation data if the priority value set is above 7. In this case, the client is
not even required to provide the <serviceType> data to the service provider.
The launch service is assumed.

The RawXMLINOutMessageReceiver

associated with the reliability estimation service provider invokes the

getService() or launchService() method based on the priority value set by the
client.

The

predefined

invokeBusinessLogic()

behaviour

of

RawXMLINOutMessageReceiver invokes findOperation() behaviour based

on the information contained in the <priority> element. If the operation to be
performed is defined within the service provider, the invokeBusinessLogic()
invokes the method using reflective middleware and receives the response as
OMElement reference from the getService() method and uses this response to
formulate the SOAP envelope, which is its response parameter.

The

behaviour of RawXMLINOutMessageReceiver is suitably modified as given

below and hence a custom message receiver is established.

75

SOAPBody body = msgContext.getEnvelope().getBody();

String priority= body.getFirstElement().getText();

int value = priority.compareTo("7");

if(value < 0)
Method m1 = findOperation(op, ReliabilityEstimationService, "execute");
// op is the AxisOperation and ReliabilityEstimationService is the actual
//service implementation class which hosts lolpService() method
// The method reference m1 here refers to getService() method.
else
Method m2 = findOperation(op, ReliabilityEstimationService, "launch");
For each and every request sent to the server, appropriate message
contexts are created within the SOAP communication model in order to
receive the SOAP request payload from the client and then to send the SOAP
response payload to the requested client. The complete SOAP envelope of
the request sent by the client for launching the service is as follows:
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<swa:lolpService xmlns:swa="http://power">
<swa:serviceClass>ReliabilityEstimationService</swa:serviceClass>
<swa:priority>10</swa:priority>
<swa:serviceType>launch</swa:serviceType>
</swa:lolpService>
</soapenv:Body>
</soapenv:Envelope>

76

The SOAP request has been sent to the launchService() method as

its parameter as OMElement reference.

OMElement is an Axis2

representation of XML node, it provides a tree model like the Document

Object Model (DOM) that represents the XML document template.
3.4.1

Implementation of the Launching Service

The FileDataSource and DataHandler classes of javax.activation

package are used to make the service ready to transport to the requested
client.

A FileDataSource reference implies an abstraction of collection of

data and it encapsulates a file of any content type. A DataHandler object can
be created in association with the FileDataSource.

The FileDataSource

provides an InputStream to the DataHandler in order to access the data and

the data available are in byte stream form. While FileDataSource does the
data typing services, the DataHandler is used to copy the contents to another
disk file or to make the byte stream readily available onto the associated
OutputStream.

The design of FileDataSource and DataHandler provides

implicit conversion of data to byte stream form and transfer the data as such
to the secondary disk file or directly to the application. The launchService()
method accepts the name of the service to be invoked and the service class
which encapsulates the service as request in the form of OMElement that
fetches the requested service class and sends it back to the client as
OMElement. The code segment which will make the byte code contents of
the service class in a readily deliverable form is given below.
String serviceClass = element.getFirstElement().getText();
FileDataSource fds = new FileDataSource(serviceClass);
DataHandler dh = new DataHandler(fds);

77

The service class has to be attached to the message and a response

has to be formulated in the form of XML. The requested service is in the
form of byte stream and it is readily available with the DataHandler. Using
the output message context reference, the addAttachment() method is called
to which the DataHandler object is passed as parameter, which will enable the
service class to be attached with the SOAP response. A unique service ID is
returned as a string reference to refer the attached byte stream and it is sent to
the client in the form of XML which has been created using OMFactory.
Finally the generated XML document, which is the SOAP response named as
serviceElement is sent to the requested client through the message receiver.
The code segment which will create the SOAP response named as
serviceElement is as follows:

String serviceID = outMessageContext.addAttachment(dh);

OMFactory factory = OMAbstractFactory.getOMFactory();
OMNamespace omNs = factory.createOMNamespace("http://power","swa");
OMElement serviceElement=
factory.createOMElement("lolpServiceResponse", omNs);
OMElement element = factory.createOMElement("reliability",
omNs, serviceElement);
serviceElement.addAttribute("href", serviceID, null);

The reliability estimation service has been created and the

description of service is specified in services.xml as shown below:

78

<serviceGroup>
<service name="ReliabilityService">
<description>
Reliability Estimation Service SOAP with Attachment Model
</description>
<parameter name="enableSwA">true</parameter>
<parameter name="ServiceClass" locked="false">
power.ReliabilityEstimationService
</parameter>
<operation name="launchService">
<actionMapping>urn:launchService</actionMapping>
<messageReceiver
class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</operation>
</service>
</serviceGroup>

The name of the service is ReliabilityService, which will be the

name of the archive file. Two Parameters have been specified which will be
transformed into service properties in the corresponding Axis Service. The
above transformation is carried out by the ServiceClass which specifies
the

service

implementation.

The

specified

Java

class

power.ReliabilityEstimationService is loaded by the MessageReceiver

when required.

The <operation> element specifies the public method

launchService() to be invoked based on the client request.

79

3.4.2

Invoking the Service from the Client

The ReliabilityService is deployed in the Web server in order

to enable the clients to access the required service to launch the reliability
estimation

services.

EndpointReference

The

can

be

corresponding
located

using

WSDL

file

the

following

or

the
URL:

http://localhost:8080/axis2/services/ReliabilityService
The client sends a SOAP message to the server requesting for the
required service to be launched. The SOAP Envelope for the SOAP request
Message is created using SOAPFactory, as shown below:
SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
SOAPEnvelope env = fac.getDefaultEnvelope();
OMNamespace omNs = fac.createOMNamespace("http://power","swa");
OMElement method = fac.createOMElement("lolpService", omNs);
OMElement param1 = fac.createOMElement("serviceClass", omNs);
OMElement param2 = fac.createOMElement("priority", omNs);
OMElement param3 = fac.createOMElement("serviceType", omNs);
param1.setText("ReliabilityEstimationService");
method.addChild(param1);
param2.setText("10");
method.addChild(param2);
param3.setText("launch");
method.addChild(param3);
env.getBody().addChild(method);

The SOAP request is sent to the launchService() method of the

ReliabilityEstimationService, which extracts the service class name from the
message and retrieves the corresponding service class file from the server and
sends the reference i.e., service ID as a part of SOAP response to the client.

80

The client can retrieve the requested service to be launched using the service
ID in association with the DataHandler. The service class in the form of
binary content is available as SOAP Attachment. Using the service ID, which
has been sent by the ReliabilityService, the DataHandler retrieves the
attachment and provides the requested reliability estimation service to the
client and the code used to retrieve the service class is given below:

SOAPBody body = response.getEnvelope().getBody();

OMElement element = body.getFirstChildWithName(new
QName("http://power","lolpServiceResponse"));
OMElement lolpService = element.getFirstChildWithName(new
QName("http://power","power"));
String serviceID = lolpService.getAttributeValue(new QName("href"));
DataHandler dataHandler = response.getAttachment(serviceID);
if (dataHandler!=null){
// The reliability estimation service class is downloaded and
// launched on the client side.
}

The following XML document shows the SOAP response obtained

based on the SOAP request. The SOAP response contains the reference
service ID, using which the client can retrieve the service to be launched from
the DataHandler.
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<swa:lolpServiceResponse xmlns:swa="http://power">
<swa:reliability

81

href="cid:urn:uuid:72EA2136F948A489CD2393312780553"/>
</swa:lolpServiceResponse>
</soapenv:Body>
</soapenv:Envelope>
The client receives the SOAP response and extracts the reliability
estimation service as byte stream from the attachment as referred by service
ID and stores it in the same name of the service in the location from where the
client application is executing.

The client application uses a reflective

middleware for invoking the lolpService() service which is encapsulated in

the ReliabilityEstimationService class. The code segment of the reflective
middleware to invoke the service is as follows:
Class c = Class.forName("ReliabilityEstimationService");
Object o = c.newInstance();
Object [] objectParameters = { new OMElement("ieee-rts.xml") };
Class [] classParameters = { objectParameters[0].getClass() };
Method m = c.getMethod("lolpService", classParameters);
OMElement element = (OMElement) m.invoke(o, objectParameters);

The element refers to the SOAP response of the LOLP service

and contains the LOLP index for the given IEEE-RTS test system data.
While launching option is used, the lolpService is defined in such a way that
the service can be executed only once by the client, i.e., the client has to
consume the service from the service provider for every request. A self
destructive algorithm has been proposed and incorporated within the service
which has to be launched. The proposed algorithm stores a pattern as a string
in its own byte code file, which will be changed while the service is being
executed at the client side. The algorithm permanently deletes the service
class from the client side if it identifies the change in the pattern after

82

successful completion of the service. In the proposed reliability estimation

service class, a pattern serve0 is assumed and this pattern has been changed
to serve1 after the service is consumed once. The code segment of the self
destructive algorithm is given in Appendix 3.
3.5

LAYERED SOA MODEL FOR GENERATION SYSTEM

RELIABILITY EVALUATION
A Service Oriented Architectural model using layered composition

is proposed for generation system reliability analysis. The layered architectural

model describes a set of patterns and provides loosely coupled, because of the
separation of concerns between descriptions, implementation and binding, and
provides unprecedented flexibility in responsiveness to the power utilities.
This model provides a standard communication among different power
system applications, running on a variety of platforms and / or frameworks.
In the proposed SOA based generation system adequacy evaluation model,
the SOA stack is composed of transport, information, service, discovery and
packaging layers.
Generating system adequacy evaluation is performed to evaluate
the ability of the system generating capacity to meet the total system demand.
The proposed SOA model is composed of Generation System Reliability
(GSR) service provider, Power Systems Service Registry and Service
Requester. The data pertaining to power systems reliability analysis are
represented in eXtensible Markup Language (XML) for exchanging the
reliability data among the users and service providers. The GSR service
provider describes the reliability evaluation services and publishes them to the
power systems service registry. The calling sequences of reliability evaluation
services along with required data are configured as SOAP (Simple Object
Access Protocol) messages and the proposed SOA model communicates
between the service provider and the service requester with formally defined

83

messages. The proposed model for generating system reliability analysis is

highly distributed and has inherent features such as scalability and flexibility
and provides a loosely coupled environment for power systems reliability
analysis.
The technologies like Supervisory Control and Data Acquisition
(SCADA), Common Object Request Broker Architecture (CORBA), Remote
Procedure Calls (RPCs) and Remote Method Invocation (RMI) do not
guarantee the exploitation of the full functionality among heterogeneous
environment. To overcome the complexity and proprietary nature of the
above mentioned technologies, the SOA model has been developed for
representation of power systems which provides the powerful set of features
based on open standards like XML, SOAP, WSDL and ebXML registry. The
proposed model supports interoperability between services on different
platforms in a reliable, scalable and adaptable manner and provides a common
computational environment for interaction between various power system
clients and reliability service providers. It allows plugging in new services or
upgrading existing services in a granular fashion to address the new
requirements. The power systems reliability evaluation services are readily
available as well as universally visible and the clients can access the services
in a distributed environment.
The major factors to be considered while developing modern power
system applications are ease of use, maintainability, integration, scalability
and interoperability. Due to deregulation policies and unpredicted increase in
demand, there is an exponential growth in power system networks to meet the
desired operational level. These sudden and dynamic changes lead to more
complex and new issues in power system planning and operations.
Consequently, new Information and Communication technologies are needed
to construct an interoperable, open and platform independent integrated

84

information system for Power System applications. The proposed service

oriented architectural model as shown in Figure 3.3 for generation system
reliability analysis provides an enhanced distributed model that solves legacy
issues associated with the interaction of power system applications. The
service oriented open system will enable various Power System services to
interact with each other in dissimilar platforms. Extensive data and
applications can be shared easily and flexibly.
Power Systems
Service Registry

Discover Reliability
service and its
Binding information

Publish Reliability
Service

ebXML
Registry

GSR Service Provider

Power Systems
Reliability
Clients

Invoke and obtain

GSRS-WSDL
GSR Services

Exchange of data
using XML over
SOAP

Interfaces
(LOLP service)
(LOLE service)
(LOEP service)
(LOEE service)
GSRS-DL description (Generation
System Reliability service.wsdl)

Figure 3.3

Create interfaces and Reliability

Service Descriptors

Proposed SOA model for Generation System Reliability

Analysis

The GSR services are categorized into Loss of Load Probability

(LOLP), Loss of Load Expectation (LOLE), Loss of Energy Expectation
(LOEE) and Loss of Energy Probability (LOEP) services. The GSR Service
provider offers the above services and describes the interfaces of the services
using Web Service Description Language (WSDL). Since the described

85

services are Generation System Reliability Services, the WSDL file is termed
as GSRS-WSDL. This is in the form of XML that makes the services
available in the Power Systems Service Registry.
Services are the key building blocks of SOA. A service is a
reusable function that can be invoked by another component through a welldefined interface. Services are loosely coupled, that is, they hide their
implementation details and only expose their interfaces. In this manner, the
power system client need not be aware of any underlying technology or the
programming paradigm which the service is using. The loose coupling
between services allows for a quicker response to changes than the existing
conventional applications for power system operations. This results in a much
faster adoption to the need of power system industries.
The power system clients discover the services available in the
registry by service names and acquire the interface information using GSRSWSDL of the Generation System Reliability services. Based on this
information, the clients have a binding with the Generation System Reliability
service provider and can invoke services using Simple Object Access Protocol
(SOAP) messages. An ebXML registry is used to publish the proposed
reliability services.
3.6

IMPLEMENTATION

OF

LAYERED

WEB

SERVICES

ARCHITECTURE
The proposed SOA model is viewed as layered Web Services
architecture for generation system reliability analysis. The various layers
involved in the implementation of the proposed architecture for generation
system reliability analysis are Transport layer, Information layer, Service
layer, Discovery layer and Packaging layer as shown in Figure 3.4.

86

Packaging Layer

SOAP Request /

Response

SOAP Messages
Generation system reliability services

Discovery Layer

ebXML
Registry

Reliability service registry

Service Layer

LOEE

LOLP

Generation system reliability

Services descriptors

LOLE

LOEP

Information Layer
XMLised
Power system reliability data

Transport Layer

XML- PSR

Raw PSR
Data

XML- PSR

Raw PSR
Data

HTTP / HTTPS

Figure 3.4

Layered Web Services Architecture for Generation System

Reliability Analysis

Each layer is performing its intended task and interacts with each
other to evaluate the generation system adequacy. The implementation details
of these layers are explained in the following sections.
3.6.1

Transport Layer
The power system clients communicate with the service provider

via HTTP / HTTPS protocol. The transport layer, which is at the bottom of
the model, encapsulates the communication. The transport layer provides an
end-to-end data transport service between the power system applications
across the network. The transport layer wraps around the end hosts that
encapsulates the communication medium. This layer provides a medium
through which the SOAP envelope which comprises of reliability data as

87

messages can be sent using the connectivity information to the subsequent

layers. When the input message is received, the request payload in the
SOAP envelope is parsed to handle appropriate action. The firewall friendly
protocols, HTTP and secure HTTPS are used for SOAP message exchanges to
invoke generation system reliability estimation services with HTTP Request
and Response.
3.6.2

Information Layer
As the size of power systems is large, data exchange is a major

concern because of the complex nature of power system operations. New

participants join the power industries as generation units, transmission units
and distributors. Because of the physical connectivity of power systems, all
levels of industry like generation, transmission and distribution need proper
planning and reliability data. The exchange of data needs to be reliable, errorfree and adaptable to different types of software used for power system
planning and operations in the related power system industries.
In power systems, data can be output of one process while being
input for another. In reliability analysis, a huge volume of data is being
exchanged among interconnected systems. IEEE Reliability Test System data
is represented in eXtensible Markup Language. The data exchange must have
a protocol that makes the data more significant for each power system
planning operation. The exchange of power system data using XML offers
trouble-free integration with the Web and Intranet / Internet applications.

88

The information layer is used to access the external systems such as

relational database or text file which contains raw power system data and it
provides the procedural means to transfer the raw power system reliability
data to XML representation for which XML schema is defined. The generated
XML document is encapsulated within the SOAP envelope and it is given as
input parameter to the service layer through transport layer.
3.6.3

Service Layer
The reliability indices Loss of Load Probability (LOLP), Loss of

Load Expectation (LOLE), Loss of Energy Expectation (LOEE) and Loss of

Energy Probability (LOEP) are used to assess generating capacity adequacy
and the methods for estimating them are declared in the user-defined
reliability service interface. A service configuration file has to be defined
using XML that includes appropriate interfaces through which the Web
Service Description File for generation system reliability services is generated
and termed as GSRS-WSDL. GSRS-WSDL is used as the metadata language
for defining the Generation System Reliability services (GSRS). It describes
how the service providers and client communicate with each other. GSRSWSDL is capable of describing services that are implemented using any
language and deployed on any platform. It represents information about the
interfaces and semantics of how to invoke the services. It contains the
information about the data type, binding and address information for invoking
the services from the service provider. The LOLP service is described as
follows:

89

<definitions name="reliabilityService"
targetnamespace="urn:reliability">
<types>
<schema targetnamespace="urn:reliability"
xmlns:tns="urn:reliability"
xmlns:soap11-enc=
"http://schemas.xmlsoap.org/soap/encoding/">
<doubletype name="estimateLolp">
</doubletype>
<element name="estimateLolp" type="tns:estimateLolp"/>
<element name="computelolpresponse" type ="string"/>
</types>
<message name="lolp_estimateLolp">
<portType name="lolp">
<operation name="estimateLolp">
<input message="tns:lolp_estimateLolp"/>
<output message="tns:lolp_estimateLolpresponse"/>
</operation>
</portType>
<binding name="lolpbinding" type="tns:lolp">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"/>
<operation name="estimateLolp">
<soap:operation soapaction=""/>
<soap:body use="literal"/>
</operation>
</binding>
<service name="reliabilityService">
<port name="lolpPort" binding="tns:lolpbinding">
<soap:address location="replace_with_actual_url"/>
</port>
</service>
</definitions>
The GSRS-WSDL definition document consists of seven key
structural elements for describing generation system service. The <definition>
element defines the name of the service as reliabilityService and declares
the namespace as reliability. The <types> element defines the data types
that would be used to describe the generator reliability data and load data. The
<message> element represents a logical definition of the data being

90

transmitted between the client and the service provider. The <portType>
element defines the abstract definition of the operation (estimateLolp) of the
service, request and response messages. The <binding> element specifies a
concrete protocol (SOAP) used for representing messages. The <service>
element represents the service to be invoked over multiple bindings. The
<port> element specifies an address (lolpPort) for binding to the service.
GSRS-WSDL makes the services available in the discovery layer through
power systems service registry.
3.6.4

Discovery Layer
The generated GSRS-WSDL is deployed and published to the

power systems service registry, which is universally visible and accessible by

the power system clients. The proposed SOA model for reliability analysis
requires the common registry to deploy the services for easy integration, reuse and
effective governance of services to meet the growing requirements. A pre-defined
electronic business XML (ebXML) registry is used to publish reliability services.
The ebXML registry allows the power system client to efficiently discover and
communicate with the services. The main purpose of the ebXML registry is to
discover the required services and to allow fast, reliable communication and
interoperability among diverse applications. The reliability services which are
available in the ebXML registry are shown in Figure 3.5.

Figure 3.5 Reliability Services Available in the Power System Registry

91

Based on the Web services discovery mechanism, the binding

between the power system clients and GSRS has been established. Once the
connection is established between the power system client and the service
provider, the exchanging of SOAP request and response messages takes place
at the packaging layer.
3.6.5

Packaging Layer
The power system clients communicate with the generation system

reliability service provider using SOAP messages as shown in Figure 3.6.

SOAP uses the protocol HTTP POST for request and response in the form of
messages. The SOAP Body represents the mandatory processing information
between the power system clients and service provider. The payload of SOAP
request message contains the generation system reliability data and load data
in terms of XML documents, which are attached as input parameters. The
SOAP response message carries the computed output of GSR indices used for
estimating the adequacy of the generating system.

SOAP Request for Reliability Services

Generating
system

Load system
data
Reliability
Service Provider

Reliability
Service Requesters
SOAP Request
for
GSR Services

HTTP
Engine

HTTP
Engine

GSR Services
LOLP
LOLE

SOAP
Engine

SOAP
Engine

LOEE
LOEP

Reliability SOAP Response

Estimation of Generating
System

Figure 3.6

SOAP Communication between Reliability Service Requester

and Provider

92

Both analytical and simulation methods have been used to evaluate

the reliability of generation system. The implementation of the SOA model
with layered composition has been tested for Roy Billinton Test System
(RBTS), and an IEEE Reliability Test system (IEEE-RTS) and the results are
reported. The developed distributed model can be easily incorporated and
plugged into any Internet based software systems for estimating the power
system reliability.
SOAP messages are configured for reliability service invocation
and response. The request message consists of service endpoint address of the
service provider and the required power system data in XML form. The
following code segment delineates how generator and load data have been
attached to the SOAP message.

String urn = "urn:Reliabiltiy";

MessageFactory messageFactory= MessageFactory.newinstance();
SOAPMessage message = messageFactory.createMessage();
SOAPPart soapPart = message.getSOAPPart();
SOAPEnvelope envelope = soapPart.getEnvelope();
SOAPBody body = envelope.getBody();
SOAPElement bodyElement=body.addChildElement(
envelope.createName(operation, "", urn));
FileInputStream fs=new FileInputStream("c:\\reliabilitydata.xml");
message.addAttachmentPart (attachment);

The SOAP request message for the estimation of LOLP indices is

as follows:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/>
< SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/encoding/">
<SOAP-ENV:Header/><SOAP-ENV:Body>

93
<public double LOLP(long cx,long ex,double P2x,double P3x, double P4x)
xmlns="urn:saaj"/>
</SOAP-ENV:Body></SOAP-ENV:Envelope>
<generator_reliability_data>
<general>
< tngg>9</tngg >
<totalcapacity type="mw">3405</totalcapacity>
</general>
<generator_group>
<group_id>1</group_id>
<unit_id>u12</unit_id>
<unit type>steam</unit>
<numofunits>4</numofunits>
<unit_size type="mw">12</unit_size>
<for>0.02</for>
<mttf type="hour">2940</mttf>
<mttr type="hour">60</mttr>
<sm type="weeksperyear">2</sm>
</generator_group>
..........................
</generator_ reliability_data>
<load_system_data>
<week>
<week_id>1</week_id>
<ppl>86.5</ppl>
<apl type="MW">2456.7</apl>
</week>
..........................
< /load_system_data>

94

The SOAP response message for the power system reliability

services is as follows:
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns0="urn:Reliability"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Body>
<ns:computeResponse>
<result>
<adequacy_evaluation>
<gsrindices>
<lolp>0.0412</lolp>
<lole>0.1505</lole>
......................
</gsrindices>
</result>
</ns:computeResponse>
</env:Body>
</env:Envelope>
In the proposed SOA model, the various generation system
reliability services can be invoked by the clients without any limitation. Thus,
establishing the SOAP connection to the destination as specified in the SOAP
message, the power system client is capable of invoking the required
generation system reliability service as given in the SOAP message at the
specified port. The generator reliability data and load data contents of the
SOAP body are provided to the service. The provider sends an entire XML
document as response rather than sending a set of values to the clients. The

95

SOAP based communication model defines a loosely coupled and documentdriven communication. Hence, the proposed SOA model for generation
system reliability analysis makes the service provider and the power systems
client to exist in a loosely coupled heterogeneous environment. The SOA
model has been designed to include or plug in new power system planning
and expansion services without modifying the existing environment.
3.7

CLOUD MODEL FOR POWER SYSTEM RELIABILITY

ESTIMATION SERVICE
The proposed SOAP communication model for power system

reliability estimation is extended to cloud computing environment due to

inherent technical benefits.

The cloud environment reduces the risk of

physical infrastructure, its initial and maintenance costs, the run time and
response time and moreover increases the pace of innovation. The abstraction
of infrastructure enables the power system applications not locked into
devices or locations. Reliability estimation services can be obtained any time
from any access point.
The cloud computing has changed the way of development,
deployment, updation and maintenance of power system applications and the
infrastructure on which they are being executed. Cloud computing when
properly implemented, provides the users with greater flexibility, portability,
and choice in their computing options. Cloud computing defines a model
where specific services are assigned to systems that are accessed through a
network. It is a type of computing in which dynamically scalable and often
virtualized resources are provided as services over the Internet (Buyya et al
2009). The cloud environment that provides Platform as a Service allows
various power system applications developed using different programming
paradigms to interact with each other without any modifications. When

96

Software is provided as a Service, it allows the electrical network service

providers to develop the power system services and host them in the cloud
environment which are used to serve the power system clients.
A cloud infrastructure can operate solely for a particular power
sector like a local distribution substation which is connected to the consumers
through feeder section. Rather than purchasing the hardware and software to
run various power system applications, clients need only a computer or a
server to download the required power system applications and Internet
access to run the software. The cloud hypervisor manages the servers and the
virtual machines and thus allocates the necessary hardware on demand
thereby providing Infrastructure as a Service. Along with the scaling capacity
of cloud platforms, we need to pay as we use similar to the electric power
distribution systems, wherein we pay for the usage. Processed data can be
stored securely in the cloud storage in the form of tables. The stored data can
be accessed from anywhere at any time and therefore no data backups are
required. The deployment of applications in a cloud environment reduces the
cost for service providers when compared other distributed environments.
Platform as a Service (PaaS) cloud provides with an infrastructure
as well as complete operational and development environments for the
deployment of complex power system applications. Most commonly used
PaaS cloud environment is Google App Engine. To leverage Google App
Engine, the required power system application is written in Java using
Googles development framework along with tools like Google file system
and data repositories. Google App Engine is selected to deploy the reliability
services to estimate the power distribution system reliability indices using
Monte Carlo Simulation approach.

97

3.7.1

Power System Reliability Estimation Service using Monte

Carlo Simulation
Simulation is a more sophisticated procedure that treats the

reliability estimation problem as a series of experiments (Billinton 1996).

Simulation processes can be generally categorized as being either random or
sequential. A reliability assessment (LOLE) of a generation system using a
non-chronological load model is considered. The state duration sampling
method is used to simulate the behaviour of the generating units. The sample
system is based on random sampling of generation and load states and
therefore does not take into account the sequential variation of the load with
time or the duration of the generation states. The load model with daily peak
load variation curve is used where the load levels are numbered in the
decreasing order to form a cumulative load model. Consequently, neither
frequency, duration, nor energy indices can be evaluated; only LOLP and
LOLE (in days/year) can be assessed. For analysis, a sample system with five
40-MW units each with a forced outage rate of 0.01 is considered. The system
load is represented by the daily peak load variation curve, which has a
forecast maximum daily peak load of 160 MW, a minimum daily peak load of
64 MW, and a study period of 365 days (one year). The step by step
simulation procedure is explained as follows (Billinton and Allan 1996):
Step 0 :

Initialize D = 0, N = 0, where D is the days of trouble and N is the

number of samples

Step 1 :

Generate a uniform random number U1 in the interval (0, 1)

Step 2 :

If U1 < FOR (0.01), then unit 1 is deemed to be in the down state

(C1 = 0) otherwise unit 1 is available with full capacity (C1 = 40)

Step 3 :

Repeat Steps 1-2 for units 2-5 (giving C2 to C5)

Step 4 :

Cumulate available system capacity, C

5
i 1

Ci

98

Step 5 :

Generate a uniform random number U2 in the interval (0, 1)

Step 6 :

Compare the value of U2 with the cumulative probabilities

representing the daily peak load variation curse. If Pi-1< U2

Pi,

then load level L= Li. (In this sample system, the load model is
considered as straight line and it is more convenient to calculate
the load level from L = 64 + (160 - 64) U2)
Step 7 :

If C < L, then D = D + l

Step 8 :

N=N+l

Step 9 :

Calculate LOLP = D / N.

Step 10 :

Calculate LOLE = LOLP x 365

Step 11 :

Repeat Steps 1-10 until acceptable values of LOLP / LOLE or

stopping rule is reached.
The value for LOLE index obtained using the Monte Carlo

Simulation approach is: 0.159999538 day / year. Due to small value of forced
outage rate is used; the number of samples required may seem to be very large
even for this small sample test system.
The GSRServlet middleware which is uploaded to the Google
cloud environment encapsulates the Monte Carlo Simulation behaviour for
the estimation of LOLE index. The Google App Engine allows dynamic
allocation of system resources for a power system application based on the
actual demand. The power system application developed using App Engine is
easy to build, maintain and to scale up or down depending on the traffic and
data storage. A deployment descriptor file is to be created while deploying
the reliability estimation service on to the GAE Cloud. The deployment
descriptor file (web.xml) is configured as follows:

99

<web-app >
<servlet>
<servlet-name>GenerationSystemReliabilityMonteCarlo</servlet-name>
<servlet-class>gsrcloud.GSRServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>GenerationSystemReliabilityMonteCarlo</servlet-name>
<url-pattern>/GSRServlet</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>gsrmontecarlo.jsp</welcome-file>
</welcome-file-list>
</web-app>

The gsrmontecarlo.jsp is designated as a welcome file and it is

displayed when the URL request http://gsrmontecarlo.appspot.com is
forwarded by the server to the client machine. The gsrmontecarlo.jsp file
displays a HTML form to obtain the general power system data from the
client for which the reliability analysis is to be carried out.
The above configuration file contains the information and details
about the deployed reliability estimation service. On receiving the request
from the client, the Web server determines all the information using this Web
application deployment descriptor. An additional configuration file has to be
created in order to deploy and run the reliability estimation service in the
Google App Engine that includes an application identifier and the version
number.

The

<application>

element

contains

the

application

id

gsrmontecarlo. This is the application id which has been created and

registered in the Google App Engine. The <version> element contains the

100

version identifier for the latest version of the application. The App Engine
based Web application configuration is given as follows:

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://kenai.com/projects/nbappengine/
download/schema/appengine-web.xsd appengine-web.xsd">
<application>gsrmontecarlo</application>
<version>1</version>
</appengine-web-app>

Based on the Web service deployment descriptor (web.xml) and the

App Engine based Web application configuration (appengine-web.xml) files,
a Web archive file reliabilityestimation.war has been created to deploy into
the cloud environment.

Once the deployment is over, the service is ready for

execution. Generally, the App Engine Software Development Kit is used to

create and upload the reliability estimation services by the service provider.
The multi-purpose tool appcfg is used for uploading the reliability
estimation services onto the cloud. At the time of uploading the information,
appcfg gets the application id (gsrmontecarlo) from the appengine-web.xml
file and uploads the contents and reliability estimation is provided as a service
from the following URL http://gsrmontcarlo.appspot.com, which can be
accessed by the power system clients worldwide.
3.8

PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS
Enhanced remote services have been developed for evaluation of

generating system adequacy assessment and tested with sample RBTS and
IEEE-RTS test systems. The QoS measures such as average elapsed time,

101

i.e., Round Trip Time and throughput are estimated and compared for
different power system reliability estimation services using different models
deployed in the Google App Engine, Tomcat Web Server and Sun
Application Server. To reduce the computation time, outage capacities are
rounded to regular intervals so as to reduce the number of states in the
capacity outage probability table. The QoS measures are obtained by varying
the number of requests to the distributed reliability estimation services.
Initially, the reliability estimation services have been implemented using RMI
framework for testing the behaviours. The RMI framework uses the Java
Remote Method Protocol, which in turn uses TCP/IP for its communication.
Through an open port, the RMI client communicates with the RMI server.
Whenever there is a firewall, the communication is blocked which is a major
drawback whenever RMI based applications are to communicate between
different local area networks.
After developing, deploying and testing the power system
reliability estimation services using RMI, JAX-RPC, SOAP based Service
Oriented model and Google App Engine cloud, the Qos measures are
tabulated as shown in Table 3.1.
Table 3.1 Comparison of QoS Measures for Reliability Estimation Services
RMI
System
3 Bus
System
RBTS
(6 bus
System)
IEEE RTS
(24 bus
System)

JAX-RPC
(SunAppServer)
RTT Throughput
in ms
in Mbit/s

AXIS2
CLOUD
(Tomcat)
(GoogleAppEngine)
RTT Throughput RTT Throughput
in ms
in Mbit/s
in ms
in Mbit/s

RTT
in ms

Throughput
in Mbit/s

298

1.76

280

1.87

269

1.95

245

2.14

268

1.95

248

2.11

235

2.23

205

2.56

210

2.496

190

2.759

172

3.048

152

3.449

102

The performance measures thus obtained in all the environments

refer to the average values when 30 different power system clients accessed
the required power system reliability estimation service. Request Elapsed
Time is the time that elapses between the initiation and fetching of the
required service by the power system client. The variations of the RTT and
throughput for power system reliability estimation services deployed in
various platforms are shown in Figures 3.7 and 3.8.

Figure 3.7 Variations in Round Trip Time

Figure 3.8 Variations in Throughput

103

The main characteristic of the cloud environment is that it is ondemand and cost effective. Further, environments like Google App Engine,
Windows Azure etc., provide the developers to upload and test certain
specific number of applications for free of cost for a limited memory usage
and other criterion.

From the obtained throughput, it is clear that the Google

App Engine is efficient in fetching the required service when compared with
the other environments. One of the major concerns from the clients
perspective would be the response time, which is found to vary minimally in
all cases for the tested power system reliability estimation services using
various platforms.
3.9

CONCLUSION
The need for Web enabled automation and launching of self

destructive power system reliability estimation services has been discussed in

this chapter.

A Web enabled automation model has been formulated to

upload reliability estimation services, which automates the process of

deployment in the application server and decouples the service provider from
the deployment procedure. In this automation model, custom annotations
have been created for uploading reliability estimation services onto the
appropriate application server. In this model, the client is allowed to set the
priority value to indicate the urgency of the service in order to take timely
decision at critical conditions.

The Web enabled automation model for

power system reliability estimation services is extended using SOAP

communication to launch the uploaded services onto the client itself whenever
needed for execution especially during critical conditions and as per the
priority requirements. A reflective middleware is used to launch and invoke
the reliability service on the client side when the SOAP response carries the
service itself as attachment. In order to keep the integrity and security of the
service, the services which are to be launched are designed to be self

104

destructive so that the requester cannot copy or modify the downloaded

service whose response is needed to take decision in time to avoid any
abnormality.
A service oriented architectural model using layered composition
has been developed and implemented for generation system reliability analysis.
The developed distributed model can be easily incorporated and plugged into
any Internet based software systems for estimating the power system
reliability. A public cloud environment is used to host the generating system
reliability estimation services and the performance of various distributed
services proposed in this chapter has been compared with respect to the QoS
parameters Round Trip Time and Throughput.