State Estimation and Network Marketing Systems

(1)

CHAPTER 4 SCALABLE AND COST EFFECTIVE MODELS FOR

STATE ESTIMATION SERVICES

4.1 INTRODUCTION

The power system has expanded to a huge system and transmission among grids is also on the increase. The generation, transmission and distribution systems in an electric power system network experience inevitable changes in its structure. Due to increasing expansion, the power system is becoming the one that is data-intensive, information-intensive, communication-intensive and computation-intensive. The need for integrated and distributed applications for power system analysis is increasing significantly from the last decade. In a large interconnected power system, the basic operations such as load flow, optimal PMU placement, state estimation, economic load dispatch etc., are being carried out using different power system applications executing in heterogeneous platforms and the data required for analysis are stored in different formats. Each power system is represented differently and implemented in different computing paradigm and hence the interoperability between various power system applications needs to be enhanced. The power system operations carried out in a control centre provide valuable information that also needs to be integrated in an efficient manner.

Currently, the researchers focus on providing Web enabled solutions for various power system operations and control. Scalability is

(2)

significant to the success of many power sectors currently involved in providing the power system services on the Web. Scalability is a measure of the ability of the application to expand to meet the power utility needs. Scalable applications are able to operate normally as they grow and can have more resources added at anytime to service more customer demands. It is very unlikely that a Web application to meet the consumer needs on a single server. At some point in time it is required to add more servers to meet increasing demands in order to meet service quality requirements.

Cloud services are becoming popular in which computing resources are made available on-demand to the user as needed. Cloud computing offers a powerful environment to scale Web applications without difficulty. In Web services environment, the clients can see only the service and not the implementation and the service providers are concerned about the infrastructure required for service delivery. The service providers cannot gain access to their applications from anywhere through their connected devices. In cloud services environment, they need not concern about the infrastructure required for the service delivery.

In the cloud computing environment, the applications are purchased, licensed and run over the network instead of the user desktop. The processing power, bandwidth and storage are all managed remotely. Startup cost for providing services in the cloud environment is inexpensive. In cloud computing, investing ahead of demand is not required and we simply use and pay for exactly what we use and when we need it. Service consumers are billed based upon server utilization, processing power used or bandwidth consumed. Large high performance power system applications can benefit from on-demand access and scalability of compute and storage resources provided by the cloud environments.

(3)

The large interconnected power system requires a common computational environment and needs to communicate between the service provider and client in a heterogeneous environment. It became obvious that to have an effective operation of the electric power grid, there needed to be a coordinated effort related to the exchange of information between applications. Since there is a tremendous growth in power systems, an architecture is needed that allows plug-in of new services or upgrading existing services in a granular fashion to address the new requirements. The power system services have to be readily available with universal visibility to be accessed by the clients. The changing environment demands that the control centres be distributed and be fully decentralized, integrated, open, flexible and able to cope up with changes in the power system network.

4.2 WEB ENABLED STATE ESTIMATION SERVICES

The existing Web enabled models for power system operations are mainly concerned with sharing of information and do not provide convenient environment for enhancing the interoperability while solving power system applications. Integration of various power system applications is a challenging task, which is of vital importance for coordinated, secure and reliable operation of the power systems. The software architecture for power system applications has experienced profound changes due to new innovations and technological growth in both electrical utilities and information technology industries.

The concept of Web based architectures overrides the concept of distributed architectures, which are emerged from component models. Inspite of these developments, it is necessary to develop a model that supports interoperability between services on different platforms in a reliable, scalable and inherently adaptable manner. Such a model provides a loosely coupled

(4)

environment wherein the services can be easily plugged in to the existing system for solving the scalability issues in power system applications.

The generalized service oriented model discussed in the last chapter is designed to meet the power system requirements using a single server environment. Dynamic scaling is an inherent feature of a cloud computing environment. The simplest model of cloud computing can be created using a pool of servers that has been virtualized using an application tool like the Web services directory, Universal Description, Discovery and Integration

(

UDDI) or a network tool used for server load balancing. This can make multiple real or virtual servers appear as a single resource, which is actually meant as a cloud environment. It is proposed to develop Web based models for providing state estimation and optimal PMU placement services and then exported them to ‘Platform as a Service’ cloud environments such as Google App Engine and Windows Azure. The Web based services are designed using UDDI registry and Model-View-Controller approach for solving state estimation and optimal PMU placement problems respectively.

State estimation is essential for the monitoring of power systems and can be obtained using Weighted Least Square algorithm. The result gives the current operating state of the power system which primarily helps in maintaining the security of the power system. The Web provides an environment for invoking the power system services from anywhere through the Internet thus providing an opportunity for the power system engineers to make effective, efficient and timely decisions by understanding the current operating state of the power system without the need for personnel visits to transmission and distribution locations. Web services based model for representation of state estimation service is shown in Figure 4.1. This model has three elements namely State Estimation Service Provider, Power System Registry and Power Systems Client.

(5)

Figure 4.1 Web Service Model for Power System State Estimation

The service provider offers the state estimation service and describes its interface using WSDL (Web Services Description Language) which is in the form of XML that makes the service available in the UDDI Registry. The step by step implementation details of the proposed Web service model for state estimation are given below and its representation as a Web service stack is shown in Figure 4.2.

Figure 4.2 Power System State Estimation Web Service Stack

WSFL UDDI UDDI WSDL SOAP HTTP

State Estimation Service Flow State Estimation Service Discovery State Estimation Service Publishing State Estimation Service Description

XML Based SOAP Messaging Network Finds the Service and its Description SOAP communicates XML Messages Publish Service and Service Description State Estimation Service Description WSDL  Available Operations  setBus  getResult  Port Information  Endpoint Details Publish service metadata

Creates interface and WSDL based service description. UDDI Registry State Estimation Service Binding Template tModel Power System State Estimation Service Client

Power System State Estimation Service Provider

(6)

The state estimation service interface is created as given below:

The configuration of the interface which is used to create state estimation service description (WSDL file) is depicted as an XML file (config.xml). The configuration file contains the information and details about the deployed state estimation service and metadata such as service name, namespace and description as given below.

public interface PSStateEstimationInt extends Remote {

public void XMLGenerationPSData() throws RemoteException public void setBus(int busno) throws RemoteException

public void getResult(double voltage, double angle) throws RemoteException; public Object[] wls() throws RemoteException;

//wls-Weighted Least Square Method } <configuration> <service name="PowerWLSService" targetNamespace="urn:power" typeNamespace="urn:power" packageName="power"> <interface name="power.PSStateEstimationInt "/> </service> </configuration>

(7)

The state estimation service description file contains descriptions about various operations like getResult() and setBus() that are represented in XML as given below:

To perform the key operations of the proposed Web service model such as publish, find and bind in an interoperable manner, there must be a state estimation Web service stack that embraces standards at each level, as shown in Figure 4.2. State estimation Web service, which is publicly available on the Internet use commonly deployed HTTP protocol. The

WSDL file contains various mapping information like

PowerWLSServiceHttpBinding, PowerWLSServiceHttpEndpoint and

portType. The portType defines input and output messages using elements defined in the <types> section. For instance, the input message setBus() is described as an endpoint.

<service name="PowerWLSService" scope="application"> <description>Power WLS Service</description>

<parameter name="ServiceClass">power.PowerWS</parameter> <operation name="setBus">

// To set the number of buses in the test system input for which the // estimate is be found out

<messageReceiver class="org.apache.axis2.receivers.

RawXMLINOnlyMessageReceiver"/> </operation>

…………..

(8)

The state estimation service description which is obtained using config.xml is given below:

<?xml version="1.0" encoding="UTF-8" ?>

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://power">

<wsdl:documentation>PowerWLSService</wsdl:documentation> <wsdl:message name="setBusRequest">

<wsdl:part name="parameters" element="ns:setBus" /> </wsdl:message> <wsdl:message name="setBusResponse" /> …… <wsdl:operation name="setBus"> <wsdl:inputmessage="ns:setBusRequest"wsaw:Action="urn:setBus"/> <wsdl:output message="ns:setBusResponse" wsaw:Action="urn:setBusResponse" /> …… <wsdl:binding name="PowerWLSServiceSoap11Binding" type="ns:PowerWLSServicePortType"> <wsdl:binding name="PowerWLSServiceHttpBinding" type="ns:PowerWLSServicePortType"> <http:binding verb="POST" /> <http:operation location="PowerWLSService/setBus" /> <wsdl:input>

<mime:content type="text/xml" part="setBus" /> </wsdl:input> <wsdl:service name="PowerWLSService"> <wsdl:port name="PowerWLSServiceHttpSoap11Endpoint" binding="ns:PowerWLSServiceSoap11Binding"> <soap:address location="http://192.168.1.7:9999/axis2/ services/PowerWLSService. PowerWLSServiceHttpSoap11Endpoint/" /> </wsdl:port> <wsdl:port name="PowerWLSServiceHttpSoap12Endpoint" binding="ns:PowerWLSServiceSoap12Binding"> <soap12:address location="http://192.168.1.7:9999/axis2 /services/Power WLSService.Power WLSServiceHttpSoap12Endpoint/" /> ………. </wsdl:definitions>

(9)

The state estimation service description file delineates how the service provider and the power system client communicate with each other, provides metadata for defining the state estimation service, represents information about the interface and also provides semantics of how to invoke a service. It contains the information about the data type, binding and address information for invoking the services from the service provider. The service provider reads this information and uses it to access the state estimation service.

The proposed Web service model for state estimation requires a registry to deploy the service for easy integration, reuse and effective governance of services to meet the growing requirements. Registry has to delegate permission to the service provider entities to publish their own service descriptions. The registry allows the power system client to discover and communicate with the services efficiently. The main purpose of the registry is to allow fast and reliable communication and interoperability among diverse applications. The state estimation service, which provides the operating state of the power system, is published in the UDDI registry using HTTP POST method.

The power system clients communicate with the state estimation service provider using SOAP messages. The body of the SOAP message represents the mandatory processing information between the client and state estimation service provider. SOAP uses the HTTP POST for request and response in the form of messages. The service details of the deployed service such as the service name, service key, bindingTemplate, tModelInstance and other details can be viewed in the UDDI registry. The UDDI Inquiry API namely the get_serviceDetail() gives the full information about the state estimation service structure.

(10)

At the time of operation, the power system clients discover the required service which is available in the Registry. Once the service is discovered, the client will query the services by their names to get the binding information and the identification of the provider. Based on this information, the clients access the provider for invoking the services.

The output will be obtained after giving the FindService Request wherein the correct keyedReference is passed which includes the keyName, keyValue and the tModel key through the SOAP message. The HTTP POST request to extract the serviceKey to find the “PowerWLSService” is given below:

POST /juddi/inquiry HTTP/1.0

Content-Type: text/xml; charset=utf-8

Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.4 Host: localhost:9999 Cache-Control: no-cache Pragma: no-cache SOAPAction: "" Content-Length: 672 ………… <soapenv:Body>

<uddiv2:find_service generic="2.0" maxRows="5"

xmlns:uddiv2="urn:uddi-org:api_v2"> <uddiv2:categoryBag>

<uddiv2:keyedReference keyName="UUID:C1ACF26D-9672-4404- 9D70-39B756E62AB4" keyValue="wsdlSpec" tModelKey="C1ACF26D- 9672-4404-9D70-39B756E62AB4"/>

(11)

The response thus obtained is shown below: HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Content-Type: text/xml;charset=utf-8 Date: Sun, 13 Jun 2010 23:55:12 GMT Connection: close

…………

<soapenv:Body>

<serviceList generic="2.0" operator="jUDDI.org" xmlns="urn:uddi-org:api_v2"> <serviceInfos> <serviceInfo businessKey="08CA9940-71EC-11DF-AA08- AAAB52B6D56F" serviceKey="8DD1B940-74EC-11DF-B940-EBD81A843E1D"> <name>PowerWLSService</name> …………

From the above response, the serviceKey is obtained. The HTTP POST request submitted to get the URL of the PowerWLSService provider using the serviceKey is as follows:

POST /juddi/inquiry HTTP/1.0

Content-Type: text/xml; charset=utf-8

Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.4 Host: localhost:9999 Cache-Control: no-cache Pragma: no-cache SOAPAction: "" Content-Length: 438

(12)

<soapenv:Body>

<uddiv2:get_serviceDetail generic="2.0" xmlns:uddiv2="urn:uddi- org:api_v2"> <uddiv2:serviceKey>8DD1B940-74EC-11DF-B940- EBD81A843E1D</uddiv2:serviceKey> </uddiv2:get_serviceDetail> </soapenv:Body> …………

The response to the above request provides the URL of the “PowerWLSService” service provider. This URL is used to bind the service.

HTTP/1.1 200 OK <soapenv:Body>

<serviceDetail generic="2.0" operator="jUDDI.org" xmlns="urn:uddi-org:api_v2"> <businessService businessKey="08CA9940-71EC-11DF-AA08-AAAB52B6D56F" <name>PowerWLSService</name> <accessPoint URLType="http">http://localhost:9999/axis2/services/PowerWLSService </accessPoint> <overviewURL>http://localhost:9999/axis2/services/PowerWLSService?wsdl </overviewURL> </soapenv:Body>

Using the URL obtained from the above response, the required PowerWLSService can be invoked. The steps involved in the invocation of state estimation service are shown in Figure 4.3. A SOAP connection is established to the destination as specified in the SOAP message; the power system client is capable of invoking the required state estimation service at the specified port. The SOAP based communication model defines a loosely

(13)

coupled and document-driven communication. Hence, the proposed Web service model for state estimation makes the service provider and the power system clients to exist in a loosely coupled environment.

Figure 4.3 Invoking the State Estimation Service

The power system clients geographically apart can access the services whenever required. The power system clients discover the service available in the registry by service names and acquire the interface information using WSDL of the state estimation service. Based on this information, the clients have a binding with the service provider and can invoke services using SOAP messages. The Web service model for state estimation service has been tested on 6-Bus, Anderson and Fouad 9-Bus, IEEE14-Bus, IEEE 30 and IEEE 118-Bus systems and the HTTP response obtained for IEEE 14-Bus system is shown below:

HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ..…… <?xml version='1.0' encoding='UTF-8'?> <soapenv:Envelope Power System Client State Estimation Service Provider SE Service End point interface WSDL Imple-mentation classes java/ XML binding SOAP Protocol Binding State Estimation service endpoint Publish WSDL Get WSDL SOAP request SOAP response

(14)

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <ns:getResultResponse xmlns:ns="http://powerws"> <ns:answer> <stateestimationdata> <psdata> <busno>1</busno> <voltage>1.0575</voltage> <angle>0.0000</angle> </psdata> <psdata> <busno>2</busno> <voltage>1.0415</voltage> <angle>-5.0159</angle> </psdata> ….. <busno>14</busno> <voltage>1.0147</voltage> <angle>-16.1906</angle> </psdata> </stateestimationdata> </ns:answer> </ns:getResultResponse> </soapenv:Body> </soapenv:Envelope>

The proposed Web service model uses static allocation for both computation and storage resources. The network administrator has to monitor the server load and manually adjust the server capacity according to the

(15)

number of users, which is unpredictable for exponentially growing large interconnected power systems. Since there is a tremendous growth in power systems, an architectural model is needed that allows plug-in of new services or upgrading existing services in a granular fashion to address the new requirements. Only a distributed environment provides an opportunity for making the power delivery more efficient, whether by minimizing the personnel visits to transmission and distribution locations or by enabling better decisions through more timely and best estimate of the power system network.

4.3 CLOUD ARCHITECTURAL MODEL FOR POWER SYSTEM SERVICES

In one perspective, the cloud computing has changed the way of development, deployment, updation and maintenance of applications and the infrastructure on which they are being executed. From another perspective, cloud computing is nothing new because it uses approaches, concepts, and best practices that have already been established. The Chairman, Microsoft Corporation India says, “it is only once in every 15-20 years that something revolutionary happens in the Information Technology sector and cloud computing certainly has the power to change the way IT will be used in future. Cloud computing when properly implemented, provides the users with greater flexibility, portability, and choice in their computing options. It allows IT to be delivered in multiple ways”. Cloud Computing reduces the capital expenditure because it is ‘pay as you go’ model.

Cloud computing defines a model where specific services are assigned to systems that are accessed through a network. It is a type of computing in which dynamically scalable and often virtualized resources are provided as services over the Internet (Buyya et al 2009). It is based on the

(16)

use of distributed computing resources that are easily allocated, de-allocated, migrated and possibly re-allocated on user request (Mancini et al 2010). As such, it relies heavily on the use of virtualization technologies that are able to offer an almost unlimited amount of virtual computing resources. With the help of virtualization, which controls the access to physical resources in a transparent way, it is possible to offer computational resources with full control for accessing various power system operations using which, the power system clients can configure them as administrators, without any restriction.

Cloud computing architectural model simplifies infrastructure while maximizing availability, scalability and performance. These features play a vital role for the usage of cloud computing architecture for power system applications. The Five major components of Cloud Computing are Application, Platform, Software, Storage and Infrastructure as shown in Figure 4.4. Applications refer to various power system applications like Load Flow, Economic Load Dispatch, Contingency Analysis, State Estimation, Optimal PMU placement etc. The cloud environment that provides Platform as a Service allows various power system applications developed using different programming paradigms to interact with each other without any modifications. It further allows adding of generation, transmission and distribution resources on demand and the power system applications need to be properly designed to scale along with the underlying hardware. When Software is provided as a Service, it allows the electrical network service providers to develop the power system services and host them in the cloud environment which are used to serve the power system clients.

(17)

Figure4.4Cloud Architectural Model for Power System Applications

A cloud infrastructure can operate solely for a particular power sector like a local distribution substation which is connected to the consumers through feeder section. Rather than purchasing the hardware and software to run various power system applications, clients need only a computer or a server to download the required power system applications and Internet access to run the software. The cloud hypervisor manages the servers and the virtual machines and thus allocates the necessary hardware on demand thereby providing Infrastructure as a Service (Reese 2009). Along with the scaling capacity of cloud platforms, we need to pay as we use similar to the electric power distribution systems, wherein we pay for the usage. Processed data can be stored securely in the cloud storage either in the form of blobs or tables depending upon the type of the data. The stored data can be accessed from anywhere at any time and therefore no data backups are required.

Infrastructure as a Service Platform as a Service Power System Applications

Storage as a Service

Integration Middleware Messaging

Hardware Abstraction Connectivity

Load Flow Economic Load Dispatch Optimal PMU Placement State Estimation

(18)

Cloud computing heavily relies on communication protocols. Standards are implemented openly to aid collaboration between services thereby providing independence between device and software. The well known PaaS (Platform as a Service) providers, Google App Engine and Azure Cloud are selected to deploy the state estimation and optimal PMU placement services. 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 reduces the cost for service providers when compared other distributed environments.

The componentized service oriented model for power system services is extended to scalable and cost-effective cloud model for solving various power system problems as shown in Figure 4.5.

Figure 4.5 Extending Service Oriented Model to Cloud Model

The service description and behaviour components are represented in the Software as a Service layer. The information component is represented in the Storage as a Service (SaaS) layer. These two layers are interacting with each other using SOAP communication. The proposed generalized service oriented model concerns about the infrastructure for service delivery. The scalability of the application is enhanced by the way of integrating the service oriented model with cloud environment as shown in Figure 4.6.

Generalized Service oriented Model

Public Cloud PaaS Providers SOAP

(19)

Figure 4.6 Proposed Cloud Representation with Inherent Service Oriented Model

The process module of the behaviour component is extended to access the Platform as a Service cloud providers to invoke the hosted services and responds to the interaction component. The action module is modified to extract the necessary deployment descriptor file and the App Engine based configuration file from the service description and to create the war file using the contents and the structure shown below. To deploy the state estimation service in Google cloud environment, a single directory named ‘stateestimation’ is used to store all the project files.

Power System clients

Platform as a Service Cloud Software as a Service Layer

Process Service Invocation Power System Services Descriptor Behaviour Component Implementation Action Decision and Deployment Interaction Component Storage as a

Service Layer Information Component

(20)

The complete project directory looks like this: stateestimation/ index.jsp busdata.xml WEB-INF/ appengine-web.xml web.xml classes/ Complex.class StateEstimate.class

The index.jsp is designated as a welcome file and it is displayed when the URL request “http://stateestimate.appspot.com” is forwarded by the process module to the client machine through interaction component. The index.jsp file displays a HTML form to obtain the general power system data from the client. Based on this data, the interaction component extracts the bus and line data required for state estimation analysis from the information component as per the schema defined and stores them in a file called “busdata.xml” under ‘stateestimation’ directory.

The following code segment in the action module prepares the directory structure and stores the necessary files at sub-level directories as per the deployment requirement of Google App Engine.

String strManyDirectories="stateestimation/WEB-INF/classes"; boolean success = (new File(strManyDirectories)).mkdirs(); String filename ="StateEstimate.class";

File f = new File(filename);

FileInputStream fis = new FileInputStream(f); byte [] buffer = new byte[(int) f.length()]; fis.read(buffer, 0, buffer.length);

(21)

fis.close();

//to store StateEstimate.class in the classes sub-directory File f1 = new File(".\\stateestimation\\WEB-INF\\classes\\"+ filename); FileOutputStream fos = new FileOutputStream(f1);

DataOutputStream dos = new DataOutputStream(fos); dos.write(buffer);

dos.close();

//to store the deployment descriptor file into WEB-INF sub-directory File f2 = new File(".\\stateestimation\\WEB-INF\\web.xml");

FileOutputStream fos1 = new FileOutputStream(f2); PrintStream ps = new PrintStream(fos1);

ps.println("<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<web-app> \n<welcome-file-list> \n ");

ps.println("<welcome-file>"+ “index.jsp” + "</welcome-file> "); ps.println("</welcome-file-list> </web-app>");

ps.close();

//similarly other required files for deployment are copied in the directory //structure

The following code segment in the action module automates the deployment procedure and uploads all the contents from the ‘stateestimation’ directory to the space reserved for the state estimation service in the Google cloud environment. Once the deployment is over, the service is ready for execution.

Runtime rt = Runtime.getRuntime();

Process p2 = rt.exec("cmd /c appcfg.cmd update c:\\gae\\stateestimation"); The action module uploads the contents of the ‘stateestimation’ directory for deployment to the Google App Engine and instructs the process module how to access the service from the cloud environment. The process

(22)

module is designed to retrieve the response from the cloud in HTML format and then formulates the SOAP response based on the values contained in the attributes and forwards the same to interaction component to dispatch to the clients.

4.3.1 Power System Services using Google App Engine

Platform as a Service (PaaS) cloud provides with an infrastructure as well as complete operational and development environments for the deployment of complex power system applications. Most commonly used PaaS cloud environment is Google App Engine. To leverage Google App Engine, the required power system application is written in Java using Google’s development framework along with tools like Google file system and data repositories. Google App Engine is selected to deploy the power system services to solve the optimal placement of phasor measurement units and power system state estimation. The architectural model for the proposed power system services in Google App Engine (GAE) cloud environment is shown in Figure 4.7.

Figure 4.7 Power System Services in Google App Engine

Power System

Services State Estimation Optimal PMU placement

Power System Management Cloud Environment Virtualization Resources Hardware

Deploying Virtual Machines Hypervisor

Power System Data Storage

Standards Runtimes Networks Execution Monitoring

Configuration Deployment

Accessibility Visualization

(23)

Platform as a Service cloud environment supplies all the resources required to build power system applications and services completely from the Internet, without having to download or install software. The other power system problems can also be implemented in a similar way in the GAE cloud environment.

4.3.1.1 State Estimation Service

The GAE allows dynamic allocation of system resources for a power system application based on the actual demand. The power system application developed using App Engine is easy to build, maintain and to scale up or down depending on the traffic and data storage.

A deployment descriptor file is to be created while deploying the state estimation service on to the GAE Cloud. The deployment descriptor file is configured as follows:

The above configuration file contains the information and details about the deployed state estimation service. On receiving the request from the client, the Web server determines all the information using this Web application deployment descriptor. An additional configuration file has to be

<web-app version="2.5" xmlns=http://java.sun.com/xml/ns/javaee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"> ……….. <welcome-file-list> <welcome-file>stateestimation.jsp</welcome-file> </welcome-file-list> </web-app>

(24)

created in order to deploy and run the state estimation service in the Google App Engine that includes an application identifier and the version number. The <application> element contains the application id (stateestimation). This is the application id which has been created and registered in the Google App Engine. The <version> element contains the version identifier for the latest version of the application. The App Engine based Web application configuration is given as follows:

Both Web service deployment descriptor (web.xml) and the App Engine based Web application configuration (appengine-web.xml) files are stored in the service description component of the proposed cloud model. Later, these files are used by the action module to develop the war file for deployment.

Generally, the App Engine Software Development Kit is used to create and upload the state estimation service by the service provider. The GAE is used for registering, uploading and accessing the state estimation problem in the proposed cloud computing model. The multi-purpose tool “appcfg” is used for uploading the state estimation service onto the cloud. At the time of uploading the information, “appcfg” gets the application id (stateestimation) from the appengine-web.xml file and uploads the contents and state estimation is provided as a service from the following URL

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

(25)

“http://www.stateestimation.appspot.com”, which can be accessed by the power system clients worldwide. The above steps have been automated using action module of the behaviour component in the proposed cloud representation model with inherent service oriented features. Hence, the solution for the given state estimation problem is provided as a service, which allows the dynamic allocation of system resources for the power system application based on the actual demand.

The power system clients can access the state estimation service from anywhere and anytime. Proper formatting and easy navigation of pages have been followed during the implementation of the state estimation service. In addition to it, the inappropriate contents and excessive contents were avoided. These few important characteristics adopted in the state estimation service implementation allow the power system clients to avail the service from any electronic gadget including a mobile client.

4.3.1.2 Optimal PMU Placement Service

It is proposed to use Struts Framework for implementing the Optimal PMU placement service before exported into Google Cloud Infrastructure. Struts is a popular open source framework, which is used to build Web applications with integration of standard technologies such as Servlets, Java Beans and Java Server Pages (JSP). Struts offer many benefits to the Web application developer, including the Model-View-Controller (MVC) design patterns in Web applications. This is one of the best practices for designing web applications.

Struts framework offers a set of tag libraries to support the faster development of the different layers for the power system Web application. The general idea behind the MVC architecture is to segregate the power system application into three layers namely the ‘model’ layer that represents

(26)

the implementation of the power system service, the ‘view’ layer that represents the power system data processed by the model component; and a ‘controller’ layer that is responsible for interaction between the model and the view. As compared with the proposed cloud representation with inherent service oriented model, the ‘model’ layer is treated as behaviour component; the ‘view’ layer represents the data formatting logic included in the interaction component, which formats the response from the process module before delivering to client and the ‘controller’ layer represents the process module along with SOAP communication.

The ‘model’ contains the power system service logic and communicates with the information component to store, retrieve and manipulate power system data through interaction component. This is actually carried out in the proposed Struts model for optimal PMU placement service by an ActionServlet, namely ‘PowerAction’, which encapsulates the Binary Integer Linear Programming logic to obtain the solution for optimal locations. PowerActionForm is a bean class, having ‘set’ and ‘get’ methods defined in it. Separate Methods have been defined for getting the number of buses and line data and for formulating the equations and the objective function. PowerAction helps to invoke the Optimal PMU placement logic by getting the input from the PowerActionForm bean class. When the client needs a power system service to be invoked, the request is received by the ‘PowerAction’ servlet that selects the appropriate view to be returned. The ‘view’ is responsible for displaying the results for the optimal PMU placement service to the power system clients, which is implemented using JSP. This ActionServlet writes the result by invoking the ‘set’ methods defined in the bean class.

In order to configure the optimal PMU placement service in the Struts environment, the PowerAction, which is an ActionServlet class, needs

(27)

initial Meta information from a configuration file called struts-config.xml as given below:

During startup, the ActionServlet reads the struts-config.xml file and creates an instance of an Action class. Processing the client request, the ‘PowerAction’ makes decision by referring to this object. ‘PowerAction’ receives the request for optimal PMU placement service and bundles all the request parameters into a JavaBean class which extends ActionForm class, namely PowerActionForm. Thus ‘PowerAction’ decides which action is to be invoked to process the request. It also validates the power system data entered by the client. The action class processes the request with the help of the ‘model’ component. After processing the request, the action class returns an ActionForward to the controller. Based on the ActionForward the controller invokes the appropriate view. To deploy and run the OPP Problem

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE struts-config PUBLIC

"-//Apache Software Foundation//DTD Struts Configuration 1.3//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_3.dtd"> <struts-config> <form-beans> <form-bean name="PowerActionForm" type="power.PowerActionForm"/> </form-beans> <action-mappings>

</action-mappings> </struts-config>

(28)

in the Google App Engine, an additional configuration file called as appengine-web.xml is required to include the application identifier (“optimumpmuplacement”) and the version number of the application. On receiving the request from the client, the Web server determines all the information using the following Web application deployment descriptor.

The HTTP response is sent to the client by the ‘view’ component. On successful execution of the PowerAction, the response is redirected to success.jsp. All the implementation classes and configuration files are bundled together and packaged into a war file which is deployed in the cloud. Once deployed, the optimal PMU placement service is provided from the

URL, “http://www.optimumpmuplacement.appspot.com”, which can be

accessed by the power system clients worldwide. <?xml version="1.0" encoding="UTF-8"?> <servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>PowerAction.do</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app>

(29)

4.3.2 Power System Services using Windows Azure

The deployment of power system services in the cloud environment is further investigated using Windows Azure Cloud. The PaaS provider, Microsoft Azure provides a framework that is based on the more ubiquitous .NET platform and hence easily portable across Microsoft environments. The state estimation and optimal PMU placement services are deployed in the Azure environment and the performance is compared with the Google cloud environment. The architectural model of the Azure cloud for providing power system services is shown in Figure 4.8. The different power system services are deployed in the Windows Azure public cloud environment in which the virtualization of power system resources is taken care by the “Infrastructure as a Service” layer. In this model, a single logical instance of the power system application is being shared by several customers. The power system clients can access the required power system service through the WebRole instance.

Figure 4.8 Power System Services in Azure Cloud Environment

Hardware Storageas a Service Azure Hypervisor Host Partition Guest Partition Guest Partition State Estimation as a Service WebRole

Client 1 Client 2 Client 3

OPP as a Service Load Balancer

(30)

The power system client interacts with the service and the WebRole instance helps in processing the request and response. The WebRole stays as a single HTTP endpoint for the external clients. The incoming request for the power system service is forwarded to the WebRole through the Load Balancer that ensures functionalities like proper load distribution and fault tolerance.

In the above architecture the state estimation service and optimal PMU placement service are included in the application layer between the WebRole and PaaS layers. The following XML document shows the description of the state estimation service that is deployed in the Azure environment. It consists of various metadata like service name, details of WebRole and the configuration settings.

The values for the service definition are configured when the WebRole instance is running. The service configuration shown below for this WebRole instance includes the number of virtual machines for each role and credentials like Account Name and Account Key.

<ServiceDefinition name="SE_Cloud"

xmlns="http://schemas.microsoft.com/

ServiceHosting/2008/10/ServiceDefinition"> <WebRole name="SE_WebRole">

(31)

The service definition and configuration files are also created for deploying optimal PMU placement service using the serviceName, OPP_Cloud and the AccountName as “optimumpmuplacement”. The state estimation service, which provides the operating states of the power system network is packaged, uploaded and deployed in the Azure Cloud environment. The clients invoke the required state estimation service through the HTTP GET method using the URL, “http://stateestimation.cloudapp.net” and the optimal PMU placement service is invoked to obtain the number of PMUs and their optimal locations in the power system network using the URL, “http://optimumpmuplacement.cloudapp.net”.

<ServiceConfiguration serviceName=" SE_Cloud " xmlns="http://schemas.microsoft.com/

ServiceHosting/2008/10/ServiceConfiguration"> <Role name=" SE_WebRole ">

(32)

The HTTP GET Request carries the bus and line data of the power system as input for which the state estimates are to be determined. The state estimation output from Azure cloud for the IEEE 14-Bus system is shown in Figure 4.9.

Figure 4.9 State Estimation Results from Azure Environment

The optimal PMU placement problem requires the bus data and the connectivity between the nodes of the power system network as input. Once the above information is provided, the OPP problem is formulated and solved using Binary Integer Linear Programming. Figure 4.10 shows the input provided by the client for solving the optimal PMU placement problem for real time 230 kV sub network, which has 8 nodes.

(33)

Figure 4.10 Input Data for OPP Service

The output for the OPP Service is obtained from the Azure Cloud which can be viewed from the Uniform Resource Locator (URL) “http://optimalpmuplacement.cloudapp.net”. The Figure 4.11 shows the results obtained for the OPP problem for real time 230 kV sub network.

(34)

The solution thus obtained for the 230 kV sub network shows that three PMUs are to be placed in buses 3, 6 and 8. The solution provides the optimal location of PMUs for the given network maintaining complete observability of the network. Solutions for different test systems namely 6-Bus, Anderson and Fouad 9-6-Bus, IEEE 14-6-Bus, IEEE 30-Bus and real time systems namely sub networks of State Electricity board 110 kV (North and South) and 400 kV Southern Region grid are also obtained.

4.4 PERFORMANCE ANALYSIS

Effective Cloud based Architectural models using GAE and Azure have been developed for solving power system problems and tested using 6-Bus, Anderson and Fouad 9-Bus, IEEE 14, IEEE 30-Bus systems and real time systems. After developing, deploying and testing the power system applications in the Azure and Google infrastructures, the request traffic, bandwidth usage and the CPU usage are tracked from the power system application console. The average elapsed time and throughput for the different power system services deployed in the Google App Engine and Windows Azure are compared and are given in Table 4.1 below:

Table 4.1 Comparison of QoS Measures for Power System Services

Average QoS Measures

State Estimation Service

Optimal PMU Placement Service

Azure GAE Azure GAE

Round Trip Time (sec) 0.645 0.734 0.32 0.43

Throughput (Mbit/sec) 29 21 30 26

The performance measures thus obtained in both the environments refer to the average values when 30 different power system clients accessed the required power system service. Request Elapsed Time is the time that

(35)

elapses between the initiation and fetching of the required service by the power system client. From the obtained performance measures, it is clear that there is a minimal difference between the two environments for accessing the services. The various characteristics of the two environments while solving the power system problems are given in Table 4.2.

Table 4.2 Comparison between two Cloud Environments

Characteristics GAE Windows Azure

Developed Language Java Asp.Net

Cost Free Free for limited usage

File Size Smaller Larger when compared with App Engine

Deployment Time Lesser Higher when compared with App Engine

The main characteristic of the cloud environment is that it is on-demand and cost effective. Further, environments like Google App

Engine provide the developers to upload and test certain specific number of applications for free of cost for a limited memory usage and other criterion. Even though Azure platform provides an environment for the developers to test their applications free of cost, it will incur charges if the application is hosted on-line for a longer period of time.

The size of the power system service developed for deploying in GAE is smaller when compared to that developed for Azure Environment. It stays as one of the reasons for a longer deployment time in Windows Azure when compared with Google App Engine. The deployment procedure in Azure environment is time consuming than in the GAE. The variations of the RTT and throughput for different power system services are shown in Figures 4.12 and 4.13.

(36)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8

State Estimation Service Optimal PMU placement Service R T T ( in se conds)

Power System Services

Azure GAE

Figure 4.12 Variation of RTT for different Power System Services

0 5 10 15 20 25 30 35

State Estimation Service Optimal PMU placement Service T hrough pu t (Mbit / sec )

Power System Services

Azure GAE

Figure 4.13 Variation of Throughput for different Power System Services

From the obtained throughput, it is clear that the Google App Engine is efficient in fetching the required service when compared with the Azure environment. One of the major concerns from the client’s perspective would be the response time, which is found to vary minimally in both the environments for the tested power system services.

(37)

4.5 CONCLUSION

Scalable Web Service models have been developed for solving state estimation and optimal PMU placement problems. The state estimation service is implemented using UDDI registry. Model-View-Controller approach is used to implement optimal PMU placement service. An innovative cloud model has been developed for providing power system services by configuring the components of the generalized service oriented model as its ‘Software as a Service’ and ‘Storage as a Service’ layers.

The power system services are implemented in two different ‘Platform as a Service’ cloud environments, namely GAE and Azure platforms, which are highly distributed and have inherent features like ease of use, dynamic scalability, reliability and low cost. The performance of the proposed cloud model has been analyzed with different test systems and the parameters like round trip time and throughput have been estimated and reported. The effectiveness of the proposed cloud service model has been validated based on these parameters. Cloud being an environment that dynamically allocates computational resources, any number of power system clients can be served with the power system services without any limitations. The scalability of power system services are enhanced by the way of integrating the service oriented model with the cloud environment.