chapter 4 cloud services for power system transient...
TRANSCRIPT
![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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/1.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/2.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/3.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/4.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/5.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/6.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/7.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/8.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/9.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/10.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/11.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/12.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/13.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/14.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/15.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/16.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/17.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/18.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/19.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/20.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/21.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/22.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/23.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/24.jpg)
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](https://reader033.vdocuments.site/reader033/viewer/2022042105/5e844b811bb02c09437f6987/html5/thumbnails/25.jpg)
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
-