25
90 CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT STABILITY ANALYSIS 4.1 INTRODUCTION The virtualization and grid computing technologies are the key concepts for evaluation of cloud computing. Mohsin Ali et al (2007) proposed a method for transient stability analysis using grid computing technology. Grid computing enables sharing, selection, and aggregation of a wide variety of geographically and organizationally distributed resources like supercomputers, storage systems, data sources for solving resource-intensive problems. It uses standard, open, general-purpose protocols, and delivers the desired Quality of Service (QoS) via virtual computing systems. There are no global standard architectures for cloud computing comparable to the globus toolkit for grid computing, and cloud computing does not necessarily need a standard, open, general-purpose protocol. Furthermore, it supports interfaces that are syntactically simple, semantically restricted and high-level. These features of interfaces are underlying factors for a rapid adoption of cloud computing services in the power sectors. Armstrong et al (2005) stated that the virtualization technology is not only associated with the software layer but also with the hardware too. The resource virtualization is the abstraction of a server, storage, network, and operating system by creating a virtual version of them. The primary use of virtualization technologies is to support multiple operating

CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

90

CHAPTER 4

CLOUD SERVICES FOR POWER SYSTEM

TRANSIENT STABILITY ANALYSIS

41 INTRODUCTION

The virtualization and grid computing technologies are the key

concepts for evaluation of cloud computing Mohsin Ali et al (2007) proposed

a method for transient stability analysis using grid computing technology

Grid computing enables sharing selection and aggregation of a wide variety

of geographically and organizationally distributed resources like

supercomputers storage systems data sources for solving resource-intensive

problems It uses standard open general-purpose protocols and delivers the

desired Quality of Service (QoS) via virtual computing systems There are no

global standard architectures for cloud computing comparable to the globus

toolkit for grid computing and cloud computing does not necessarily need a

standard open general-purpose protocol Furthermore it supports interfaces

that are syntactically simple semantically restricted and high-level These

features of interfaces are underlying factors for a rapid adoption of cloud

computing services in the power sectors

Armstrong et al (2005) stated that the virtualization technology is

not only associated with the software layer but also with the hardware too

The resource virtualization is the abstraction of a server storage network

and operating system by creating a virtual version of them The primary

use of virtualization technologies is to support multiple operating

91

systems and platforms Essentially it uses a virtual machine monitor or host

called a ldquohypervisorrdquo to enable multiple operating system instances to run on

a single physical server and based on that it can enable hardware

consolidation in an enterprise At the software platform level the

heterogeneity exists which usually offers different implementations semantic

behaviors and APIs For these heterogeneous systems virtualization is the

pivotal technology to realize interoperability Virtualization can take place at

both the platform and application level making it easier for researchers to

develop and use new applications while hiding the complexity of the low

level infrastructure and reducing manageability overheads Aman Kansal et al

(2010) proposed virtualization concepts for metering and provisioning of

power to the end user and realize significant cost savings for implementing

virtualized data centers in power sectors Perhaps the performance of virtual

machine is not suitable for computing high end applications especially for

those applications involving closely coupled communications Compared to

virtualization cloud computing is more like a kind of ldquotechnology clusterrdquo

which contains more than one distinguishable but interrelated elements of

technology

The primary functionality of a power system is based upon

processing or manipulating and exchanging its data between the power system

applications The power system data for analyzing the transient stability of

power systems include general line bus and synchronous machine data In

existing systems these data are normally stored in databases often using a

Microsoft Access or Relational Database Management System (RDBMS)

The Structured Query Language (SQL) is used for accessing the database It

becomes very difficult to perform remote operations on the data when they

have been stored in a centralized data base A cloud environment is providing

separate layer lsquoStorage as a Servicersquo layer which allows the data to be

accessed efficiently from anywhere at any time

92

A deregulated electricity environment comprises of Generation

Transmission and Distribution sectors Each sector has as an independent grid

operator known as Independent System Operator (ISO) They are responsible

for the day-to-day operation of the power systems The data sharing and

integration are becoming major issues between these sectors while performing

power system operations As an analogy in open access electricity market the

demand has to be served by generation from anywhere in the interconnected

systems Cloud environment provides anytime anywhere solutions for data

sharing and integration issues

The scalability is the other issue in the current power system

network The power system operations are used by many concurrent users at a

time The systems have to be designed to handle operations by the clients and

providers without any hurdle to exchange data due to heterogeneous nature

The conventional data center does not provide the dynamic scalability The

cloud environment provides the inherent dynamic scalability for the

operations of power systems The tight coupling between various applications

is another issue in power system operations Tight coupling is possible at

different levels of the system ranging from hardware resources to

dependencies on external systems It reduces the scalability of the system

Applications which are designed to be loosely coupled should be able to

move easily into a cloud environment in contrast to tightly coupled

applications To resolve tight coupling some systems may need to be partially

redesigned to handle dynamic resources and avoid network dependencies

Inter-operations between the deregulators are common in large scale power

systems It leads to additional challenges such as how these operations can be

performed in a secure and reliable manner in a cloud computing environment

93

The power system engineers have to manage the parameters such as

real power reactive power voltage and frequency for the stable operation of

power systems To store and maintain these parameters in a cloud efforts

must be taken to ensure the information is kept safe in transport processing

and storage The Service Level Agreements (SLA) may be executed between

the provider and clients to keep the information in a safe and secure manner in

the cloud environment The cloud environment has to provide more reliable

services to the clients as the number cloud service providers have become

increased The power sectors still rely on the applications written in languages

such as FORTRAN and COBOL that are running on outdated operating

systems like UNIX or Windows NT Moving these applications to a cloud

environment would likely be expensive due to the large number of required

changes Furthermore the fact that these systems still run on legacy software

and technologies might indicate that the organizations prefer reliable and

stable operation of power systems at the cost of dynamic scalability

In power system analysis the computation between conventional

and Web enabled applications has become cross-discipline in nature Using

the current Information Technology (IT) concepts the applications can be

invoked from anywhere by the users The scope of power system services

computing covers whole lifecycle of power system services innovation

research that includes Power System componentization service modelling

service creation service realization service annotation service deployment

service discovery service composition service delivery service-to-service

collaboration services monitoring services optimization and as well as

service management The goal of power systems services computing is to

adopt recent IT services and computing technologies to perform the services

more efficiently and effectively A Web service based model for doing power

system analysis is reported in the previous chapter The work mainly

concentrates on the representation of power system data and its operations in

94

PowerSystem

Client

Registry

Cloud

Services

PublishFind

Bind

Invoke

Virtual Service

Provider

Virtual Service

Provider

Virtual Service

Provider

Services

Services

Services

a distributed heterogeneous environment The computation of stability

services in SOA has also been investigated The Web service architecture

provides the capability for self-contained functions to operate over the

Internet The SOA facilitates interoperable services between distributed

systems to communicate and exchange data with one another thus providing

a uniform means for clients and service providers to discover and offer

services respectively

The extension of SOA to cloud computing architecture is shown in

Figure 41 The computation of services in cloud model is based on

distributed IT concepts that are inherent which provides the easy way of

interaction between power system applications in a heterogeneous

environment The application providers can deploy their applications without

any limitation in a cloud environment and users can access complex data rich

deployed applications from anywhere on demand basis The deployment of

applications in a cloud environment reducing the cost for service providers

when compared to other distributed environments

Figure 41 Extension of SOA to Cloud Computing Architecture

95

Cloud computing is the Internet based system development

paradigm in which large scalable computing resources are provided ldquoas

servicesrdquo over the Internet to users Web-based companies such as Google

and Amazon have built Web infrastructure to deal with computation of

applications in the cloud environment According to a survey by Gartner

(2009) nearly 90 of organizations expect to maintain or grow their usage of

applications in cloud computing environment In this research Google App

Engine a cloud computing environment provided by Google is utilized for

stability services and for exchanging power system data

In this proposed model power system clients are able to invoke the

power system services anytime from anywhere and utilize large scale storage

and computing resources On the other hand the cloud computing service

providers themselves may focus on how to distribute and scheduled the

computer resources The storage and computing on massive data are the key

technologies for a cloud computing infrastructure Nowadays the service

providers and clients interested in implementing clouds face the challenge of

integrating complex software and hardware components from multiple

vendors Cloud computing platforms are attractive because they quickly

access private and public resources on demand without any complexities The

core benefit of cloud computing is instant deployment of power system

applications which is offering immediate easy access to power system client

from any location worldwide Combined with this other important benefits

are self services The cloud based applications are instantly scalable For both

clients and service providers the successful creation and deployment of cloud

services will become the foundation for their operations

Today the latest paradigm to emerge is that of cloud computing

which promises reliable services delivered through next-generation data

centers that are built on virtualized compute and storage technologies The

96

clients will be able to access applications and data from a lsquocloudrsquo anywhere

on demand basis The power system clients are assured that the cloud

infrastructure is very robust and will always be available at any time

Computing services need to be highly reliable scalable and autonomic to

support ubiquitous access dynamic discovery and composability The

recently emerged cloud computing paradigm appears to be the most

promising one to leverage and build on the developments from other

paradigms

42 NEED FOR CLOUD SERVICES IN POWER SECTORS

The proposed cloud computing model is capable of providing the

following technical benefits for the power system industries

The ability to create the illusion of infinite capacity performance

is the same if scaled for any number of power system clients

with consistent service-level characteristics

Abstraction of the infrastructure enables the power system

applications not locked into devices or locations

The power system clients only pay for what they use with no or

minimal up-front investment costs for using the deployed power

system services in the cloud environment

Power system services are available on demand and able to

scale up and down with near instant availability Typically no

forward planning forecast is required

Access to power system applications and information can be

obtained from any access point

97

The cloud services for power system transient stability analysis

can guarantee Quality of Service (Qos) for power system

clients

The computation of power system services in a cloud computing

environment is an autonomous entity and it is managed

transparently to a power system client

The hardware software and data required for analyzing power

systems represented in cloud can be automatically reconfigured

orchestrated and consolidated to present a single platform and

finally rendered to power system clients

The above key features enable the power sectors for representing

their operations and analysis in a cloud computing environment

43 LAYERS OF CLOUD COMPUTING ARCHITECTURE

The main layers of cloud computing architecture are shown in

Figure 42 The different layered services are lsquoInfrastructure as a Servicersquo

(IaaS) layer lsquoPlatform as a Servicersquo (PaaS) layer and Software or Application

as a Service (SaaS) layer Each segment serves a different purpose and offers

different solutions to businesses and individuals Cloud computing is a model

for enabling convenient on-demand network access to a shared pool of

configurable computing resources that can be rapidly provisioned and

released with minimal management effort or service provider interaction In

simpler terms cloud computing is nothing but accessing all the computational

needs of the consumer from a single point This offers reliable services

delivered through data centers that are built on computer and storage

virtualization technologies

98

Figure 42 Layers of Cloud Computing Architecture

Clients are the devices (mobiles thick and thin clients) that the end

users interact with to manage their information on the cloud The data center

is the collection of servers where the subscribed application is housed

Distributed Servers are placed at geographically disparate locations But to

the cloud subscriber these servers act as if they were right next to each other

in the cloud environment The different layers of cloud computing

architecture are explained in the following sections

431 Infrastructure as a Service (IaaS)

The cloud infrastructure layer provides the fundamental resources

needed to provide upper level platforms and services The physical resources

along with core middleware capabilities form the basis for delivering

Infrastructure as a Service (IaaS) The services provided in this layer can be

split into three categories namely computational resources data storage and

communication The properties and design features are shared between the

above three categories are availability interoperability and security

Generally the communication is based on SOAP or Representational State

Transfer (REST) over standard HTTP The works reported in this thesis

mainly concentrated on the SOAP based communication as it makes power

system applications are more interoperable The service providers are free to

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Service Provider

Client

99

design their systems directly on top of this layer skipping the platform layer

This results in increased freedom and flexibility since providers can opt to

use an existing platform that matches the individual system or even

implement their own platform for specific cases This approach can also be

used to transfer power system applications to a cloud in order to reduce

infrastructure investments

432 Platform as a Service (PaaS)

The PaaS provides the environment for service providers to

implement their services It also provides a source code level environment

with a set of APIs to aid the interaction between cloud components and

applications scalability and ease deployment and management The Google

App Engine (GAE) provides Java runtime environment and APIs for

interacting with the cloud runtime environment The major benefit for

providers implementing their services in this layer is that the environment

provides useful features easing development and reducing development time

including automatic scaling and load balancing as well as integration with

other services The service providers are able to dedicate more of their focus

on implementing specific logic while outsourcing base functionality to

platform services

433 Software as a Service (SaaS)

The cloud application or software layer is the topmost layer in the

cloud architecture and the layer most visible to end users The services in this

layer are typically accessed through Web portals The proposed cloud

computing model has proven popular with end users because it alleviates the

need to provide support for hardware to run applications and services as well

as eliminate the need for local installation and configuration The clients can

compute their required services from their terminals to the data centers in

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 2: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

91

systems and platforms Essentially it uses a virtual machine monitor or host

called a ldquohypervisorrdquo to enable multiple operating system instances to run on

a single physical server and based on that it can enable hardware

consolidation in an enterprise At the software platform level the

heterogeneity exists which usually offers different implementations semantic

behaviors and APIs For these heterogeneous systems virtualization is the

pivotal technology to realize interoperability Virtualization can take place at

both the platform and application level making it easier for researchers to

develop and use new applications while hiding the complexity of the low

level infrastructure and reducing manageability overheads Aman Kansal et al

(2010) proposed virtualization concepts for metering and provisioning of

power to the end user and realize significant cost savings for implementing

virtualized data centers in power sectors Perhaps the performance of virtual

machine is not suitable for computing high end applications especially for

those applications involving closely coupled communications Compared to

virtualization cloud computing is more like a kind of ldquotechnology clusterrdquo

which contains more than one distinguishable but interrelated elements of

technology

The primary functionality of a power system is based upon

processing or manipulating and exchanging its data between the power system

applications The power system data for analyzing the transient stability of

power systems include general line bus and synchronous machine data In

existing systems these data are normally stored in databases often using a

Microsoft Access or Relational Database Management System (RDBMS)

The Structured Query Language (SQL) is used for accessing the database It

becomes very difficult to perform remote operations on the data when they

have been stored in a centralized data base A cloud environment is providing

separate layer lsquoStorage as a Servicersquo layer which allows the data to be

accessed efficiently from anywhere at any time

92

A deregulated electricity environment comprises of Generation

Transmission and Distribution sectors Each sector has as an independent grid

operator known as Independent System Operator (ISO) They are responsible

for the day-to-day operation of the power systems The data sharing and

integration are becoming major issues between these sectors while performing

power system operations As an analogy in open access electricity market the

demand has to be served by generation from anywhere in the interconnected

systems Cloud environment provides anytime anywhere solutions for data

sharing and integration issues

The scalability is the other issue in the current power system

network The power system operations are used by many concurrent users at a

time The systems have to be designed to handle operations by the clients and

providers without any hurdle to exchange data due to heterogeneous nature

The conventional data center does not provide the dynamic scalability The

cloud environment provides the inherent dynamic scalability for the

operations of power systems The tight coupling between various applications

is another issue in power system operations Tight coupling is possible at

different levels of the system ranging from hardware resources to

dependencies on external systems It reduces the scalability of the system

Applications which are designed to be loosely coupled should be able to

move easily into a cloud environment in contrast to tightly coupled

applications To resolve tight coupling some systems may need to be partially

redesigned to handle dynamic resources and avoid network dependencies

Inter-operations between the deregulators are common in large scale power

systems It leads to additional challenges such as how these operations can be

performed in a secure and reliable manner in a cloud computing environment

93

The power system engineers have to manage the parameters such as

real power reactive power voltage and frequency for the stable operation of

power systems To store and maintain these parameters in a cloud efforts

must be taken to ensure the information is kept safe in transport processing

and storage The Service Level Agreements (SLA) may be executed between

the provider and clients to keep the information in a safe and secure manner in

the cloud environment The cloud environment has to provide more reliable

services to the clients as the number cloud service providers have become

increased The power sectors still rely on the applications written in languages

such as FORTRAN and COBOL that are running on outdated operating

systems like UNIX or Windows NT Moving these applications to a cloud

environment would likely be expensive due to the large number of required

changes Furthermore the fact that these systems still run on legacy software

and technologies might indicate that the organizations prefer reliable and

stable operation of power systems at the cost of dynamic scalability

In power system analysis the computation between conventional

and Web enabled applications has become cross-discipline in nature Using

the current Information Technology (IT) concepts the applications can be

invoked from anywhere by the users The scope of power system services

computing covers whole lifecycle of power system services innovation

research that includes Power System componentization service modelling

service creation service realization service annotation service deployment

service discovery service composition service delivery service-to-service

collaboration services monitoring services optimization and as well as

service management The goal of power systems services computing is to

adopt recent IT services and computing technologies to perform the services

more efficiently and effectively A Web service based model for doing power

system analysis is reported in the previous chapter The work mainly

concentrates on the representation of power system data and its operations in

94

PowerSystem

Client

Registry

Cloud

Services

PublishFind

Bind

Invoke

Virtual Service

Provider

Virtual Service

Provider

Virtual Service

Provider

Services

Services

Services

a distributed heterogeneous environment The computation of stability

services in SOA has also been investigated The Web service architecture

provides the capability for self-contained functions to operate over the

Internet The SOA facilitates interoperable services between distributed

systems to communicate and exchange data with one another thus providing

a uniform means for clients and service providers to discover and offer

services respectively

The extension of SOA to cloud computing architecture is shown in

Figure 41 The computation of services in cloud model is based on

distributed IT concepts that are inherent which provides the easy way of

interaction between power system applications in a heterogeneous

environment The application providers can deploy their applications without

any limitation in a cloud environment and users can access complex data rich

deployed applications from anywhere on demand basis The deployment of

applications in a cloud environment reducing the cost for service providers

when compared to other distributed environments

Figure 41 Extension of SOA to Cloud Computing Architecture

95

Cloud computing is the Internet based system development

paradigm in which large scalable computing resources are provided ldquoas

servicesrdquo over the Internet to users Web-based companies such as Google

and Amazon have built Web infrastructure to deal with computation of

applications in the cloud environment According to a survey by Gartner

(2009) nearly 90 of organizations expect to maintain or grow their usage of

applications in cloud computing environment In this research Google App

Engine a cloud computing environment provided by Google is utilized for

stability services and for exchanging power system data

In this proposed model power system clients are able to invoke the

power system services anytime from anywhere and utilize large scale storage

and computing resources On the other hand the cloud computing service

providers themselves may focus on how to distribute and scheduled the

computer resources The storage and computing on massive data are the key

technologies for a cloud computing infrastructure Nowadays the service

providers and clients interested in implementing clouds face the challenge of

integrating complex software and hardware components from multiple

vendors Cloud computing platforms are attractive because they quickly

access private and public resources on demand without any complexities The

core benefit of cloud computing is instant deployment of power system

applications which is offering immediate easy access to power system client

from any location worldwide Combined with this other important benefits

are self services The cloud based applications are instantly scalable For both

clients and service providers the successful creation and deployment of cloud

services will become the foundation for their operations

Today the latest paradigm to emerge is that of cloud computing

which promises reliable services delivered through next-generation data

centers that are built on virtualized compute and storage technologies The

96

clients will be able to access applications and data from a lsquocloudrsquo anywhere

on demand basis The power system clients are assured that the cloud

infrastructure is very robust and will always be available at any time

Computing services need to be highly reliable scalable and autonomic to

support ubiquitous access dynamic discovery and composability The

recently emerged cloud computing paradigm appears to be the most

promising one to leverage and build on the developments from other

paradigms

42 NEED FOR CLOUD SERVICES IN POWER SECTORS

The proposed cloud computing model is capable of providing the

following technical benefits for the power system industries

The ability to create the illusion of infinite capacity performance

is the same if scaled for any number of power system clients

with consistent service-level characteristics

Abstraction of the infrastructure enables the power system

applications not locked into devices or locations

The power system clients only pay for what they use with no or

minimal up-front investment costs for using the deployed power

system services in the cloud environment

Power system services are available on demand and able to

scale up and down with near instant availability Typically no

forward planning forecast is required

Access to power system applications and information can be

obtained from any access point

97

The cloud services for power system transient stability analysis

can guarantee Quality of Service (Qos) for power system

clients

The computation of power system services in a cloud computing

environment is an autonomous entity and it is managed

transparently to a power system client

The hardware software and data required for analyzing power

systems represented in cloud can be automatically reconfigured

orchestrated and consolidated to present a single platform and

finally rendered to power system clients

The above key features enable the power sectors for representing

their operations and analysis in a cloud computing environment

43 LAYERS OF CLOUD COMPUTING ARCHITECTURE

The main layers of cloud computing architecture are shown in

Figure 42 The different layered services are lsquoInfrastructure as a Servicersquo

(IaaS) layer lsquoPlatform as a Servicersquo (PaaS) layer and Software or Application

as a Service (SaaS) layer Each segment serves a different purpose and offers

different solutions to businesses and individuals Cloud computing is a model

for enabling convenient on-demand network access to a shared pool of

configurable computing resources that can be rapidly provisioned and

released with minimal management effort or service provider interaction In

simpler terms cloud computing is nothing but accessing all the computational

needs of the consumer from a single point This offers reliable services

delivered through data centers that are built on computer and storage

virtualization technologies

98

Figure 42 Layers of Cloud Computing Architecture

Clients are the devices (mobiles thick and thin clients) that the end

users interact with to manage their information on the cloud The data center

is the collection of servers where the subscribed application is housed

Distributed Servers are placed at geographically disparate locations But to

the cloud subscriber these servers act as if they were right next to each other

in the cloud environment The different layers of cloud computing

architecture are explained in the following sections

431 Infrastructure as a Service (IaaS)

The cloud infrastructure layer provides the fundamental resources

needed to provide upper level platforms and services The physical resources

along with core middleware capabilities form the basis for delivering

Infrastructure as a Service (IaaS) The services provided in this layer can be

split into three categories namely computational resources data storage and

communication The properties and design features are shared between the

above three categories are availability interoperability and security

Generally the communication is based on SOAP or Representational State

Transfer (REST) over standard HTTP The works reported in this thesis

mainly concentrated on the SOAP based communication as it makes power

system applications are more interoperable The service providers are free to

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Service Provider

Client

99

design their systems directly on top of this layer skipping the platform layer

This results in increased freedom and flexibility since providers can opt to

use an existing platform that matches the individual system or even

implement their own platform for specific cases This approach can also be

used to transfer power system applications to a cloud in order to reduce

infrastructure investments

432 Platform as a Service (PaaS)

The PaaS provides the environment for service providers to

implement their services It also provides a source code level environment

with a set of APIs to aid the interaction between cloud components and

applications scalability and ease deployment and management The Google

App Engine (GAE) provides Java runtime environment and APIs for

interacting with the cloud runtime environment The major benefit for

providers implementing their services in this layer is that the environment

provides useful features easing development and reducing development time

including automatic scaling and load balancing as well as integration with

other services The service providers are able to dedicate more of their focus

on implementing specific logic while outsourcing base functionality to

platform services

433 Software as a Service (SaaS)

The cloud application or software layer is the topmost layer in the

cloud architecture and the layer most visible to end users The services in this

layer are typically accessed through Web portals The proposed cloud

computing model has proven popular with end users because it alleviates the

need to provide support for hardware to run applications and services as well

as eliminate the need for local installation and configuration The clients can

compute their required services from their terminals to the data centers in

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 3: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

92

A deregulated electricity environment comprises of Generation

Transmission and Distribution sectors Each sector has as an independent grid

operator known as Independent System Operator (ISO) They are responsible

for the day-to-day operation of the power systems The data sharing and

integration are becoming major issues between these sectors while performing

power system operations As an analogy in open access electricity market the

demand has to be served by generation from anywhere in the interconnected

systems Cloud environment provides anytime anywhere solutions for data

sharing and integration issues

The scalability is the other issue in the current power system

network The power system operations are used by many concurrent users at a

time The systems have to be designed to handle operations by the clients and

providers without any hurdle to exchange data due to heterogeneous nature

The conventional data center does not provide the dynamic scalability The

cloud environment provides the inherent dynamic scalability for the

operations of power systems The tight coupling between various applications

is another issue in power system operations Tight coupling is possible at

different levels of the system ranging from hardware resources to

dependencies on external systems It reduces the scalability of the system

Applications which are designed to be loosely coupled should be able to

move easily into a cloud environment in contrast to tightly coupled

applications To resolve tight coupling some systems may need to be partially

redesigned to handle dynamic resources and avoid network dependencies

Inter-operations between the deregulators are common in large scale power

systems It leads to additional challenges such as how these operations can be

performed in a secure and reliable manner in a cloud computing environment

93

The power system engineers have to manage the parameters such as

real power reactive power voltage and frequency for the stable operation of

power systems To store and maintain these parameters in a cloud efforts

must be taken to ensure the information is kept safe in transport processing

and storage The Service Level Agreements (SLA) may be executed between

the provider and clients to keep the information in a safe and secure manner in

the cloud environment The cloud environment has to provide more reliable

services to the clients as the number cloud service providers have become

increased The power sectors still rely on the applications written in languages

such as FORTRAN and COBOL that are running on outdated operating

systems like UNIX or Windows NT Moving these applications to a cloud

environment would likely be expensive due to the large number of required

changes Furthermore the fact that these systems still run on legacy software

and technologies might indicate that the organizations prefer reliable and

stable operation of power systems at the cost of dynamic scalability

In power system analysis the computation between conventional

and Web enabled applications has become cross-discipline in nature Using

the current Information Technology (IT) concepts the applications can be

invoked from anywhere by the users The scope of power system services

computing covers whole lifecycle of power system services innovation

research that includes Power System componentization service modelling

service creation service realization service annotation service deployment

service discovery service composition service delivery service-to-service

collaboration services monitoring services optimization and as well as

service management The goal of power systems services computing is to

adopt recent IT services and computing technologies to perform the services

more efficiently and effectively A Web service based model for doing power

system analysis is reported in the previous chapter The work mainly

concentrates on the representation of power system data and its operations in

94

PowerSystem

Client

Registry

Cloud

Services

PublishFind

Bind

Invoke

Virtual Service

Provider

Virtual Service

Provider

Virtual Service

Provider

Services

Services

Services

a distributed heterogeneous environment The computation of stability

services in SOA has also been investigated The Web service architecture

provides the capability for self-contained functions to operate over the

Internet The SOA facilitates interoperable services between distributed

systems to communicate and exchange data with one another thus providing

a uniform means for clients and service providers to discover and offer

services respectively

The extension of SOA to cloud computing architecture is shown in

Figure 41 The computation of services in cloud model is based on

distributed IT concepts that are inherent which provides the easy way of

interaction between power system applications in a heterogeneous

environment The application providers can deploy their applications without

any limitation in a cloud environment and users can access complex data rich

deployed applications from anywhere on demand basis The deployment of

applications in a cloud environment reducing the cost for service providers

when compared to other distributed environments

Figure 41 Extension of SOA to Cloud Computing Architecture

95

Cloud computing is the Internet based system development

paradigm in which large scalable computing resources are provided ldquoas

servicesrdquo over the Internet to users Web-based companies such as Google

and Amazon have built Web infrastructure to deal with computation of

applications in the cloud environment According to a survey by Gartner

(2009) nearly 90 of organizations expect to maintain or grow their usage of

applications in cloud computing environment In this research Google App

Engine a cloud computing environment provided by Google is utilized for

stability services and for exchanging power system data

In this proposed model power system clients are able to invoke the

power system services anytime from anywhere and utilize large scale storage

and computing resources On the other hand the cloud computing service

providers themselves may focus on how to distribute and scheduled the

computer resources The storage and computing on massive data are the key

technologies for a cloud computing infrastructure Nowadays the service

providers and clients interested in implementing clouds face the challenge of

integrating complex software and hardware components from multiple

vendors Cloud computing platforms are attractive because they quickly

access private and public resources on demand without any complexities The

core benefit of cloud computing is instant deployment of power system

applications which is offering immediate easy access to power system client

from any location worldwide Combined with this other important benefits

are self services The cloud based applications are instantly scalable For both

clients and service providers the successful creation and deployment of cloud

services will become the foundation for their operations

Today the latest paradigm to emerge is that of cloud computing

which promises reliable services delivered through next-generation data

centers that are built on virtualized compute and storage technologies The

96

clients will be able to access applications and data from a lsquocloudrsquo anywhere

on demand basis The power system clients are assured that the cloud

infrastructure is very robust and will always be available at any time

Computing services need to be highly reliable scalable and autonomic to

support ubiquitous access dynamic discovery and composability The

recently emerged cloud computing paradigm appears to be the most

promising one to leverage and build on the developments from other

paradigms

42 NEED FOR CLOUD SERVICES IN POWER SECTORS

The proposed cloud computing model is capable of providing the

following technical benefits for the power system industries

The ability to create the illusion of infinite capacity performance

is the same if scaled for any number of power system clients

with consistent service-level characteristics

Abstraction of the infrastructure enables the power system

applications not locked into devices or locations

The power system clients only pay for what they use with no or

minimal up-front investment costs for using the deployed power

system services in the cloud environment

Power system services are available on demand and able to

scale up and down with near instant availability Typically no

forward planning forecast is required

Access to power system applications and information can be

obtained from any access point

97

The cloud services for power system transient stability analysis

can guarantee Quality of Service (Qos) for power system

clients

The computation of power system services in a cloud computing

environment is an autonomous entity and it is managed

transparently to a power system client

The hardware software and data required for analyzing power

systems represented in cloud can be automatically reconfigured

orchestrated and consolidated to present a single platform and

finally rendered to power system clients

The above key features enable the power sectors for representing

their operations and analysis in a cloud computing environment

43 LAYERS OF CLOUD COMPUTING ARCHITECTURE

The main layers of cloud computing architecture are shown in

Figure 42 The different layered services are lsquoInfrastructure as a Servicersquo

(IaaS) layer lsquoPlatform as a Servicersquo (PaaS) layer and Software or Application

as a Service (SaaS) layer Each segment serves a different purpose and offers

different solutions to businesses and individuals Cloud computing is a model

for enabling convenient on-demand network access to a shared pool of

configurable computing resources that can be rapidly provisioned and

released with minimal management effort or service provider interaction In

simpler terms cloud computing is nothing but accessing all the computational

needs of the consumer from a single point This offers reliable services

delivered through data centers that are built on computer and storage

virtualization technologies

98

Figure 42 Layers of Cloud Computing Architecture

Clients are the devices (mobiles thick and thin clients) that the end

users interact with to manage their information on the cloud The data center

is the collection of servers where the subscribed application is housed

Distributed Servers are placed at geographically disparate locations But to

the cloud subscriber these servers act as if they were right next to each other

in the cloud environment The different layers of cloud computing

architecture are explained in the following sections

431 Infrastructure as a Service (IaaS)

The cloud infrastructure layer provides the fundamental resources

needed to provide upper level platforms and services The physical resources

along with core middleware capabilities form the basis for delivering

Infrastructure as a Service (IaaS) The services provided in this layer can be

split into three categories namely computational resources data storage and

communication The properties and design features are shared between the

above three categories are availability interoperability and security

Generally the communication is based on SOAP or Representational State

Transfer (REST) over standard HTTP The works reported in this thesis

mainly concentrated on the SOAP based communication as it makes power

system applications are more interoperable The service providers are free to

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Service Provider

Client

99

design their systems directly on top of this layer skipping the platform layer

This results in increased freedom and flexibility since providers can opt to

use an existing platform that matches the individual system or even

implement their own platform for specific cases This approach can also be

used to transfer power system applications to a cloud in order to reduce

infrastructure investments

432 Platform as a Service (PaaS)

The PaaS provides the environment for service providers to

implement their services It also provides a source code level environment

with a set of APIs to aid the interaction between cloud components and

applications scalability and ease deployment and management The Google

App Engine (GAE) provides Java runtime environment and APIs for

interacting with the cloud runtime environment The major benefit for

providers implementing their services in this layer is that the environment

provides useful features easing development and reducing development time

including automatic scaling and load balancing as well as integration with

other services The service providers are able to dedicate more of their focus

on implementing specific logic while outsourcing base functionality to

platform services

433 Software as a Service (SaaS)

The cloud application or software layer is the topmost layer in the

cloud architecture and the layer most visible to end users The services in this

layer are typically accessed through Web portals The proposed cloud

computing model has proven popular with end users because it alleviates the

need to provide support for hardware to run applications and services as well

as eliminate the need for local installation and configuration The clients can

compute their required services from their terminals to the data centers in

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 4: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

93

The power system engineers have to manage the parameters such as

real power reactive power voltage and frequency for the stable operation of

power systems To store and maintain these parameters in a cloud efforts

must be taken to ensure the information is kept safe in transport processing

and storage The Service Level Agreements (SLA) may be executed between

the provider and clients to keep the information in a safe and secure manner in

the cloud environment The cloud environment has to provide more reliable

services to the clients as the number cloud service providers have become

increased The power sectors still rely on the applications written in languages

such as FORTRAN and COBOL that are running on outdated operating

systems like UNIX or Windows NT Moving these applications to a cloud

environment would likely be expensive due to the large number of required

changes Furthermore the fact that these systems still run on legacy software

and technologies might indicate that the organizations prefer reliable and

stable operation of power systems at the cost of dynamic scalability

In power system analysis the computation between conventional

and Web enabled applications has become cross-discipline in nature Using

the current Information Technology (IT) concepts the applications can be

invoked from anywhere by the users The scope of power system services

computing covers whole lifecycle of power system services innovation

research that includes Power System componentization service modelling

service creation service realization service annotation service deployment

service discovery service composition service delivery service-to-service

collaboration services monitoring services optimization and as well as

service management The goal of power systems services computing is to

adopt recent IT services and computing technologies to perform the services

more efficiently and effectively A Web service based model for doing power

system analysis is reported in the previous chapter The work mainly

concentrates on the representation of power system data and its operations in

94

PowerSystem

Client

Registry

Cloud

Services

PublishFind

Bind

Invoke

Virtual Service

Provider

Virtual Service

Provider

Virtual Service

Provider

Services

Services

Services

a distributed heterogeneous environment The computation of stability

services in SOA has also been investigated The Web service architecture

provides the capability for self-contained functions to operate over the

Internet The SOA facilitates interoperable services between distributed

systems to communicate and exchange data with one another thus providing

a uniform means for clients and service providers to discover and offer

services respectively

The extension of SOA to cloud computing architecture is shown in

Figure 41 The computation of services in cloud model is based on

distributed IT concepts that are inherent which provides the easy way of

interaction between power system applications in a heterogeneous

environment The application providers can deploy their applications without

any limitation in a cloud environment and users can access complex data rich

deployed applications from anywhere on demand basis The deployment of

applications in a cloud environment reducing the cost for service providers

when compared to other distributed environments

Figure 41 Extension of SOA to Cloud Computing Architecture

95

Cloud computing is the Internet based system development

paradigm in which large scalable computing resources are provided ldquoas

servicesrdquo over the Internet to users Web-based companies such as Google

and Amazon have built Web infrastructure to deal with computation of

applications in the cloud environment According to a survey by Gartner

(2009) nearly 90 of organizations expect to maintain or grow their usage of

applications in cloud computing environment In this research Google App

Engine a cloud computing environment provided by Google is utilized for

stability services and for exchanging power system data

In this proposed model power system clients are able to invoke the

power system services anytime from anywhere and utilize large scale storage

and computing resources On the other hand the cloud computing service

providers themselves may focus on how to distribute and scheduled the

computer resources The storage and computing on massive data are the key

technologies for a cloud computing infrastructure Nowadays the service

providers and clients interested in implementing clouds face the challenge of

integrating complex software and hardware components from multiple

vendors Cloud computing platforms are attractive because they quickly

access private and public resources on demand without any complexities The

core benefit of cloud computing is instant deployment of power system

applications which is offering immediate easy access to power system client

from any location worldwide Combined with this other important benefits

are self services The cloud based applications are instantly scalable For both

clients and service providers the successful creation and deployment of cloud

services will become the foundation for their operations

Today the latest paradigm to emerge is that of cloud computing

which promises reliable services delivered through next-generation data

centers that are built on virtualized compute and storage technologies The

96

clients will be able to access applications and data from a lsquocloudrsquo anywhere

on demand basis The power system clients are assured that the cloud

infrastructure is very robust and will always be available at any time

Computing services need to be highly reliable scalable and autonomic to

support ubiquitous access dynamic discovery and composability The

recently emerged cloud computing paradigm appears to be the most

promising one to leverage and build on the developments from other

paradigms

42 NEED FOR CLOUD SERVICES IN POWER SECTORS

The proposed cloud computing model is capable of providing the

following technical benefits for the power system industries

The ability to create the illusion of infinite capacity performance

is the same if scaled for any number of power system clients

with consistent service-level characteristics

Abstraction of the infrastructure enables the power system

applications not locked into devices or locations

The power system clients only pay for what they use with no or

minimal up-front investment costs for using the deployed power

system services in the cloud environment

Power system services are available on demand and able to

scale up and down with near instant availability Typically no

forward planning forecast is required

Access to power system applications and information can be

obtained from any access point

97

The cloud services for power system transient stability analysis

can guarantee Quality of Service (Qos) for power system

clients

The computation of power system services in a cloud computing

environment is an autonomous entity and it is managed

transparently to a power system client

The hardware software and data required for analyzing power

systems represented in cloud can be automatically reconfigured

orchestrated and consolidated to present a single platform and

finally rendered to power system clients

The above key features enable the power sectors for representing

their operations and analysis in a cloud computing environment

43 LAYERS OF CLOUD COMPUTING ARCHITECTURE

The main layers of cloud computing architecture are shown in

Figure 42 The different layered services are lsquoInfrastructure as a Servicersquo

(IaaS) layer lsquoPlatform as a Servicersquo (PaaS) layer and Software or Application

as a Service (SaaS) layer Each segment serves a different purpose and offers

different solutions to businesses and individuals Cloud computing is a model

for enabling convenient on-demand network access to a shared pool of

configurable computing resources that can be rapidly provisioned and

released with minimal management effort or service provider interaction In

simpler terms cloud computing is nothing but accessing all the computational

needs of the consumer from a single point This offers reliable services

delivered through data centers that are built on computer and storage

virtualization technologies

98

Figure 42 Layers of Cloud Computing Architecture

Clients are the devices (mobiles thick and thin clients) that the end

users interact with to manage their information on the cloud The data center

is the collection of servers where the subscribed application is housed

Distributed Servers are placed at geographically disparate locations But to

the cloud subscriber these servers act as if they were right next to each other

in the cloud environment The different layers of cloud computing

architecture are explained in the following sections

431 Infrastructure as a Service (IaaS)

The cloud infrastructure layer provides the fundamental resources

needed to provide upper level platforms and services The physical resources

along with core middleware capabilities form the basis for delivering

Infrastructure as a Service (IaaS) The services provided in this layer can be

split into three categories namely computational resources data storage and

communication The properties and design features are shared between the

above three categories are availability interoperability and security

Generally the communication is based on SOAP or Representational State

Transfer (REST) over standard HTTP The works reported in this thesis

mainly concentrated on the SOAP based communication as it makes power

system applications are more interoperable The service providers are free to

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Service Provider

Client

99

design their systems directly on top of this layer skipping the platform layer

This results in increased freedom and flexibility since providers can opt to

use an existing platform that matches the individual system or even

implement their own platform for specific cases This approach can also be

used to transfer power system applications to a cloud in order to reduce

infrastructure investments

432 Platform as a Service (PaaS)

The PaaS provides the environment for service providers to

implement their services It also provides a source code level environment

with a set of APIs to aid the interaction between cloud components and

applications scalability and ease deployment and management The Google

App Engine (GAE) provides Java runtime environment and APIs for

interacting with the cloud runtime environment The major benefit for

providers implementing their services in this layer is that the environment

provides useful features easing development and reducing development time

including automatic scaling and load balancing as well as integration with

other services The service providers are able to dedicate more of their focus

on implementing specific logic while outsourcing base functionality to

platform services

433 Software as a Service (SaaS)

The cloud application or software layer is the topmost layer in the

cloud architecture and the layer most visible to end users The services in this

layer are typically accessed through Web portals The proposed cloud

computing model has proven popular with end users because it alleviates the

need to provide support for hardware to run applications and services as well

as eliminate the need for local installation and configuration The clients can

compute their required services from their terminals to the data centers in

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 5: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

94

PowerSystem

Client

Registry

Cloud

Services

PublishFind

Bind

Invoke

Virtual Service

Provider

Virtual Service

Provider

Virtual Service

Provider

Services

Services

Services

a distributed heterogeneous environment The computation of stability

services in SOA has also been investigated The Web service architecture

provides the capability for self-contained functions to operate over the

Internet The SOA facilitates interoperable services between distributed

systems to communicate and exchange data with one another thus providing

a uniform means for clients and service providers to discover and offer

services respectively

The extension of SOA to cloud computing architecture is shown in

Figure 41 The computation of services in cloud model is based on

distributed IT concepts that are inherent which provides the easy way of

interaction between power system applications in a heterogeneous

environment The application providers can deploy their applications without

any limitation in a cloud environment and users can access complex data rich

deployed applications from anywhere on demand basis The deployment of

applications in a cloud environment reducing the cost for service providers

when compared to other distributed environments

Figure 41 Extension of SOA to Cloud Computing Architecture

95

Cloud computing is the Internet based system development

paradigm in which large scalable computing resources are provided ldquoas

servicesrdquo over the Internet to users Web-based companies such as Google

and Amazon have built Web infrastructure to deal with computation of

applications in the cloud environment According to a survey by Gartner

(2009) nearly 90 of organizations expect to maintain or grow their usage of

applications in cloud computing environment In this research Google App

Engine a cloud computing environment provided by Google is utilized for

stability services and for exchanging power system data

In this proposed model power system clients are able to invoke the

power system services anytime from anywhere and utilize large scale storage

and computing resources On the other hand the cloud computing service

providers themselves may focus on how to distribute and scheduled the

computer resources The storage and computing on massive data are the key

technologies for a cloud computing infrastructure Nowadays the service

providers and clients interested in implementing clouds face the challenge of

integrating complex software and hardware components from multiple

vendors Cloud computing platforms are attractive because they quickly

access private and public resources on demand without any complexities The

core benefit of cloud computing is instant deployment of power system

applications which is offering immediate easy access to power system client

from any location worldwide Combined with this other important benefits

are self services The cloud based applications are instantly scalable For both

clients and service providers the successful creation and deployment of cloud

services will become the foundation for their operations

Today the latest paradigm to emerge is that of cloud computing

which promises reliable services delivered through next-generation data

centers that are built on virtualized compute and storage technologies The

96

clients will be able to access applications and data from a lsquocloudrsquo anywhere

on demand basis The power system clients are assured that the cloud

infrastructure is very robust and will always be available at any time

Computing services need to be highly reliable scalable and autonomic to

support ubiquitous access dynamic discovery and composability The

recently emerged cloud computing paradigm appears to be the most

promising one to leverage and build on the developments from other

paradigms

42 NEED FOR CLOUD SERVICES IN POWER SECTORS

The proposed cloud computing model is capable of providing the

following technical benefits for the power system industries

The ability to create the illusion of infinite capacity performance

is the same if scaled for any number of power system clients

with consistent service-level characteristics

Abstraction of the infrastructure enables the power system

applications not locked into devices or locations

The power system clients only pay for what they use with no or

minimal up-front investment costs for using the deployed power

system services in the cloud environment

Power system services are available on demand and able to

scale up and down with near instant availability Typically no

forward planning forecast is required

Access to power system applications and information can be

obtained from any access point

97

The cloud services for power system transient stability analysis

can guarantee Quality of Service (Qos) for power system

clients

The computation of power system services in a cloud computing

environment is an autonomous entity and it is managed

transparently to a power system client

The hardware software and data required for analyzing power

systems represented in cloud can be automatically reconfigured

orchestrated and consolidated to present a single platform and

finally rendered to power system clients

The above key features enable the power sectors for representing

their operations and analysis in a cloud computing environment

43 LAYERS OF CLOUD COMPUTING ARCHITECTURE

The main layers of cloud computing architecture are shown in

Figure 42 The different layered services are lsquoInfrastructure as a Servicersquo

(IaaS) layer lsquoPlatform as a Servicersquo (PaaS) layer and Software or Application

as a Service (SaaS) layer Each segment serves a different purpose and offers

different solutions to businesses and individuals Cloud computing is a model

for enabling convenient on-demand network access to a shared pool of

configurable computing resources that can be rapidly provisioned and

released with minimal management effort or service provider interaction In

simpler terms cloud computing is nothing but accessing all the computational

needs of the consumer from a single point This offers reliable services

delivered through data centers that are built on computer and storage

virtualization technologies

98

Figure 42 Layers of Cloud Computing Architecture

Clients are the devices (mobiles thick and thin clients) that the end

users interact with to manage their information on the cloud The data center

is the collection of servers where the subscribed application is housed

Distributed Servers are placed at geographically disparate locations But to

the cloud subscriber these servers act as if they were right next to each other

in the cloud environment The different layers of cloud computing

architecture are explained in the following sections

431 Infrastructure as a Service (IaaS)

The cloud infrastructure layer provides the fundamental resources

needed to provide upper level platforms and services The physical resources

along with core middleware capabilities form the basis for delivering

Infrastructure as a Service (IaaS) The services provided in this layer can be

split into three categories namely computational resources data storage and

communication The properties and design features are shared between the

above three categories are availability interoperability and security

Generally the communication is based on SOAP or Representational State

Transfer (REST) over standard HTTP The works reported in this thesis

mainly concentrated on the SOAP based communication as it makes power

system applications are more interoperable The service providers are free to

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Service Provider

Client

99

design their systems directly on top of this layer skipping the platform layer

This results in increased freedom and flexibility since providers can opt to

use an existing platform that matches the individual system or even

implement their own platform for specific cases This approach can also be

used to transfer power system applications to a cloud in order to reduce

infrastructure investments

432 Platform as a Service (PaaS)

The PaaS provides the environment for service providers to

implement their services It also provides a source code level environment

with a set of APIs to aid the interaction between cloud components and

applications scalability and ease deployment and management The Google

App Engine (GAE) provides Java runtime environment and APIs for

interacting with the cloud runtime environment The major benefit for

providers implementing their services in this layer is that the environment

provides useful features easing development and reducing development time

including automatic scaling and load balancing as well as integration with

other services The service providers are able to dedicate more of their focus

on implementing specific logic while outsourcing base functionality to

platform services

433 Software as a Service (SaaS)

The cloud application or software layer is the topmost layer in the

cloud architecture and the layer most visible to end users The services in this

layer are typically accessed through Web portals The proposed cloud

computing model has proven popular with end users because it alleviates the

need to provide support for hardware to run applications and services as well

as eliminate the need for local installation and configuration The clients can

compute their required services from their terminals to the data centers in

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 6: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

95

Cloud computing is the Internet based system development

paradigm in which large scalable computing resources are provided ldquoas

servicesrdquo over the Internet to users Web-based companies such as Google

and Amazon have built Web infrastructure to deal with computation of

applications in the cloud environment According to a survey by Gartner

(2009) nearly 90 of organizations expect to maintain or grow their usage of

applications in cloud computing environment In this research Google App

Engine a cloud computing environment provided by Google is utilized for

stability services and for exchanging power system data

In this proposed model power system clients are able to invoke the

power system services anytime from anywhere and utilize large scale storage

and computing resources On the other hand the cloud computing service

providers themselves may focus on how to distribute and scheduled the

computer resources The storage and computing on massive data are the key

technologies for a cloud computing infrastructure Nowadays the service

providers and clients interested in implementing clouds face the challenge of

integrating complex software and hardware components from multiple

vendors Cloud computing platforms are attractive because they quickly

access private and public resources on demand without any complexities The

core benefit of cloud computing is instant deployment of power system

applications which is offering immediate easy access to power system client

from any location worldwide Combined with this other important benefits

are self services The cloud based applications are instantly scalable For both

clients and service providers the successful creation and deployment of cloud

services will become the foundation for their operations

Today the latest paradigm to emerge is that of cloud computing

which promises reliable services delivered through next-generation data

centers that are built on virtualized compute and storage technologies The

96

clients will be able to access applications and data from a lsquocloudrsquo anywhere

on demand basis The power system clients are assured that the cloud

infrastructure is very robust and will always be available at any time

Computing services need to be highly reliable scalable and autonomic to

support ubiquitous access dynamic discovery and composability The

recently emerged cloud computing paradigm appears to be the most

promising one to leverage and build on the developments from other

paradigms

42 NEED FOR CLOUD SERVICES IN POWER SECTORS

The proposed cloud computing model is capable of providing the

following technical benefits for the power system industries

The ability to create the illusion of infinite capacity performance

is the same if scaled for any number of power system clients

with consistent service-level characteristics

Abstraction of the infrastructure enables the power system

applications not locked into devices or locations

The power system clients only pay for what they use with no or

minimal up-front investment costs for using the deployed power

system services in the cloud environment

Power system services are available on demand and able to

scale up and down with near instant availability Typically no

forward planning forecast is required

Access to power system applications and information can be

obtained from any access point

97

The cloud services for power system transient stability analysis

can guarantee Quality of Service (Qos) for power system

clients

The computation of power system services in a cloud computing

environment is an autonomous entity and it is managed

transparently to a power system client

The hardware software and data required for analyzing power

systems represented in cloud can be automatically reconfigured

orchestrated and consolidated to present a single platform and

finally rendered to power system clients

The above key features enable the power sectors for representing

their operations and analysis in a cloud computing environment

43 LAYERS OF CLOUD COMPUTING ARCHITECTURE

The main layers of cloud computing architecture are shown in

Figure 42 The different layered services are lsquoInfrastructure as a Servicersquo

(IaaS) layer lsquoPlatform as a Servicersquo (PaaS) layer and Software or Application

as a Service (SaaS) layer Each segment serves a different purpose and offers

different solutions to businesses and individuals Cloud computing is a model

for enabling convenient on-demand network access to a shared pool of

configurable computing resources that can be rapidly provisioned and

released with minimal management effort or service provider interaction In

simpler terms cloud computing is nothing but accessing all the computational

needs of the consumer from a single point This offers reliable services

delivered through data centers that are built on computer and storage

virtualization technologies

98

Figure 42 Layers of Cloud Computing Architecture

Clients are the devices (mobiles thick and thin clients) that the end

users interact with to manage their information on the cloud The data center

is the collection of servers where the subscribed application is housed

Distributed Servers are placed at geographically disparate locations But to

the cloud subscriber these servers act as if they were right next to each other

in the cloud environment The different layers of cloud computing

architecture are explained in the following sections

431 Infrastructure as a Service (IaaS)

The cloud infrastructure layer provides the fundamental resources

needed to provide upper level platforms and services The physical resources

along with core middleware capabilities form the basis for delivering

Infrastructure as a Service (IaaS) The services provided in this layer can be

split into three categories namely computational resources data storage and

communication The properties and design features are shared between the

above three categories are availability interoperability and security

Generally the communication is based on SOAP or Representational State

Transfer (REST) over standard HTTP The works reported in this thesis

mainly concentrated on the SOAP based communication as it makes power

system applications are more interoperable The service providers are free to

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Service Provider

Client

99

design their systems directly on top of this layer skipping the platform layer

This results in increased freedom and flexibility since providers can opt to

use an existing platform that matches the individual system or even

implement their own platform for specific cases This approach can also be

used to transfer power system applications to a cloud in order to reduce

infrastructure investments

432 Platform as a Service (PaaS)

The PaaS provides the environment for service providers to

implement their services It also provides a source code level environment

with a set of APIs to aid the interaction between cloud components and

applications scalability and ease deployment and management The Google

App Engine (GAE) provides Java runtime environment and APIs for

interacting with the cloud runtime environment The major benefit for

providers implementing their services in this layer is that the environment

provides useful features easing development and reducing development time

including automatic scaling and load balancing as well as integration with

other services The service providers are able to dedicate more of their focus

on implementing specific logic while outsourcing base functionality to

platform services

433 Software as a Service (SaaS)

The cloud application or software layer is the topmost layer in the

cloud architecture and the layer most visible to end users The services in this

layer are typically accessed through Web portals The proposed cloud

computing model has proven popular with end users because it alleviates the

need to provide support for hardware to run applications and services as well

as eliminate the need for local installation and configuration The clients can

compute their required services from their terminals to the data centers in

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 7: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

96

clients will be able to access applications and data from a lsquocloudrsquo anywhere

on demand basis The power system clients are assured that the cloud

infrastructure is very robust and will always be available at any time

Computing services need to be highly reliable scalable and autonomic to

support ubiquitous access dynamic discovery and composability The

recently emerged cloud computing paradigm appears to be the most

promising one to leverage and build on the developments from other

paradigms

42 NEED FOR CLOUD SERVICES IN POWER SECTORS

The proposed cloud computing model is capable of providing the

following technical benefits for the power system industries

The ability to create the illusion of infinite capacity performance

is the same if scaled for any number of power system clients

with consistent service-level characteristics

Abstraction of the infrastructure enables the power system

applications not locked into devices or locations

The power system clients only pay for what they use with no or

minimal up-front investment costs for using the deployed power

system services in the cloud environment

Power system services are available on demand and able to

scale up and down with near instant availability Typically no

forward planning forecast is required

Access to power system applications and information can be

obtained from any access point

97

The cloud services for power system transient stability analysis

can guarantee Quality of Service (Qos) for power system

clients

The computation of power system services in a cloud computing

environment is an autonomous entity and it is managed

transparently to a power system client

The hardware software and data required for analyzing power

systems represented in cloud can be automatically reconfigured

orchestrated and consolidated to present a single platform and

finally rendered to power system clients

The above key features enable the power sectors for representing

their operations and analysis in a cloud computing environment

43 LAYERS OF CLOUD COMPUTING ARCHITECTURE

The main layers of cloud computing architecture are shown in

Figure 42 The different layered services are lsquoInfrastructure as a Servicersquo

(IaaS) layer lsquoPlatform as a Servicersquo (PaaS) layer and Software or Application

as a Service (SaaS) layer Each segment serves a different purpose and offers

different solutions to businesses and individuals Cloud computing is a model

for enabling convenient on-demand network access to a shared pool of

configurable computing resources that can be rapidly provisioned and

released with minimal management effort or service provider interaction In

simpler terms cloud computing is nothing but accessing all the computational

needs of the consumer from a single point This offers reliable services

delivered through data centers that are built on computer and storage

virtualization technologies

98

Figure 42 Layers of Cloud Computing Architecture

Clients are the devices (mobiles thick and thin clients) that the end

users interact with to manage their information on the cloud The data center

is the collection of servers where the subscribed application is housed

Distributed Servers are placed at geographically disparate locations But to

the cloud subscriber these servers act as if they were right next to each other

in the cloud environment The different layers of cloud computing

architecture are explained in the following sections

431 Infrastructure as a Service (IaaS)

The cloud infrastructure layer provides the fundamental resources

needed to provide upper level platforms and services The physical resources

along with core middleware capabilities form the basis for delivering

Infrastructure as a Service (IaaS) The services provided in this layer can be

split into three categories namely computational resources data storage and

communication The properties and design features are shared between the

above three categories are availability interoperability and security

Generally the communication is based on SOAP or Representational State

Transfer (REST) over standard HTTP The works reported in this thesis

mainly concentrated on the SOAP based communication as it makes power

system applications are more interoperable The service providers are free to

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Service Provider

Client

99

design their systems directly on top of this layer skipping the platform layer

This results in increased freedom and flexibility since providers can opt to

use an existing platform that matches the individual system or even

implement their own platform for specific cases This approach can also be

used to transfer power system applications to a cloud in order to reduce

infrastructure investments

432 Platform as a Service (PaaS)

The PaaS provides the environment for service providers to

implement their services It also provides a source code level environment

with a set of APIs to aid the interaction between cloud components and

applications scalability and ease deployment and management The Google

App Engine (GAE) provides Java runtime environment and APIs for

interacting with the cloud runtime environment The major benefit for

providers implementing their services in this layer is that the environment

provides useful features easing development and reducing development time

including automatic scaling and load balancing as well as integration with

other services The service providers are able to dedicate more of their focus

on implementing specific logic while outsourcing base functionality to

platform services

433 Software as a Service (SaaS)

The cloud application or software layer is the topmost layer in the

cloud architecture and the layer most visible to end users The services in this

layer are typically accessed through Web portals The proposed cloud

computing model has proven popular with end users because it alleviates the

need to provide support for hardware to run applications and services as well

as eliminate the need for local installation and configuration The clients can

compute their required services from their terminals to the data centers in

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 8: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

97

The cloud services for power system transient stability analysis

can guarantee Quality of Service (Qos) for power system

clients

The computation of power system services in a cloud computing

environment is an autonomous entity and it is managed

transparently to a power system client

The hardware software and data required for analyzing power

systems represented in cloud can be automatically reconfigured

orchestrated and consolidated to present a single platform and

finally rendered to power system clients

The above key features enable the power sectors for representing

their operations and analysis in a cloud computing environment

43 LAYERS OF CLOUD COMPUTING ARCHITECTURE

The main layers of cloud computing architecture are shown in

Figure 42 The different layered services are lsquoInfrastructure as a Servicersquo

(IaaS) layer lsquoPlatform as a Servicersquo (PaaS) layer and Software or Application

as a Service (SaaS) layer Each segment serves a different purpose and offers

different solutions to businesses and individuals Cloud computing is a model

for enabling convenient on-demand network access to a shared pool of

configurable computing resources that can be rapidly provisioned and

released with minimal management effort or service provider interaction In

simpler terms cloud computing is nothing but accessing all the computational

needs of the consumer from a single point This offers reliable services

delivered through data centers that are built on computer and storage

virtualization technologies

98

Figure 42 Layers of Cloud Computing Architecture

Clients are the devices (mobiles thick and thin clients) that the end

users interact with to manage their information on the cloud The data center

is the collection of servers where the subscribed application is housed

Distributed Servers are placed at geographically disparate locations But to

the cloud subscriber these servers act as if they were right next to each other

in the cloud environment The different layers of cloud computing

architecture are explained in the following sections

431 Infrastructure as a Service (IaaS)

The cloud infrastructure layer provides the fundamental resources

needed to provide upper level platforms and services The physical resources

along with core middleware capabilities form the basis for delivering

Infrastructure as a Service (IaaS) The services provided in this layer can be

split into three categories namely computational resources data storage and

communication The properties and design features are shared between the

above three categories are availability interoperability and security

Generally the communication is based on SOAP or Representational State

Transfer (REST) over standard HTTP The works reported in this thesis

mainly concentrated on the SOAP based communication as it makes power

system applications are more interoperable The service providers are free to

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Service Provider

Client

99

design their systems directly on top of this layer skipping the platform layer

This results in increased freedom and flexibility since providers can opt to

use an existing platform that matches the individual system or even

implement their own platform for specific cases This approach can also be

used to transfer power system applications to a cloud in order to reduce

infrastructure investments

432 Platform as a Service (PaaS)

The PaaS provides the environment for service providers to

implement their services It also provides a source code level environment

with a set of APIs to aid the interaction between cloud components and

applications scalability and ease deployment and management The Google

App Engine (GAE) provides Java runtime environment and APIs for

interacting with the cloud runtime environment The major benefit for

providers implementing their services in this layer is that the environment

provides useful features easing development and reducing development time

including automatic scaling and load balancing as well as integration with

other services The service providers are able to dedicate more of their focus

on implementing specific logic while outsourcing base functionality to

platform services

433 Software as a Service (SaaS)

The cloud application or software layer is the topmost layer in the

cloud architecture and the layer most visible to end users The services in this

layer are typically accessed through Web portals The proposed cloud

computing model has proven popular with end users because it alleviates the

need to provide support for hardware to run applications and services as well

as eliminate the need for local installation and configuration The clients can

compute their required services from their terminals to the data centers in

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 9: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

98

Figure 42 Layers of Cloud Computing Architecture

Clients are the devices (mobiles thick and thin clients) that the end

users interact with to manage their information on the cloud The data center

is the collection of servers where the subscribed application is housed

Distributed Servers are placed at geographically disparate locations But to

the cloud subscriber these servers act as if they were right next to each other

in the cloud environment The different layers of cloud computing

architecture are explained in the following sections

431 Infrastructure as a Service (IaaS)

The cloud infrastructure layer provides the fundamental resources

needed to provide upper level platforms and services The physical resources

along with core middleware capabilities form the basis for delivering

Infrastructure as a Service (IaaS) The services provided in this layer can be

split into three categories namely computational resources data storage and

communication The properties and design features are shared between the

above three categories are availability interoperability and security

Generally the communication is based on SOAP or Representational State

Transfer (REST) over standard HTTP The works reported in this thesis

mainly concentrated on the SOAP based communication as it makes power

system applications are more interoperable The service providers are free to

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Service Provider

Client

99

design their systems directly on top of this layer skipping the platform layer

This results in increased freedom and flexibility since providers can opt to

use an existing platform that matches the individual system or even

implement their own platform for specific cases This approach can also be

used to transfer power system applications to a cloud in order to reduce

infrastructure investments

432 Platform as a Service (PaaS)

The PaaS provides the environment for service providers to

implement their services It also provides a source code level environment

with a set of APIs to aid the interaction between cloud components and

applications scalability and ease deployment and management The Google

App Engine (GAE) provides Java runtime environment and APIs for

interacting with the cloud runtime environment The major benefit for

providers implementing their services in this layer is that the environment

provides useful features easing development and reducing development time

including automatic scaling and load balancing as well as integration with

other services The service providers are able to dedicate more of their focus

on implementing specific logic while outsourcing base functionality to

platform services

433 Software as a Service (SaaS)

The cloud application or software layer is the topmost layer in the

cloud architecture and the layer most visible to end users The services in this

layer are typically accessed through Web portals The proposed cloud

computing model has proven popular with end users because it alleviates the

need to provide support for hardware to run applications and services as well

as eliminate the need for local installation and configuration The clients can

compute their required services from their terminals to the data centers in

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 10: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

99

design their systems directly on top of this layer skipping the platform layer

This results in increased freedom and flexibility since providers can opt to

use an existing platform that matches the individual system or even

implement their own platform for specific cases This approach can also be

used to transfer power system applications to a cloud in order to reduce

infrastructure investments

432 Platform as a Service (PaaS)

The PaaS provides the environment for service providers to

implement their services It also provides a source code level environment

with a set of APIs to aid the interaction between cloud components and

applications scalability and ease deployment and management The Google

App Engine (GAE) provides Java runtime environment and APIs for

interacting with the cloud runtime environment The major benefit for

providers implementing their services in this layer is that the environment

provides useful features easing development and reducing development time

including automatic scaling and load balancing as well as integration with

other services The service providers are able to dedicate more of their focus

on implementing specific logic while outsourcing base functionality to

platform services

433 Software as a Service (SaaS)

The cloud application or software layer is the topmost layer in the

cloud architecture and the layer most visible to end users The services in this

layer are typically accessed through Web portals The proposed cloud

computing model has proven popular with end users because it alleviates the

need to provide support for hardware to run applications and services as well

as eliminate the need for local installation and configuration The clients can

compute their required services from their terminals to the data centers in

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 11: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

100

which the cloud is located The stability services provided with this model are

normally referred to as SaaS and has the advantage of ensuring recurring

revenue for the service provides as well as reducing the need for initial

investments for clients The advantages of providing applications and services

in this manner by power system service providers lie in the fact that it also

eases work related to upgrading patching and protecting the intellectual

property since clients are unable to access the source code The service

providers are able to roll out new features and updates without disturbing the

clients as long as the system is backward compatible with existing data

44 STABILITY ANALYSIS IN CLOUD COMPUTING

ENVIRONMENT

The modern power systems consist of many interconnected

synchronous generators large transmission network and distribution system

The size of the power system grows exponentially due to increase in power

demand The data required for various power system applications have been

stored in different formats in a heterogeneous environment The power system

applications themselves have been developed and deployed in different

platforms and language paradigms Interoperability between power system

applications becomes a major issue because of the heterogeneous nature

The main aim is to develop a cloud computing model that provides

power system transient stability analysis as a service on demand over the

Internet The power system applications developed in cloud computing

environment minimize the risk of physical infrastructure reduce the run time

and response time reduce the initial cost and increase the pace of innovation

The proposed cloud computing model for transient stability analysis is shown

in Figure 43

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 12: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

101

Cloud services for transient stability analysis

Stability Interfaces Distributed

Programming Workflows Libraries Scripting

Deploying ConfiguringMonitoring Execution of services

Stability Virtual Machine (SVM) SVM Management and Deployment

Resources Data Canter

Desktop Machine Cluster Workstations

Apps Hosting Platforms(Google App Engine)

Ad

ap

tive M

an

ag

em

ent

Au

ton

om

ic C

loud

Eco

no

my

Power System

Client

Middleware

Physical

Resources

Figure 43 Cloud Computing Model for Transient Stability Analysis

In the proposed model the stability services are stored in the

centralized location The server in the cloud environment has the control and

can manage the services stored in the ldquoStorage as a Servicerdquo layer The

advantage with this model is that even if thousands of requests are placed to

the server at a time the server will be able to offer the services

simultaneously to all the clients The ldquoStability as a Servicerdquo layer is provided

on top of an effective ldquoInfrastructure as a Servicerdquo layer that manages

virtualization of resources and multi-tenancy In this layer the stability

services such as Pre-Fault During-Fault Post-Fault and Swing curve are

available to access any time over a network to the power system client on

demand basis The power system clients can able to access the services at

anytime from anywhere on demand which makes the model robust in nature

The computation of stability services in cloud computing are highly reliable

scalable and autonomic to support ubiquitous access and dynamic discovery

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 13: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

102

441 Physical Resources for Stability Services

The physical infrastructure provides fundamental resources to

power system stability services In cloud systems computational resources

are normally provided in the form of virtual machines since it gives the users

significant flexibility because they have super-user access to their

infrastructure while protecting the data center by ensuring isolation between

different systems It has been made economically feasible due to the adoption

of virtualization techniques The lack of strict performance isolation between

VMs sharing physical nodes result in difficulty for vendors to provide strong

performance guarantees which in turn result in providers offering weaker

Service Level Agreements (SLAs) to ensure cost-effective services Data

storage is the second infrastructure resource providing cloud systems ability

to store power system data at remote sites with access from several locations

This storage service is essential to facilitate scaling applications beyond

individual servers Cloud storage services must meet several requirements

such as high availability adequate performance replication and consistency

In general cloud storage services are designed to be highly scalable and

focus primarily on availability and performance at the cost of consistency

often using the notion of eventual consistency

442 Cloud Interfaces for Transient stability Analysis

The cloud interfaces do not force the power system clients to

change their working habits and environments eg programming language

compiler and operating system This feature makes the cloud computing to

differ from Grid computing The power system clients in Grid computing

have to learn new Grid commands and APIs to access Grid resources and

services The cloud client software which is required to be installed locally is

lightweight The cloud interfaces are location independent and can be

accessed by well established interfaces like Web services framework and

Internet browser

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 14: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

103

443 Creating Uploading and Registering the Stability Services

The Google App Engine (GAE) is used for registering uploading

and accessing the stability services in the proposed cloud computing model

for transient stability analysis The GAE allows dynamic allocation of system

resources for a power system application based on the actual demand The

App Engine Software Development Kit (SDK) for Java is used to create the

stability services by the service providers The cloud applications need a

configuration file to deploy and run the application It includes the registered

ID of stability application and the version number of application and lists of

files that ought to be treated as static files and resource files (such as

stabilityjsp and other application data)

The power system applications developed using App Engine are

easy to build easy to maintain and easy to scale as traffic and data storage

needs grow There is no need to maintain the servers The applications have

been uploaded for ready to serve to power system clients App Engine is a

complete development stack that uses familiar technologies to build and host

Web applications

With App Engine the power system service providers can write

their application code test it on their local machine and then upload it on

cloud environment Once the applications are uploaded to Google it will

automatically host and scale the power system applications for the users The

service providers no longer need to worry about system administration

bringing up new instances of their application sharing their database or

buying machines In GAE the applications are built on the scalable

technologies like Google File System (GFS) and BigTable The above

technology provides automatic scaling for building applications using App

Engine The GFS is a scalable distributed file system for large distributed data

intensive applications It provides fault tolerance while running on

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 15: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

104

inexpensive commodity hardware and it delivers high aggregate performance

to a large number of clients With the above advent the App Engine can scale

to meet the power system engineers need

BigTable is a distributed column-oriented multi-dimensional

sorted map that can run on thousands of physical machines and allow for

extremely high consistency The power system data is replicated on multiple

machines and hence a hard disk failure on a given machine has no effect on

bringing the whole system down which potentially allows full consistency

even any of the Googlersquos servers were to fail at once MapReduce is a

software framework introduced by Google to support distributed computing

on large data sets on clusters of computers The power system clients specify

a map function that processes a key value pair to generate a set of

intermediate key value pairs and a reduce function that merges all

intermediate values associated with the same intermediate key Googles index

of the WWW is regenerated using MapReduce and it allows for many parallel

processing tasks in distributed applications

444 Configuring the Stability Services in Cloud

The configuration provides the information about the name of the

service and its XML schema and name of the remote interface and its

implementation The configuration of power system stability services is

represented as follows

ltxml version=10 encoding=UTF-8gt

ltappengine-web-app xmlns=httpappenginegooglecomns10

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpkenaicomprojectsnbappengine

downloadsschemaappengine-webxsd appengine-webxsdgt

ltapplicationgtpowersystemtsaltapplicationgt

ltappengine-web-appgt

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 16: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

105

The ltapplicationgt element contains the applications ID

(powersystemtsa) This is the application ID which has been created and

registered in the Google App Engine At the time of uploading the

application AppCfg gets the application ID from this file

445 Deployment of Stability Services

In the traditional Web application deployment model the power

systems services can be deployed using software and purchasing servers from

hardware vendors for storing the services Since the applications can also be

provided for external use the power sectors must also buy data center

equipments such as firewalls switches routers load balancers VPNs etc to

improve performance quality and data security The power sectors also have

to purchase bandwidth and hosting services from the third party In the server

side the power sectors need to purchase and install an operating system and

subsequently application server stacks such as Tomcat for Java LAMP for

PHP or Perl and database software like MS Access and Oracle The resulting

system can end up being expensive to build and hard to operate which

motivates the power sector to move in to cloud computing environment for

their operations The stability service provider has to provide a deployment

descriptor file in XML as given below which is to be used by the cloud to

initiate the service invocation in the lsquoappspotcomrsquo domain

ltxml version=10 encoding=UTF-8gt

ltweb-app version=25 xmlns=httpjavasuncomxmlnsjavaee

xmlnsxsi=httpwwww3org2001XMLSchema-instance

xsischemaLocation=httpjavasuncomxmlnsjavaee

httpjavasuncomxmlnsjavaeeweb-app_2_5xsdgt

ltsession-configgt

ltsession-timeoutgt30ltsession-timeoutgt

ltsession-configgt

ltwelcome-file-listgt

ltwelcome-filegtstabilityjspltwelcome-filegt

ltwelcome-file-listgt

ltweb-appgt

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 17: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

106

App Engine supports automatic compilation and URL mapping for

Java Server Pages (JSPs) Google App Engine supports secure connections

via HTTPS for URLs using the appspotcom domain When a power system

client requests an access to a URL using HTTPS both the request and the

response are encrypted transmitted and decrypted for enabling secure

operations in a cloud computing environment

446 Accessing the Services by Client

In this proposed model the power system client applications are

written in Java to access the stability services in a cloud computing

environment The Web based Administration Console in GAE provides an

environment for the power system engineers to easily manage the power

system applications which are running The client communicates with the

power system services in a cloud environment as shown in Figure 44

Figure 44 Communications with Power System Service Provider -

Cloud Environment

Power

System

Clients

Stability Services

Pre - Fault service

During ndash Fault service

Post - Fault service

Swing curve service

Compute

Cloud

Compute

Cloud

Storage

Cloud

Storage

Cloud

Load Flow Services

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 18: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

107

In cloud computing environment the power system clients can

access their required services by paying for what they use with minimal

investment costs The power sector can adopt this environment for running

their power system applications in order to improve the efficiency of their

operations demands The on demand cloud services for power system

transient stability analysis ensures Quality of Service (Qos) to the power

system clients

The Cloud services for transient stability analysis can be viewed

any where using a URL httppowersystemtsaappspotcom by the power

system clients The response of the invocation of computeSwing() service

from the cloud environment is shown in Figure 45

Figure 45 Swing Curve Response from Cloud

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 19: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

108

The proposed cloud computing model is a paradigm shift which

provides an environment for power system data centers and service providers

with an architecture that delivers highly reliable and scalable services to their

clients It is significantly more agile and cost effective than other enhanced

distributed models

45 PERFORMANCE ANALYSIS OF THE PROPOSED

MODELS

The power system transient stability analysis is being carried out

for 6 14 39 and real time TNEB large interconnected systems The major

factor that influences the performance of the proposed models is the Round

Trip Time (RTT) The RTT is the time that elapses from the initiation of a

method invocation by the power system client until the required results are

returned The power systems are highly interactive systems in which clients

are constantly providing input and waiting for their required results In this

situation keeping response times low is essential to enable power system

engineers to work efficiently

When the service invocation is carried out within the LANs RTT is

less than 10 milliseconds is normal In case of WAN the RTTs will increase

compare to LAN When multiple requests and responses are required by the

clients RTT will be further increased and it leads to a slower response of the

system The geographical distance of the resources required for design and

development of cloud services is also one of the important factors results in

the increase or decrease of RTT In distributed models the RTT is lower due

to geographical closeness of the resources Compared to distributed

environment packets will need to travel farther to reach the cloud

environment and back with latency depending on the geographical distance

to the cloud provider So the increased in RTT is unavoidable latency when

moving to a cloud environment The RTT is even more important if one cloud

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 20: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

109

based system is required the services from other clouds In cloud computing

environment the system is able to scale dynamically based on demand Since

the factor of Internet latency must be taken into account when considering

running systems in the cloud

There are several important differences between Web services and

RMI RMI is a distributed object model and enables the development of

distributed Java applications in which the methods of remote objects can be

invoked from other Java virtual machines possibly on remote hosts The

communication in RMI is based on the notion of distributed objects and

follows the object paradigm A distributed object exposes a remote interface

through which the clients can invoke methods RMI supports synchronous

requestresponse method invocation Distributed objects in RMI can be

stateful and maintain their identities The RMI communication is usually

blocked by firewalls Therefore it is appropriate mainly for communication

within LANs The RMI uses TCPIP as the underlying protocol for binary

communication which is not secured by default RMI works only between

applications developed in Java using its own framework

In Web services RTT is higher when compared to RMI The

reasons for slower performance of Web services compared to RMI are due to

message sizes transferred over the network processing overhead of the

messages and implementation related overheads The differences between

binary JRMP and XML-based SOAP message communications are also

influencing the performance of the proposed models The major portion of the

overhead is related to the introduction of the message level security and to the

textual encoding of the message content (pay load)

The RTT is estimated for performing the transient stability analysis

using enhanced distributed models such as JAX-RPC SOA and Cloud

computing The performance analysis of the different distributed models has

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 21: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

110

been carried out with respect to round trip time by considering various

numbers of clients invoking the services

The RTT estimated using JAX-RPC model is depicted in Figure 46

with the corresponding data given in Table 41

Table 41 RTT measures using JAX-RPC Model

JAX-RPC Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 39 67 88 125

25 76 112 133 199

50 115 167 217 286

75 155 204 266 372

Figure 46 RTT Vs Number of Clients in JAX-RPC

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 22: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

111

The RTT estimated using SOA model is depicted in Figure 47 with

the corresponding data given in Table 42

Table 42 RTT measures using SOA Model

SOA Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 45 73 96 132

25 84 124 159 212

50 120 178 227 307

75 179 243 285 414

Figure 47 RTT Vs Number of Clients in SOA

JAX-RPC uses the XML-based SOAP communication between

remote services SOAP builds on top of existing Internet protocols such as

HTTP FTP or SMTP Therefore SOAP can transverse firewalls seamlessly

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 23: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

112

because firewalls will treat SOAP messages similarly as other HTTP (or FTP

SMTP) messages The RTT is increased 8-12 in SOA when compared to

JAX-RPC model Because the SOA model provides the communication over

the XML-based SOAP protocol and thus enables overhead with other Web

services which do not have to be developed in Java

The RTT estimated using Cloud model is depicted in Figure 48

with the corresponding data given in Table 43

Table 43 RTT measures using Cloud Model

Cloud Computing Model

RTT in milli secondsNumber of

Clients 6 bus 14 bus 39 bus TNEB 123 bus

10 58 89 112 161

25 102 155 207 238

50 153 202 240 329

75 208 278 329 438

Figure 48 RTT vs Number of Clients in Cloud

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 24: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

113

In cloud computing environment the overhead will be inevitable

due to enhancement in the interoperability between power system applications

in heterogeneous environment It minimizes the physical infrastructure

lowering the cost and increasing the pace of innovation even though the RTT

is higher when compared to other models

Table 44 shows the functional comparison of proposed

architectural models for representing the transient stability analysis in power

systems In the table lsquo+rsquo sign means the proposed model contains desirable

properties and a lsquo-rsquo sign means the proposed model does not contain desirable

properties

Table 44 Functional Comparison of Proposed Models

Pro

po

sed

Mo

del

s

Asy

nch

ron

ou

s

Op

era

tio

n

Reu

sab

ilit

y

Sta

tefu

l se

rvic

es

Do

cum

ent

Ori

ente

dP

ay-P

er-U

se o

f

Ser

vic

es

Dy

na

mic

Sca

le

up

dow

n

Inte

rop

era

bil

ity

Sca

lab

ilit

y

On

Dem

an

d b

asi

s

Ser

vic

e

Vir

tua

liza

tio

nRMI - - + - - - - - - -

JAX-RPC + - - - - - + + - -

SOA + + - + - - + + - -

CLOUD + - - + + + + + + +

Some of the properties and issues are typically applicable in one

model cannot be available in other models For example the pay per use

service on demand service dynamic scale up down and virtualization are

exclusively cloud computing related issues marshalling SOAP message

between client and server is exclusively a Web service related issue while

reusability of services is exclusively a SOA related issue Other issues such

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf
Page 25: CHAPTER 4 CLOUD SERVICES FOR POWER SYSTEM TRANSIENT ...shodhganga.inflibnet.ac.in/bitstream/10603/10245/9/09_chapter 4.pdf · x The cloud services for power system transient stability

114

as security is common for all the proposed models But cloud computing

expands scalability than SOA by adding virtualization and grid computing

concepts The proposed cloud computing infrastructure using Google App

Engine is composed of many virtual machines that instantiated at runtime to

scale the system dynamically

46 CONCLUSION

A cloud service model for power system transient stability analysis

has been developed The power systems and their operations are more

analogous to cloud architecture and its services The cloud services can be

viewed and accessed on demand basis at anytime and anywhere that makes

rapid adoption of cloud computing in the power sectors The performance

analysis of the proposed distributed models using JAX-RPC SOA and Cloud

Computing for representing and solving transient stability problems is carried

out for the sample and real-time systems The RTT has been considered as the

performance measure and it has been estimated with respect to different

distributed models by considering the number of clients invoking the services

  • blankpdf
  • cerjpg
  • minjpg
  • bonjpg
  • Front Pages newpdf
  • chapter1pdf
  • Chapter2pdf
  • Chapter3pdf
  • Chapter 4pdf
  • Chapter 5pdf
  • Appendixpdf
  • References finalpdf