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

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

hoursoutageForcedhoursservice-In

hoursoutageForcedFOR (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 unit’s 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).

0 xq

C xq1)xP(X

i

ii

i (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

ii

ii

i

i

C xq

Cx0q

0 x

)xP(X

0

(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)xP(X)P(xki

ikk (3.6)

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.

)C(XP'pP(X)n

1iii (3.8)

where 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 hour’s load for

a 24 hours day. The mathematical formula for calculation of LOLP is shown

in Equation (3.9).

j

jj

jjj

A100

tp]CP[L]CP[CLOLP (3.9)

where P - Probability

L - Expected load

CA - Available generation capacity

Cj - Remaining generation capacity

pj - Probability of capacity outage

tj - Percentage of time when the load exceeds Cj

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

where • 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

k1kk

n

1kk

n

1kk )Pt(ttPLOLE (3.11)

where 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:

nLOEE p E

k kK 1 (3.12)

Figure 3.1 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

p.u k k

K 1

LOEE p E / E (3.13)

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

Power System

clients

Power system

reliability estimation

service provider with

custom Message

Receiver

getService()

(execute)

launchService()

(download)

SOAP

Request

SOAP

Response

Reliability estimation service as attachment with

SOAP Response

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.

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

public OMElement getService(OMElement request);

public OMElement launchService(OMElement request);

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:

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

String serviceClass = element.getFirstElement().getText();

FileDataSource fds = new FileDataSource(serviceClass);

DataHandler dh = new DataHandler(fds);

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.

77

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 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:

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

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);

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. The corresponding WSDL file or the

EndpointReference can be located using the following 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:

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

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 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:

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:

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

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);

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.

Figure 3.3 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

Power SystemsService Registry

Power SystemsReliability

Clients

GSR Service Provider

GSR Services

Interfaces(LOLP service)

(LOLE service)(LOEP service)(LOEE service)

GSRS-DL description (GenerationSystem Reliability service.wsdl)

4

3

2Discover Reliabilityservice and itsBinding information

Publish Reliability

Service

Invoke and obtainGSRS-WSDL

Exchange of datausing XML overSOAP

5

ebXMLRegistry

Create interfaces and Reliability

Service Descriptors1

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 well-

defined 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 GSRS-

WSDL 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

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

LOLP

LOLE

LOEE

LOEP

SOAP Request /

Response

XML- PSR

ebXMLRegistry

Information Layer

Packaging Layer

Discovery Layer

Service Layer

Transport Layer

HTTP / HTTPS

XMLisedPower system reliability data

Generation system reliabilityServices descriptors

Reliability service registry

SOAP MessagesGeneration system reliability services

Raw PSR

Data

Raw PSR

Data

XML- PSR

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, error-

free 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. GSRS-

WSDL 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

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

<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>

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.

Figure 3.6 SOAP Communication between Reliability Service Requester

and Provider

SOAP Request for Reliability Services

Generatingsystem

Load system

data

GSR Services

LOLP

LOLE

LOEP

LOEE

HTTP

Engine

SOAPEngine

HTTP

Engine

SOAP

Engine

SOAP Requestfor

GSR Services

Reliability SOAP Response

Estimation of GeneratingSystem

Reliability

Service Requesters

ReliabilityService 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.

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>

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);

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 document-

driven 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

Google’s 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, 5

1i iCC

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

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

<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>

100

version identifier for the latest version of the application. The App Engine

based Web application configuration is given as follows:

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,

<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>

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

RMIJAX-RPC

(SunAppServer)

AXIS2

(Tomcat)

CLOUD

(GoogleAppEngine)System

RTT

in ms

Throughput

in Mbit/s

RTT

in ms

Throughput

in Mbit/s

RTT

in ms

Throughput

in Mbit/s

RTT

in ms

Throughput

in Mbit/s

3 Bus

System298 1.76 280 1.87 269 1.95 245 2.14

RBTS

(6 bus

System)

268 1.95 248 2.11 235 2.23 205 2.56

IEEE RTS

(24 busSystem)

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 on-

demand 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 client’s

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.