Interfacing Software Agents with Power System Simulations - CiteSeerX

Interfacing Software Agents with Power System Simulations Li-Hsiang Sun, Gilberto Morejon, David Cartes The Center for Advanced Power Systems Florida State University 2000 Levy Ave, Bldg. A, Tallahassee, FL 32310 United States of America

Abstract :- A preliminary implementation of communication interface between a Multi-Agent system developed by The Center for Advanced Power Systems, and Virtual Test Bed simulation package developed by University of South Carolina is discussed. This interface enables hardware/software interaction between remote programs on several microcontrollers and system models in software simulation on a desktop or larger computer platform. Such an interface will provide Multi-Agent Systems an increased level of validation before implementation. Key-Words: - MAS, agent, simulation, Virtual Test Bed, processor in the loop

1. Introduction Objectives of Future Navy Capabilities (FNCs) include reduced manpower, reconfiguration and survivability. There is a need for software intelligence to automatically reconfigure power plants responding to various scenarios with less response time and better resulting configurations than systems operated by humans. Multi-Agent System (MAS) has been shown to be a promising technology to achieve this goal. In [1], the authors presented a MAS which automatically reconfigures a radial power plant. This system is a resource reservation network without a centralized control. Vital system information such as costs and power budgets are summarized and exchanged between neighboring agents. System reconfiguration is done by resource reservation, deallocation and re-allocation protocols triggered by events related to the power plant. This agent system is implemented in software, ideally with each agent connected to a major system component for local control actions and monitoring. Verification of the agent system requires combining the agent sub-system with the power plant to be controlled.

2. Preliminary Agent-Simulation Integration Deploying the agent system on a real radial power plant is not cost-effective for performance evaluation. It is desired that a MAS be validated using a real MAS to control a virtual power plant in simulation. This section discusses the approach we are currently taking to integrate the agent system with the Virtual Test Bed (VTB) simulation package developed by University of South Carolina. Plant configurations can be simulated in VTB using model components to represent power sources, motors, circuit breakers, etc., interconnected to form as system schematic. Fig. 1 is an example of a simple schematic. To run an outside controller in parallel with the simulation, a.k.a. processors in the loop

Fig. 1 A simple schematic in VTB

(PIL), the primary step is to establish communication channels between the simulation software and the remote processors (in our case, software agents) controlling the simulated plant. That is, to implement a interface which injects and receives signals to and from the simulation. There are plenty of models in VTB with such capability. For example, the “concurrentsim” client and server models [2] enable a large linear circuit schematic to be broken down into two parts, running as different but synchronized simulations (possibly on two computers connected through a network). The “Board Interface” model [3] enables a serial connection from a COM port of the computer running the simulation. It is used to send / receive signals to and from a micro-controller through a RS232 channel. The control algorithm is programmed in the microcontroller to control the virtual plant inside of VTB. The separation of the control and simulation verifies the implementation of the controller and enables the same algorithm to be tested in other configurations of the virtual plant. This kind of separation is very common in other disciplines. For example, in the field of Artificial Intelligence, systems are often separated into a knowledge base (the description of the world) and an inference engine. However, these models have their limitations (the limited number of COM ports for Board Interface, and that only circuit simulation distributed on two parts is suitable for concurrentsim). What is needed is a more general model to provide signal I/O to a client program written in various languages. For example, one that exports / imports signals to / from a Java application is what we need to integrate the agent system with the simulation. The remaining of this section describes the model we have developed to approach this problem.

2.1. RPC Model and Its Clients Our efforts are focused on the version of VTB for Microsoft Windows operating system, while exporting the signal I/O

capabilities of the model to the clients written in various languages and on different operating systems. Fig. 2 describes the relationship between the model and its clients. The circle in the VTB simulation schematic block is the RPC model. This model acts as a windows Remote Procedural Call (RPC) server, which processes the function calls GetSignal and SetSignal from a Microsoft Internet Information Services (IIS) web server, through windows RPC. The same two functions are exposed by the web server to the outside world as a web service using Simple Object Access Protocol (SOAP). The GetSignal function returns the value of a signal with a specific id in the VTB schematic, and the SetSignal function sets the value of a signal with an the specified id in VTB. These two functions provide a interface for clients to control and monitor the VTB simulation during runtime. The function prototypes are as follows:

double GetSignal (short id)  void SetSignal (short id, double value) The RPC model uses the Windows RPC to communicate with the web server (in this case, its client). Although it is based on the OSF RPC model and may be interoperable with other vendors' implementations of OSF RPC, it’s not interoperable with Open Network Computing (ONC) clients (Sun Microsystem’s RPC). It also lacks support for Windows CE. Due to these

Web server (IIS)

Windows RPC SOAP

VTB simulation physical connection logical connection

Java Client

Fig. 2 Relationships between VTB, IIS and clients

interoperation limitations, we exported these functions as a web service, using SOAP. SOAP message is encoded with XML. Since the encoding is standardized, the information transferred is independent of the platform specific data types. This feature enables interoperability between client and server applications in different languages and on heterogeneous platforms. There are many web services for different kind of applications. For example, Fig. 3 shows a client for popular TerraService [4], which provides aerial photo and topographic maps from USGS (the image shown is Doak Cambell Stadium of Florida State University). In our case, the model provides a web service to alter or monitor a VTB simulation. When the web server receives a SOAP function call, it decodes the XML message and changes its role as a client, forwarding the function call to the VTB RPC model using windows RPC. Once the RPC is returned, it encodes whatever it receives to XML. Then it acts as a server to return the XML message to the SOAP client. We adopt the RPC style SOAP because it is easily interoperable with Java or Perl’s SOAP packages and modules. Fig. 4 shows a sample of the SOAP message of the SetSignal request. IIS also accepts HTTP POST action to invoke the functions. That is, a browser can be used to set and get signals in VTB. Fig. 5 shows the html form to invoke the SetSignal function. On the web server, there are actually two software

POST /RPCS/service1.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://lilkim/SetSignal" short double

Fig. 4 Sample of SetSignal SOAP request

Fig. 5 Form for HTTP POST function invocation

Fig. 3 TerraClient

components. One provides web service and the other is the client for windows RPC, as shown in Fig. 6 The web service component is implemented in Visual Basic.NET, which enables the web server to accept SOAP and HTTP function invocation as described earlier. The RPC client component is a DLL

file, which is implemented in C++ as an inprocess Component Object Model (COM) object, with IDispatch interface. COM technology enables interoperability between Microsoft supported languages, so the RPC dll written in C++ can be called by web service component written in Visual Basic (VB). The by-product of implementing RPC client with a COM interface, is that the Microsoft Office application can also have the signal I/O capability to the VTB RPC model, if VB macro is enabled and the client dll is installed. In summary, as shown in Fig. 6, in the Microsoft domain, VB or C++ can be used to implement clients of the VTB model, with Windows RPC protocol directly talking to the simulation. While clients on other platforms and in other languages talk to the web server in SOAP for VTB signal I/O. Fig. 7 is an example of a remote Microsoft Excel spread sheet used to sample the output of a sine wave source in the VTB simulation on another machine. Another possible application (yet to be implemented) is that we can turn it around and use a spreadsheet to schedule events in VTB by sending signals from Excel at scheduled time.

2.2 Experiment on agent-simulation integration An experiment is carried out as a preliminary step to verify the functionality of the agent system. As shown in Fig. 8, agents may represent major system

Fig. 7 A remote Excel samples data from VTB

Computer A:

s o u rce breaker 2 bus

breaker 1

breaker 0

m o tor 1

m o tor 0

Computer B: RPC VTB / RPC server

Remote web server RPC client MS /COMobject IIS server

RPC

Remote MS host RPC client Excel / COM object spreadsheet

SOAP

HTTP Web Browser Programs on other remote machines (maybe nonMicrosoft)

Java perl Visual Basic

Fig. 6 Software architecture of the VTB interface

Fig. 8 Agents and simulation

150.00

voltage

100.00 50.00 0.00 0

0.05

0.1

0.15

0.2

0.25

0.3

-50.00

Instance 0 -100.00

X Motor 0

Y

time Bus

Motor 1

Fig. 9 Voltage of the bus and motors

14 12 10 8 6 4 2 0 -2

0

0.05

0.1

0.15

0.2

0.25

0.3

t ime

Speed_Mot or0

Speed_Mot or1

Fig. 10 Motor speeds in rps

40000 30000 power

components in a power plant, running on computer A, and VTB simulation of the same plant running on computer B. The breaker agents have control over the three breakers (0,1,2) in the simulation, i.e., the three agents are the SOAP clients of the RPC models associated with the breaker models in the VTB simulation. Initial condition of the system is that all breakers are open, motors are stopped, and bus voltage is 0. Assume both motors consume the same amount of power but the source (generator) can only supply one motor at a time. We first use motor0 agent to mark the motor as a non-vital load, and to turn on motor0. Following the procedure in [], the agent tries to reserve resource from the network. A reservation message is sent from motor0 → breaker0 → bus → breaker2 → source. The source grants this request and the inform message is sent from source → breaker2 → bus → breaker0 → motor0. As shown in Fig. 9, When the inform message is received at time X, the breaker2 agent calls the SOAP SetSignal function of the RPC model associated with breaker2, causing the breaker to close in the simulation. The bus voltage then rises to 115V. Immediately after, breaker0 agent also receives the inform message, and the same procedure is followed, causing breaker0 to close. Then motor0 has its power supply and begins accelerating and consumes power, as shown in Fig.10 and Fig.11.

20000 10000 0 -10000

0

0.05

0.1

0.15

0.2

0.25

0.3

time Electrical_Power_DCMotor0 Electrical_Power_DCMotor1

Fig. 11 Electrical powers of the motors in watts

Some short time after, we use motor1 agent to mark motor1 as a vital load to be turned on. A similar resource reservation message is sent up to bus agent. On receiving this request, the bus agent notices the source has no extra capacity, while the branch on breaker0 has a non-vital load. Thus a re-allocation message is sent following the path bus → breaker0 → motor0, to shed the non-vital load. This causes the breaker0 to open at time Y, motor0 voltage oscillates to 0, motor0 deaccelerates and stops consuming power, as shown in Fig. 9, Fig. 10, and Fig.11. Once the load on the breaker0 branch is shed, the bus grants the request from motor1, and reply the inform message following the path: bus → breaker1 → motor1. On receiving the inform message, the breaker1 agent calls the SOAP SetSignal function to close the breaker1 model in the simulation, Then motor1 voltage rises to 115V and motor1 starts spinning.

3. Discussion Although the experiment worked as we expected, there are several issues to be noted: • From the experiment we have shown, only the breaker (switch) model provides control input for connecting an associated RPC model for control signal I/O. The motor model have no input signal port for a load agent to exert control, thus the associated breaker is acted as the switch for motor. Appropriate VTB Motor Controller models are needed to support RPC manipulation. • The windows VTB is not a real-time simulator. The speed of the simulation is influenced by a number of factors, such as time step setting, complexity of the schematic, processing power of the computer, etc. The agent system is running on real-time. Thus the agentVTB integration can only provide us a functional indication on whether the agent protocol works, but not on the performance analysis such as response time evaluation of the agent network. The Real-Time Digital Simulator in The Center for Advanced Power Systems at Florida State University provides us an opportunity for the real-time verification. The authors are currently working on interfacing with this simulator. • The authors are also current working on models using Common Object Request Broker Architecture (CORBA). The child class of the VTB model will then have capabilities to act as an object accessible from computer network, thus the interaction with VTB can be greatly enhanced.

4. Conclusion A method of interfacing software agents with VTB is implemented. From our preliminary evaluation, it shows the potential for an agent system to replace human operators, and this interface for integrating with simulation software can be

a useful tool for further verification of the agent software as well as other control algorithms implemented in software.

7. Acknowledgements This work is supported by the Office of Naval Research under grant N000140210623. Reference: [1] L. Sun, D. A. Cartes, “Reconfiguration of Shipboard Radial Power System using Intelligent Agents”, Proceedings of EMTS 2004. [2] M. Maksimov, V. Bandura, “Server / Client Concurrent Simulation Model”, http://vtb.engr.sc.edu/vtb_lib/models/VT B2003_Models/Other/SConcurrentSim_ 030326.pdf http://vtb.engr.sc.edu/vtb_lib/models/VT B2003_Models/Other/CConcurrentSim_ 030326.pdf [3] S. Lentijo, A. Monti, “Processor in the Loop (PIL) Simulation”, http://vtb.engr.sc.edu/review/2003/Prese ntations/VTB_PIL_Lentijo.ppt [4] T. Barclay, J. Gray, E. Strand, S. Ekblad, J. Ritcher, “TerraService.NET: An Introduction to Web Services”, Technical Report MS-TR-2002-5