Distributed Intelligent Automated Demand Response – …i4energy.org/downloads/projects/sutardja-dai/DIADR_Ta… · · 2014-05-28A DISTRIBUTED INTELLIGENT AUTOMATED DEMAND RESPONSE

1

A DISTRIBUTED INTELLIGENT AUTOMATED DEMAND RESPONSE BUILDING MANAGEMENT SYSTEM

TASK 3

1 DOE Award Number & Name of Recipient

1.1 DOE Award Number:

DE-EE0003847

1.2 Recipient:

Regents of the University of California, (UC Berkeley campus), with Lawrence Berkeley National Lab and Siemens Corp. as sub-awardees.

2 Project Title and Principal Investigators

2.1 Project Title:

A DISTRIBUTED INTELLIGENT AUTOMATED DEMAND RESPONSE BUILDING MANAGEMENT SYSTEM

2.2 Task Title:

Task 3: Development of Service Oriented Architecture

2.3 Date of Report:

April 27, 2011

2.4 Principal Investigators:

Professor David Auslander, Department of Mechanical Engineering, U.C. Berkeley (UCB) Professor David Culler, Department of Electrical Engineering, U.C. Berkeley (UCB) Professor Paul K. Wright, Director, Center for Information Technology Research in the Interest of Society (CITRIS) and the Department of Mechanical Engineering, U.C. Berkeley (UCB) Dr. Yan Lu, Siemens Corporate Research Inc (SCR) Mary Ann Piette, Lawrence Berkeley National Laboratory (LBNL)

2.5 Key personnel:

Thomas Gruenewald, Siemens Corporate Research Inc (SCR) Prasad Mukka, Siemens Corporate Research Inc (SCR) Sila Kiliccote, Lawrence Berkeley National Laboratory (LBNL) Dr. Therese Peffer, Project Manager, U.C. Berkeley and CIEE (UCB)

DIADR Task 3

UC Berkeley, Siemens 2

2.6 Authors:

Daniel Arnold, Graduate Student Researcher, UC Berkeley, Mechanical Engineering Kevin Ding, Graduate Student Researcher, UC Berkeley, Mechanical Engineering Tyler Jones, Graduate Student Researcher, UC Berkeley, Mechanical Engineering Nathan Murthy, Student Researcher, UC Berkeley, Applied Mathematics Michael Sankur, Graduate Student Researcher, UC Berkeley, Mechanical Engineering Jay Taneja, Graduate Student Researcher, UC Berkeley, Computer Science Jason Trager, Graduate Student Researcher, UC Berkeley, Mechanical Engineering Rongxin Yin, Graduate Student Researcher, Lawrence Berkeley National Laboratory Dr. Yan Lu, Siemens Siyuan Zhou, Siemens

DIADR Task 3


Table of Contents 1 DOE Award Number & Name of Recipient ................................................................................................ 1

1.1 DOE Award Number: ........................................................................................................................... 1

1.2 Recipient: ............................................................................................................................................ 1

2 Project Title and Principal Investigators .................................................................................................... 1

2.1 Project Title: ........................................................................................................................................ 1

2.2 Task Title: ............................................................................................................................................ 1

2.3 Date of Report: .................................................................................................................................... 1

2.4 Principal Investigators: ........................................................................................................................ 1

2.5 Key personnel: .................................................................................................................................... 1

2.6 Authors:............................................................................................................................................... 2

3. Executive Summary ................................................................................................................................... 8

4. Comparison of Project Accomplishments and Project Goals.................................................................... 8

4.1 Siemens SOA Implementation Plan – 11/24/2010 ............................................................................. 8

4.2 Plan Verification and Adjustment – 12/8/2010 .................................................................................. 9

4.3 SOA Porting to Selected Hardware Platform – 3/30/2011 ................................................................. 9

4.4 Testing – 4/6/2011 .............................................................................................................................. 9

4.5 Demonstration of SOA on Selected Hardware Platform with Defined Communication Protocol - 4/20/2011 ................................................................................................................................................. 9

4.6 Documentation – 4/27/2011 .............................................................................................................. 9

5. Project Summary ..................................................................................................................................... 10

5.1 Task III ............................................................................................................................................... 11

6. The Energy Information Gateway (Gateway) ......................................................................................... 11

6.1 Residential and Commercial Gateway .............................................................................................. 11

6.1.2 Background ................................................................................................................................ 11

6.1.3 Extension to Commercial Spaces ............................................................................................... 12

6.2 Gateway Programming Languages and Technologies ...................................................................... 13

6.2.1 Java ............................................................................................................................................. 13

6.2.2 OSGi ............................................................................................................................................ 13

6.2.3 JADE............................................................................................................................................ 15

6.2.4 XML ............................................................................................................................................ 16

6.3 Gateway Services .............................................................................................................................. 16

6.3.1 Control Service ........................................................................................................................... 16

6.3.2 Event Service .............................................................................................................................. 17

6.3.3 WebUI Service ............................................................................................................................ 18

DIADR Task 3


6.3.4 Net Service ................................................................................................................................. 19

6.3.5 ACME Service ............................................................................................................................. 19

6.3.6 Raritan Service ........................................................................................................................... 20

6.3.7 sMAP Service .............................................................................................................................. 22

6.3.8 WattStopper Service .................................................................................................................. 22

6.3.9 XBee Service ............................................................................................................................... 22

6.3.10 JADE Agent Service................................................................................................................... 23

6.3.11 JADE Runtime Service .............................................................................................................. 23

6.4 Gateway Architecture ....................................................................................................................... 23

6.4.1 Appliance and Control Command Objects ................................................................................. 23

6.4.2 OSGi Bundles .............................................................................................................................. 24

6.4.3 Utility Bundle – Gateway.OSGi.utility ........................................................................................ 24

6.4.4 Control Bundle – Gateway.OSGi.Control ................................................................................... 25

6.4.4 Event Bundle– Gateway.OSGi.Event .......................................................................................... 26

6.4.5 WebUI Bundle – Gateway.OSGi.WebUI ..................................................................................... 26

6.4.6 OpenADR Service Bundle – Gateway.OSGi.OpenADR ............................................................... 26

6.4.7 Ethernet Service Bundle – Gateway.OSGi.Ethernet .................................................................. 26

6.4.8 WiFi Appliance Bundle – Gateway.OSGi.WiFi.Appliance ........................................................... 27

6.4.9 ACME Service Bundle – Gateway.OSGi.ACME ........................................................................... 27

6.4.10 ACME Appliance Bundle – Gateway.OSGi.ACME.Appliance .................................................... 27

6.4.11 Raritan Service Bundle – Gateway.OSGi.Raritan ..................................................................... 27

6.4.12 Raritan Appliance Bundle – Gateway.OSGi.Raritan.Appliance ................................................ 28

6.4.13 sMAP Bundle – Gateway.OSGi.SMAP ...................................................................................... 28

6.4.14 WattStopper Bundle – Gateway.OSGi.WattStopper ............................................................... 28

6.4.15 WattStopper Appliance Bundle – Gateway.OSGi.WattStopper.Appliance ............................. 29

6.4.16 Time Service Bundle – Gateway.OSGi.TimeService ................................................................. 29

6.4.17 XBee Bundle - Gateway.OSGi.XBee .......................................................................................... 29

6.4.18 GWAgent Bundle - Gateway.OSGi.GWAgent .......................................................................... 29

6.4.19 Gateway JADE Bundle – Gateway.OSGi.JADE .......................................................................... 31

7 External Bundles and External Simulations ............................................................................................. 31

7.1 Smart Appliance Simulation - Appliance.Simulation.WiFi ................................................................ 32

7.2 Laptop Simulation - Laptop.Simulation.WiFi .................................................................................... 33

7.3 Event.Test.Simulation ....................................................................................................................... 35

7.4 Jade.Test.SEB .................................................................................................................................... 35

8 Web User Interface .................................................................................................................................. 36

DIADR Task 3


9 Hardware.................................................................................................................................................. 37

9.1 Raritan Power Distribution Unit (PDU) ............................................................................................. 38

9.2 ACme WiFi Sensor and Switch .......................................................................................................... 39

9.3 Uninterruptible Power Supply (UPS)................................................................................................. 39

9.4 Sensor Box ......................................................................................................................................... 39

10 Gateway Functionality ........................................................................................................................... 40

11. Gateway Testing .................................................................................................................................... 42

11.1 Sample Test ..................................................................................................................................... 43

12. Conclusion and Future Work ................................................................................................................ 46

References .................................................................................................................................................. 47

DIADR Task 3


Table 1: Utility bundle packages and files................................................................................................... 25 Table 2: Control bundle packages and files ................................................................................................ 25 Table 3: Event bundle packages and files ................................................................................................... 26 Table 4: WebUI bundle packages and files ................................................................................................. 26 Table 5: OpenADR Bundle Packages ........................................................................................................... 26 Table 6: Ethernet Bundle Packages ............................................................................................................. 27 Table 7: ACME Bundle Packages ................................................................................................................. 27 Table 8: Raritan Bundle Packages ............................................................................................................... 28 Table 9: SMAP Bundle Packages and Files .................................................................................................. 28 Table 10: WattStopper Bundle packages and files ..................................................................................... 29 Table 11: XBee Bundle packages and files .................................................................................................. 29 Table 12: GW Agent Bundle packages ........................................................................................................ 31 Table 13: Appliance Simulation Behaviors .................................................................................................. 32 Table 14: Appliance Simulation Bundle Packages ....................................................................................... 32 Table 15: Laptop Simulation Behaviors ...................................................................................................... 34 Table 16: Laptop Simulation Packages ........................................................................................................ 34 Table 17: Raritan DPX-8 Measurements ..................................................................................................... 38 Table 18: Sensor Box Components ............................................................................................................. 39

DIADR Task 3


Figure 1: DIADR System Overview .............................................................................................................. 10 Figure 2 - Energy Information Gateway in a residential environment ....................................................... 12 Figure 3 - Commercial Energy Gateway ...................................................................................................... 13 Figure 4 - The Gateway in the OSGi framework ......................................................................................... 14 Figure 5: JADE Framework .......................................................................................................................... 15 Figure 6: JADE Message Communication .................................................................................................... 16 Figure 7: JADE Communication ................................................................................................................... 30 Figure 8: JADE Communication ................................................................................................................... 30 Figure 9: Gateway Agent GUI ...................................................................................................................... 31 Figure 10: Appliance Simulation GUI .......................................................................................................... 33 Figure 11: Laptop Simulation GUI ............................................................................................................... 34 Figure 12: SEB, GW...................................................................................................................................... 35 Figure 13: SEB Agent GUI ............................................................................................................................ 36 Figure 14: Home page of WebUI ................................................................................................................. 36 Figure 15: WebUI Operation Page .............................................................................................................. 37 Figure 16: Raritan DPX-8 1U........................................................................................................................ 38 Figure 17: ACme meter ............................................................................................................................... 38 Figure 18: Gateway Interaction with Appliances ........................................................................................ 41 Figure 19: Gateway Control Bundle logic during DR event ......................................................................... 42

DIADR Task 3


3. Executive Summary The Distributed Intelligent Automated Demand Response (DIADR) project endeavors to develop an energy management system with intelligent optimization and control algorithms to achieve 30% peak load reduction while still maintaining the building as a healthy, productive, and comfortable environment for the building occupants. The selected building site is Sutardja Dai Hall at UC Berkeley. Two earlier reports outlined the System Architecture and the Building Management System integration with the OpenADR protocol that administers the demand response signals. This report describes Task 3, the development of Develop Service Oriented Architecture for distributed intelligent ADR management System. The Service Oriented Architecture developed for Task 3 is known as the Energy Information Gateway (EIG or Gateway for short). The Gateway is a communication and control software system that enables the user to monitor and manage power loads more effectively and efficiently. This report begins with a discussion of the background of and motivation for the Gateway, and a comparison to other existing and similar products. The next section describes the technologies that the Gateway utilizes as a software system. This refers to the programming languages the Gateway utilizes, frameworks that are implemented, and protocols used. The next section describes the services that the Gateway provides. These services are explained according to their basic function; their specific methods are detailed also. Next, software modules, called bundles, are described. Their respective packages and files are detailed and their purposes explained. External software code and its relation to the Gateway and its services is explained. These include external simulations that interact with the Gateway and external bundles that are used to consume services. Hardware that the Gateway communicates with and utilizes as part of its function is described as well as their communication methods. The functionality of the Gateway is detailed. Finally testing of this functionality and output from a sample test are analyzed. The contribution from this task on the overall project is a system that enables the DR strategies and algorithms to be employed efficiently and effectively. The impact of this project is to further automated demand response systems which will have several beneficial effects on society, if implemented on a large scale.

4. Comparison of Project Accomplishments and Project Goals

4.1 Siemens SOA Implementation Plan – 11/24/2010

The delivery date of this goal was about two months after the formal start of the project in October 2010. However, the implementation plan had already been created. This plan stated that the commercial Gateway would be developed alongside the residential Gateway, which was at the time, and currently still is, being developed by Dan Arnold for a CIEE sponsored project.

DIADR Task 3


4.2 Plan Verification and Adjustment – 12/8/2010

This plan was verified in part due to the benefit of having multiple developers along with having a base to build the commercial version of the Gateway from.

4.3 SOA Porting to Selected Hardware Platform – 3/30/2011

By this date, the Gateway had nearly all of its current functionality, with most of the services listed in this report in place and debugged. Several services such as SMAP Service and WattStopper service did not exist at this point. The Gateway was being run on laptop and desktop computers instead of on the envisioned embedded hardware platform.

4.4 Testing – 4/6/2011

The Gateway has gone through extensive testing throughout its development. All new services and code is tested and debugged. By this date, the Gateway was able to provide appliance control during a simulated DR event.

4.5 Demonstration of SOA on Selected Hardware Platform with Defined Communication Protocol - 4/20/2011

By this date, the Gateway has defined communication protocols for both smart appliances and dumb appliance hardware. It was not ported to a hardware platform, as the development of the software package was given higher priority, and so was still being run on a laptop or desktop computer. All major services in this report have been included and were tested for functionality problems.

4.6 Documentation – 4/27/2011

This report fulfills this goal. There was also a joint demonstration between UC Berkeley and Siemens personnel on this date on the UC campus in the test laboratory. For more information, including presentations and video, please email project coordinator Therese Peffer ([email protected] ).

DIADR Task 3


5. Project Summary Sutardja Dai Hall is a 141,000 square foot building on the UC Berkeley campus that houses the Center for Information Technology Research in the Interest of Society (CITRIS). Much of the building occupancy is dedicated to offices, with a few classrooms, an auditorium, café and a nanofabrication lab that is not included in the project’s energy reduction goals. The whole building demand load is approximately 940kW. The diagram below describes the basic system architecture: a demand response signal is sent by the Demand Response Automated Service (DRAS) and is received by the Siemens Smart Energy Box (SEB) installed in Sutardja Dai Hall at UC Berkeley. The SEB then generates a load shedding goal sent to the Building Automation System for the HVAC system, the WattStopper lighting system, and to the distributed load gateways that control appliances.

Figure 1: DIADR System Overview

Siemens met with the facilities manager to determine which elements of the building could be subject to demand response control and which were not allowed. (The building houses an energy-intensive nanofabrication laboratory that is not included in the energy reduction goals of the project, but shares chilled water with the whole building). Initial control strategies include: to expand the allowable building zone setpoints (minimum to 69F and maximum to 78F), the pre-cooling to 69F before occupied, the ability to change duct static pressure and supply air speed, and the capability to turn off some air handling units, supply fans, and exhaust fans. For lighting, some overhead lighting units can be dimmed (stepped dimming). UC Berkeley conducted a plug load audit of the building to determine gateway controllable loads.

DIADR Task 3


5.1 Task III

Task 3 of the DIADR project is to develop a service oriented architecture for a distributed automated demand response management system. This architecture is known as the Energy Information Gateway, which will be referenced to simply as the Gateway throughout this report.

6. The Energy Information Gateway (Gateway) This section describes the Gateway. It provides background to technologies used as well as information on the services the Gateway provides. Software code is explained and the interface with hardware used is also detailed.

6.1 Residential and Commercial Gateway

The Energy Information Gateway (EIG) which provides connectivity and control among office appliances in this project is a direct spinoff from another UC Berkeley project concerned with residential load management. This section is dedicated to providing background on the residential EIG (henceforth known as the Residential Energy Gateway, or REG), whose architecture is identical to the EIG employed for commercial office load management in this project.

6.1.2 Background The installation of smart meters in residences across California has opened the realm of the residence to the possibility of advanced energy consumption monitoring and control. These new meters have the ability to enable ZigBee communication with devices inside what is known as the HAN, or Home Area Network (also known as the Home Energy Network, or HEN). While this radio is not currently enabled, its placement in the smart meter has spurred a small but rapidly growing industry of so called “smart” energy appliances and devices which intend to communicate with the smart meter and beyond. What is lacking in this space is a set standard of communication between these devices. While some might utilize ZigBee (a proprietary standard) or Zwave, others rely on Wi-Fi or Ethernet. What results from this is a hodgepodge of devices which lack standardization and are intimidating and confusing to consumers. The concept of an information gateway is hardly a new one. Currently, many such products exist designed to provide communications between the smart meter and appliances. However, the lack of standardization that so frightens the consumer also prevents these gateways from being able to communicate with devices of a different manufacturer. For example, a GE gateway can communicate with a GE washer, but not a Maytag. These problems present themselves in a commercial office setting as well (only the smart meter is now exchanged with a building energy management and control system). [1]

DIADR Task 3


Figure 2 - Energy Information Gateway in a residential environment

Recognizing a need for standardization of communication within this space, the California Public Utilities Commission (CPUC) established funding for the Residential Energy Gateway project, research for which is being conducted in the Mechanical Engineering department at UC Berkeley. The prototype being developed at UC Berkeley alleviates these restrictions on communication interoperability by providing an open source standard and software package based on widely available communications protocols. A logic diagram for a residential version of the Energy Information Gateway is shown in Figure 2. As the figure shows, within the HEN, the Gateway is able to communicate with all residential appliances, the smart meter, the HVAC system, and on site local generation. In addition, with the exception of the smart meter’s periodic connection to the utility, the Gateway is the portal through which HAN information is linked with the outside world. Perhaps most importantly, the Gateway connects to a resident user interface, through which information about all other connected elements can be viewed.

6.1.3 Extension to Commercial Spaces When viewed from an input/output sense, it is not difficult to extend the communications and control architecture see in Figure 2 to a commercial setting. In this space, elements of the HEN or HAN are replaced with their commercial equivalents for a single office or small group of offices. In addition, communication external to the office is no longer made between the Gateway and the utility, but the Gateway and the building’s energy management and control system (EMCS). The visualization of this dual architecture is seen in Figure 3. As the graphic shows, the Commercial EIG is the link between elements of the office energy network, including: the occupant user interface, office appliances, HVAC setpoints, lighting and occupancy sensors, and a local database (provided one exists). In addition, the Commercial EIG is the link between these local office elements and the building’s EMCS, which is capable of communication with the utility and demand response centers. With the exception of the local database, this architecture is completely analogous to the residential setting seen in Figure 2. The application of the EIG to a commercial setting makes the storage of past energy usage data within the

DIADR Task 3


local office itself a possibility (thus the inclusion of the Database connection in the local office energy network). [2]

Figure 3 - Commercial Energy Gateway

6.2 Gateway Programming Languages and Technologies

6.2.1 Java Java is one of the most widely known and used programming languages in use today. It is a strong typed, object oriented programming language. The Java development community is very active and there exists many add-ons, plug-ins, libraries and frameworks for Java. Java is also an object-oriented language which lends itself to the Gateway development, as appliances can be programmed as objects easing their control. One such framework, the OSGi, which is discussed below, is utilized by Java and thus makes it an optimal choice for the GW.

6.2.2 OSGi The Open Services Gateway Initiative, or OSGi, is a modular software framework for JAVA, in which the EIG is written. OSGi supports the dynamic integration and operation of modular, semi-self-contained, pieces of JAVA code known as “bundles”. Once installed into the OSGi framework, bundles can be dynamically started, stopped, and updated, which allows for pieces of the framework to be operated on independently. OSGi is service oriented, meaning that bundles installed in the framework can create services for consumption by other bundles. Both the residential and commercial EIG make use of the modularity and service oriented architecture of OSGi to establish robust communications with external appliances. [3]

DIADR Task 3


As an example of the use of the service oriented architecture, please consider the following situation: The core software package of the EIG contains an Ethernet bundle, which create and exports the “NetService” service to the OSGi framework. NetService provides the capability for an external appliance to connect to the Gateway over a TCP/IP connection (Ethernet or WiFi. An appliance manufacturer wishing to connect his or her appliance to the EIG over a WiFi connection needs only create and install a bundle to the OSGi framework, and direct that bundle to consume NetService. While this process may seem a bit intimidating, the EIG team has created a set of templates and detailed instructions which streamlines the creation and installation of new bundles into the framework. Making use of the service oriented architecture in OSGi, the EIG team has developed other more specialized services which provide further functionality including: participation in Demand Response events, executing appliance control, and hosting a local web user interface. The EIG in the context of OSGi can be seen in Figure 4. Within the figure, blue ovals denote bundles and green boxes denote services. Bundles on the figure’s left hand side represent the “core” bundles of the EIG. This collection is responsible for providing the services on the far right hand side of the figure. The bundles in the center of the figure, WiFi Appliance and ZigBee Appliance, can consume the provided services. These bundles represent specific appliances within the HAN or office, such as a refrigerator or laser printer. Red lines below these bundles imply that the Gateway can support the integration of an undetermined amount of appliances, just using the services seen in the figure. As one might infer from this figure, connecting appliances within the HAN or office to the EIG allows supervisory control over these appliances to be applied. Currently, such control is enabled during a demand response event, which is obtained through a connection to an OpenADR server via OpenADRService.

Figure 4 - The Gateway in the OSGi framework

DIADR Task 3


6.2.3 JADE The Java Agent DEvelopment framework (JADE) is a framework written in Java for the development of agent based interaction and behaviors. It was developed by the Foundation for Intelligent Physical Agents (FIPA) as a communication protocol. The JADE framework allows a user to create several agent classes, each with user specified behaviors. The JADE framework contains a service called the Directory Facilitator (DF), which is similar to a phonebook in that agents can advertise their behaviors and other agents can look up agents according to desired behaviors. [4] The Gateway uses JADE as a communication protocol and communication medium to communicate with the Siemens Smart Energy Box (SEB). Currently, the Gateway receives DR events from the SEB. In the future, multiple Gateways will communicate with a SEB and within each other to achieve the DR power reduction goal. JADE (Java Agent DEvelopment framework) is a software Framework fully implemented in Java language, and is Open Source distributed under LGPL license. JADE simplifies the implementation of multi-agent systems through a middle-ware that complies with the FIPA specifications and through a set of graphical tools that supports the debugging and deployment phases. The agent platform can be distributed across machines (which do not even need to share the same OS) and the configuration can be controlled via a remote GUI. The configuration can be even changed at run-time by moving agents from one machine to another, as and when required. JADE is completely implemented in Java language and the minimal system requirement is the version 1.4 of JAVA (the run time environment or the JDK). JADE has the following characteristics in Figure 5:

1. A JADE-based application is composed of a collection of active components called Agents: 2. Each agent has a unique name 3. Each agent is a peer since he can communicate in a bidirectional way with all other agents 4. Each agent lives in a container, which can be hosted on different machines.

Figure 5: JADE Framework

DIADR Task 3


Each agent has a sort of mailbox where messages for that agent are inserted. When a message is put in the mailbox the agent is notified. However, it will be up to the agent to decide if and when to read the message and how to react to it. Figure 6 shows the JADE messaging mechanism.

Figure 6: JADE Message Communication

Each JADE agent is an intelligent, autonomous component, which can communicate and negotiate with other agents as well as make decisions based on its own information. The characteristics of JADE agents and their ability to construct a peer-to-peer network fit into the market-based relationship between SEB and multiple Gateways very well. Therefore, the JADE agent-based mechanism has been chosen as the framework for communications and negotiations between SEB and Gateways.

6.2.4 XML One goal of the Gateway is to provide an open-standard and open-source software package. One part of this goal is to a make the GW a platform that is agnostic to other devices platform, OS, etc. To do this, XML (eXtensible Markup Language) is used as the primary communication protocol so that smart appliance manufacturers need only to conform to the XML schemas used for communication. XML has a parent-child structure in that elements (objects) can have sub-elements, and these sub-elements can have their own sub-elements. Elements are demarcated by tags that begin with <tag> and close with </tag>. Elements can have attributes assigned to them within the tag structure. These features of XML make it a natural choice to use as a communication language as it enables both simple and complex control commands to be formed and transmitted.

6.3 Gateway Services

The following sections describe the various services the Gateway provides to the OSGi framework. A paragraph explains the basic function of the service, and the services’ methods and description are also included. These can be skipped without loss in continuity, however the methods give important insight into the function and scope of each service. It should be noted that these services are subject to change as the Gateway is constantly evolving.

6.3.1 Control Service Each external appliance connection, Wi-Fi, Raritan, ACme (each implementation of Ne tService or Raritan Service or ACME Service) will bind its implementation of NetService or Raritan Service to a new interface object of IControlService and then will export this unique service object to the OSGi

DIADR Task 3


framework. This is a very technical way of saying that each appliance is individually controllable. All Control Service service objects are then consumed by the Control Bundle where control action takes place. All Control Service objects have access to the IControlService interface which is characterized by the following methods: public Appliance getData();

- Returns an Appliance data object (see section on Appliance and Control Command objects)

public void writeToAppliance(ControlCommand cc);

- Writes a Control Command object to the specified service or location

public String getConnectionName();

- Returns the connection name of a WiFi connection associated with an appliance, and therefore Appliance object

6.3.2 Event Service The Gateway contains the Event Service which creates and registers DR events within the OSGi framework. The Event Service also monitors the timing of events and informs the control bundle when an event is starting and stopping. The Event Service is consumed by multiple bundles, such as the Control bundle, Web UI bundle and Gateway Agent bundle. Event Service uses the OSGi Service Factory since multiple bundles may consume the service simultaneously. IEventServiceFactory allows the OSGi framework to distinguish between multiple implementations (multiple DR events) of the same service object. Bundles consuming this service do so through the IEventService and IEventControl interface. The IEventService interface contains the following methods, with description underneath: public void createEvent (Calendar startTime, Calendar stopTime, double desPowerLevel, String eventType);

- Creates a DR event using Java Calendar objects of startTime and stopTime. The parameter desPowerLevel is the fraction of power the Gateway will reduce the total load to from the base load. The type of event is given as a string parameter eventType.

public void createEvent(int ds, int dur, double desPow, String type);

- Creates a DR event within the OSGi framework. This method does not use Java Calendar objects, but instead uses integer minute delays. The parameter ds is the minutes in integers to the start of the DR event from current time, and dur is the duration of the event in minutes. The parameter desPow is the same as above.

public void terminateEvent();

- Removes the DR event from the OSGi framework, ending control services related to this event

DIADR Task 3


The IEventControl interface contains the following methods, with description underneath: public int getState();

- Returns the state of the DR Event as an integer.

public Calendar getStartTime();

- Return the start time of the DR event in a Java Calendar object.

public Calendar getStopTime();

- Returns the stop time of the DR event in a Java Calendar object.

public int getEventDuration();

- Returns the DR event duration in minutes as an integer

public double getDesPower();

- Returns the DR event desired power level fraction of base load as a double

public String getEventType();

- Returns the DR event type

public boolean getStartTrans();

- Returns a boolean stating if the DR event is starting

public void setStartTrans(boolean in);

- Allows another service or external bundle to start a DR event. This is also utilized by the Even Service for timing purposes.

public boolean getStopTrans();

- Returns a boolean stating if the DR event is stopping

public void setStopTrans(boolean in);

- Allows another bundle to stop a DR event. This is also utilized by the Even Service for timing purposes.

public String getTimeString();

- Returns a time string of current system time in the format yyyy.mm.dd.hh.mm.ss.msmsms

6.3.3 WebUI Service The Gateway provides services to create a connection to a locally hosted web page that the user can utilize to change preferences and view power use and appliance state. This is done via the WebUI

DIADR Task 3


Service. This service uses XML to transmit Appliance objects and Control Command objects. This service is exported through the IWebUI interface. The IWebUI interface contains the following methods, with description underneath: public String getConnectionName();

- Returns the connection name of the WiFi connection associated with the Appliance object

public void writeToUI(Appliance o);

- Sends an Appliance object to the Web UI. The Appliance object contains data such as connection parameters and power usage data.

public ControlCommand getCC();

- Returns a Control Command object from the Web UI to the Gateway.

public boolean getCommState();

- Returns the communication state between the Web UI and Gateway

6.3.4 Net Service The Gateway provides services to create socket server connections on the Gateway host machine. This is done via the Net Service. Net Service creates socket connections, receives XML data from appliance simulations and sends XML control commands. The Net Service uses the OSGi Service Factory as multiple bundles may consume the service at an instant. INetServiceFactory allows the OSGi framework to distinguish between different implementations of the same service object. Bundles consuming this service do so through the interface INetService. The INetService interface contains the following methods, with description underneath: public void makeWiFiConnection(String name, int portNum, int timeOut, boolean writeEnable, boolean delayFlag, boolean interruptFlag);

- Creates the WiFi Connection (Socket Server) with user specific connection name (name), port number (portNum), time out parameter (timeout) and other parameters. This is called from WiFi.Appliance external bundles to create an instance of Net Service within the Control Service.

public void closeWiFiConnection();

- Closes the WiFi Connection (Socket Server), interrupts all threads in net service. This is called from WiFi.Appliance bundles

6.3.5 ACME Service

DIADR Task 3


The Gateway provides a service called ACME Service that allows it to connect to an ACME WiFi load switch, retrieve data and toggle internal relays if available. The service creates a UDP (User Datagram Protocol) socket on the Gateway host machine for a user specified port, which the ACMEs are programmed to report to. It passively receives ACME data packets and parses them into information. The ACME Service uses the OSGi Service Factory as multiple bundles may consume the service at an instant. IACMEServiceFactory allows the OSGi framework to distinguish between different implementations of the same service object. Bundles consuming this service do so through the interface IACMEService. The IACMEService interface contains the following methods, with description underneath: public void startAcmeService();

- Starts the ACME Service. This is called from the ACME.Appliance bundle.

public void stopAcmeService();

- Stops the ACME Service. This is called from the ACME.Appliance bundle.

6.3.6 Raritan Service The Gateway provides Raritan Service to connect to a Raritan DPX-8 (and other Raritan devices able to use SSH) and query it for data as well as send outlet control commands. The connection is created via secure shell (SSH) which can be done over WiFi or a wired Ethernet connection. The Raritan service uses the OSGi ServiceFactory as multiple bundles may consume the Raritan Service at one time. IRaritanServiceFactory allows the OSGi framework to distinguish between different implementations the same service object. Bundles consuming this service do so through the IRaritanService and IRaritanControl interfaces. The IRaritanService interface contains the following methods, with description underneath: public void startRaritanService(String raritanIP, String userName, String passWord, String unitName);

- Starts the Raritan Service with specified IP address, username, password and unit name. This is called from the Raritan.Appliance Bundle activator. This creates a Raritan Service object within the Control Service.

public void stopRaritanService();

- Stops the Raritan Service, interrupting all threads within Raritan Service. This is called from the Raritan.Appliance Bundle activator.

The IRaritanControl interface contains the following methods, with description underneath: public int getOutletPowerState(int outletNum);

- Obtains the power state (1 = On, 0 = Off) of the specified outlet (outletNum)

DIADR Task 3


public void setOutletPowerState(int outletNum, int powerState);

- Sets the power state (1 = On, 0 = Off) of the specified outlet (outletNum)

public double getOutletCurrent(int outletNum);

- Obtains the current in Amps for the specified outlet

public double getOutletMaxCurrent(int outletNum);

- Obtains the maximum current in Amps for the specified outlet

public double getOutletPowerFactor(int outletNum);

- Obtains the power factor for the specified outlet

public double getOutletActualPower(int outletNum);

- Obtains the actual power (true power) in Watts for the specified outlet

public double getOutletApparentPower(int outletNum);

- Obtains the apparent power in Watts for the specified outlet

public void writeControlCommand(ControlCommand cc);

- Allows other bundles to send a control command object from their bundle to the Raritan Service.

public String getUnitName();

- Obtains the unit name.

public boolean getConnectionState();

- Obtains a Boolean signifying whether the SSH connection is valid or not

public String[] getOutletApplianceName();

- Obtains a string array with names of appliances corresponding to each outlet

public int[] getOutletPriority();

- Obtains an integer array with priorities of appliances corresponding to each outlet

public Appliance getOutletApplianceObject(String connectionName);

- Returns an Appliance Data Object for the specified connection name.

public Appliance getOutletApplianceObject(int outletNum);

- Returns an Appliance Data Object for the specified outlet number.

DIADR Task 3


6.3.7 sMAP Service The Gateway provides a service to create connection to Raritan PDUs (see section on Peripheral Hardware) and uses its command line protocol (CLP) to obtain all pertinent unit and outlet information. The connection is made using SSH over WiFi/LAN and data is obtained using XML. This data is parsed and translated into a JSON object which is posted to URLs for sMAP insertion. This service is currently written to only be instantiated once during Gateway operation, so does not rely on INetServiceFactory. The service is exported through the interface ISMAPService. The interface ISMAPService contains the following methods, with description underneath. public void startRaritanSMAPService();

- Starts the sMAP Service and is called by the Gateway.OSGi.SMAPService activator

public void stopRaritanSMAPService();

- Stops the sMAP Service and is called by the Gateway.OSGi.SMAPService activator

This service is in transition to being integrated into the Raritan Service. This will allow for better control of data gathering and to decrease the possibility of synchronization issues with the hardware.

6.3.8 WattStopper Service WattStopper Service is a service that will soon be added to the Gateway. This service will allow the Gateway to connect to the BACnet interface and control lighting in the laboratory adjacent to the test lab. This service is exported through the interface IWattStopperService, which contains only one method, described below. public void setLightLevel(int area, int powerState); - Sets the light level, specified by powerState, of a certain area, specified by the integer area.

6.3.9 XBee Service XBee Service provides services to control XBee devices. Bundles importing the XBeeService service will have access to the interface IXBeeService, which is characterized by the following methods: The IXBeeService interface contains the following methods, with description underneath: public void openCoordinatorPort(String comPortName);

- Opens a COM port to the XBee chip connected to the GW machine. The COM port is specified by comPortName.

public void closeCoordinatorPort();

- Closes the COM port so that the connection is terminated.

DIADR Task 3


public boolean startListenToDevice(String deviceId);

- Tells the Gateway to start listening to the XBee device specified by deviceID.

public boolean stopListenToDevice(String deviceId);

- Tells the Gateway to stop listening to the XBee device specified by deviceID.

public String getData(String deviceId, String dataName);

- The method getData is the method to get data from the XBee device, using argument String deviceId to indicate the device, and argument String dataName to indicate which of the data returned from the device is being fetched.

6.3.10 JADE Agent Service This service starts a JADE agent, called a GatewayAgent. This agent has behaviors that allow it to search for SEB Agents, and obtain DR event information. It is currently in development at Siemens Corporate Research.

6.3.11 JADE Runtime Service The JadeRuntimeService is provided by Gateway.OSGi.JADE bundle, and can be used by other bundles to run JADE on top of the OSGi framework.

6.4 Gateway Architecture

A Service Oriented Architecture is a set of design principles in which a suite of interoperable services can be used within multiple, separate systems. The OSGi framework lends itself naturally to developing a service oriented architecture. This will be further discussed. Bundles and their functions will also be further discussed.

6.4.1 Appliance and Control Command Objects The Appliance.java class is a class used to transmit appliance simulation data from smart appliance simulations to the Gateway, and also to pass information within the Gateway. This class is also used by services such as Raritan Service to present its data to the Control Service in an easily parsed way. When utilized by smart appliance simulations, this object is marshaled into an XML object and passed to the Gateway. It is then unmarshaled from XML to a java Appliance object and sent to the Control Service. The Appliance class contains the following fields:

- String connectionName – Connection name of the appliance and Appliance object - String time – Time value in format yyyy.mm.dd.hh.mm.ss.msmsms - double power – Power value in Watts - int power – Integer value for the port number the appliance simulation is using

DIADR Task 3


- boolean drFlag – Boolean value stating whether the appliance is participating in a DR event - boolean powerState – Boolean stating whether the appliance is in operation or not (On or Off) - int priority – Integer value of the appliances priority, used for priority based control method - boolean underControl – Boolean stating whether the appliance is under Gateway control - int behaviorState – Integer value used by smart appliance simulations to change their internal

dynamics or behavior.

All of these fields have methods that allow the Gateway to set them to a certain value, and methods to return the value. The ControlCommand.java class is a class used to transmit commands from the Gateway to smart appliance simulations. This class is also used to set the power state of Raritan PDU outlets, by being passed from the Control Service to Raritan Service. When passed to an appliance simulation the object is marshaled into an XML object, transmitted via WiFi, then unmarshaled from XML to a ControlCommand object on the appliance side. The Control Command class has the following fields:

- String adrEventStatus – DR event status - String connectionName – Connection name of the appliance and Appliance object - String time – Time stamp in form yyyy.mm.dd.hh.mm.ss.msmsms - double commandEnergyVal – Double giving desired power value from Gateway - boolean delayStart – Boolean stating whether the appliance will delay starting its behavior - boolean drFlag – Boolean stating whether the Gateway is in a DR event - int setPriority – Integer from Gateway to change the priority value of appliance - boolean operationState – Boolean stating desired power state from Gateway - int behaviorState – Boolean stating desired behavior from Gateway - boolean setControl – Boolean stating whether or not the Gateway is assuming control of appliance

All of these fields have methods that allow the Gateway to set them to a certain value, and methods to return the value.

6.4.2 OSGi Bundles As discussed earlier, the GW relies on the OSGi framework to provide a service oriented architecture. This is accomplished via creating discrete bundles that export and consume specific services. The following sections detail the individual bundles and their contents, including packages and important files. The following sections, until 6.5, can also be optionally skipped without missing continuity in understanding the Gateway.

6.4.3 Utility Bundle – Gateway.OSGi.utility The utility bundle contains several packages that are utilized in multiple other bundles throughout the Gateway.

Package - gateway.OSGi.utility File Description

.clientcomm Appliance.java XML schema for appliance data objects

ObjectFactory.java Allows for multiple uses of above schema

DIADR Task 3


.IACMEService IAcmeService.java Interface for AcmeService

.IControlService IControlService.java Interface for ControlService

.IEventService IEventService.java Interface for EventService

.INetService INetService.java Interface for NetService

.IOpenADRService IOpenADRService.java Interface for OpenADRService

.IRaritanService IRaritanService.java Interface for RaritanService

IRaritanControl.java Interface for RaritanControl

.ISMAPService ISMAPService.java Interface for SMAPService

.ITimeService ITimeService.java Interface for TimeService

.IWattStopperService IWattStopperService.java Interface for WattStopperService

.IWebUIService IWebUIService.java Interface for WebUIService

.net.tinyos.message AcReport.java Class used to retrieve data from UDP packets from ACMEs

Message.java Super-class of AcReport.java

.servercomm ControlCommand.java XML schema for control command objects

ObjectFactory.java Allows multiple uses of above schema

Table 1: Utility bundle packages and files

The Java classes AcReport.java and Message.java were written at Berkeley to decode tinyos messages. The ControlCommand and Appliance classes are used for appliance-Gateway communication and are described above.

6.4.4 Control Bundle – Gateway.OSGi.Control The Control bundle provides the Control Service to the Gateway which includes supervisory control of the Gateway and control of appliances and devices connected and registered with the GW.

Package – gateway.OSGi. File Description

.control ControlActivator.java OSGi bundle Activator for Control Bundle

.control.internal GatewayControl.java Registers OSGi events and services within framework

GCLogic.java Logic algorithm for start and stop of DR events

Time.java Used for timing purposes

.control.interal.GUI GatewayGUI.java GUI for Gateway (in development)

.control.interal.openADR OpenADRControl.java Used for control of OpenADR Service

.control.interal.Raritan RaritanHandler.java Creates array of Raritan Service objects

Table 2: Control bundle packages and files

DIADR Task 3


6.4.4 Event Bundle– Gateway.OSGi.Event The Event bundle provides services to create a DR event and register it with the OSGi framework.

Package File Description

.event EventActivator.java OSGi bundle activator for Event Bundle

.event.internal EventService.java Event service that can be exported via interface in Utility Bundle

IEventServiceFactory.java Allows for multiple instances of Event Service to be created

Time.java Used for timing purposes Table 3: Event bundle packages and files

6.4.5 WebUI Bundle – Gateway.OSGi.WebUI The WebUI bundle provides services to communicate with the web user interface. This includes services to export data from the Gateway to the UI, and obtain configuration data from the UI.


.webui WebUIActivator.java OSGi bundle activator for WebUI Bundle

.webui.internal WebUI.java Provides WebUI service for communication to Web UI

Time.java Provides time comparison and timing methods

Table 4: WebUI bundle packages and files

6.4.6 OpenADR Service Bundle – Gateway.OSGi.OpenADR The OpenADR provides services to communicate with an Akuacom server to obtain DR event information.


.openadr OpenADRActivator.java OSGi bundle activator for OpenADR Bundle

.openadr.internal OpenADRService.java Provides OpenADR Service Table 5: OpenADR Bundle Packages

6.4.7 Ethernet Service Bundle – Gateway.OSGi.Ethernet The Ethernet bundle provides services to create a socket on the Gateway host machine.

DIADR Task 3



.ethernet EthernetActivator.java OSGi bundle activator for Ethernet Bundle

. ethernet.internal NetService.java Contains Net Service that allows for WiFi communication over sockets

INetServiceFactory.java Allows for multiple instances of Net Service Objects

Time.java Used for timing purposes Table 6: Ethernet Bundle Packages

6.4.8 WiFi Appliance Bundle – Gateway.OSGi.WiFi.Appliance The WiFi.Appliance bundle utilizes the services provided by the Ethernet bundle to create a socket connection on the Gateway host machine with a user specified port. This bundle is able to be cloned for multiple sockets on different ports. When this bundle is activated a Net Service object is created in the Control Service. This object contains the methods of Net Service but lives within the Control Bundle.

6.4.9 ACME Service Bundle – Gateway.OSGi.ACME The Acme bundle provides services to create a UDP socket for ACME data communication. It also provides services to post the data to SMAP.


.acme AcmeServiceActivator.java OSGi bundle activator for ACME Bundle

. acme.internal AcmeService.java Contains ACME Service for Acme communication

IAcmeServiceFactory.java Allows for multiple instances of ACME Service objects

Table 7: ACME Bundle Packages

6.4.10 ACME Appliance Bundle – Gateway.OSGi.ACME.Appliance The ACME.Appliance bundle utilizes the services provided by the ACME bundle to start and stop the service. When activated, a ACME Service object is created inside Control Service. This object has the methods of ACME Service and lives within the Control Bundle.

6.4.11 Raritan Service Bundle – Gateway.OSGi.Raritan The Raritan bundle provides services to connect to a Raritan DPX via SSH to poll for data and send control commands.


.raritan RaritanActivator.java OSGi bundle activator for

DIADR Task 3


Raritan Bundle

. raritan.internal RaritanService.java Contains Raritan Service

IRaritanServiceFactory.java Allows for multiple instances of Raritan Service objects

.ch.ethz.xxxx Java SSH library Table 8: Raritan Bundle Packages

The library used to create and use SSH connections is from Ganymed SSH-2 for Java (http://www.ganymed.ethz.ch/ssh2/).

6.4.12 Raritan Appliance Bundle – Gateway.OSGi.Raritan.Appliance The Raritan.Appliance bundle utilizes the services from the Raritan bundle to start and stop the services. This allows for multiple Raritan connections. When this bundle is started a Raritan control object is registered in the framework. The activator in this bundle passes the IP address of the PDU to be connected to the startRaritanService method in Raritan Service. This bundle can be cloned for multiple instances of the Raritan Service.

6.4.13 sMAP Bundle – Gateway.OSGi.SMAP The sMAP bundle provides the sMAP service, which connects to Raritan PDUs and queries for all pertinent data. This service also parses the data and posts it to sMAP.


.smap SMAPActivator OSGi bundle Activator for SMAP Bundle

.smap.internal SMAPService Contains SMAP Service

.ch…. Library used to create SSH connections

.org.json JSON library Table 9: SMAP Bundle Packages and Files

The library used to create and use SSH connections is from Ganymed SSH-2 for Java (http://www.ganymed.ethz.ch/ssh2/). The JSON library can be found here (https://github.com/douglascrockford/JSON-java/archives/master).

6.4.14 WattStopper Bundle – Gateway.OSGi.WattStopper The WattStopper bundle provides the WattStopper service, which allows the Gateway to turn off lights adjacent to the test lab.


.wattstopper WattStopperActivator OSGi bundle activator for WattStopper Bundle

.wattstopper.internal WattStopperService Contains WattStopper Service

http://www.ganymed.ethz.ch/ssh2/

http://www.ganymed.ethz.ch/ssh2/

https://github.com/douglascrockford/JSON-java/archives/master

DIADR Task 3


Table 10: WattStopper Bundle packages and files

6.4.15 WattStopper Appliance Bundle – Gateway.OSGi.WattStopper.Appliance This bundle solely contains the wattstopper.appliance package which contains the file WattStopperApplianceActivator.java file. This activator consumes the WattStopper Service through its interface and utilizes its sole method to turn overhead lights on and off.

6.4.16 Time Service Bundle – Gateway.OSGi.TimeService Synchronization is important to the Gateway’s operation, so a time service was developed. This service is able to provide reference time strings and java time objects to different bundles. In previously discussed bundles, there is often a class called Time.java. This is taken from the Time Service Bundle and used for the simplicity of including it in each bundle and customizing. Most of these classes provide a reference time of the format yyyy.mm.dd.hh.mm.ss.msmsms, such as for Net Service. The Event Bundle uses Java Calender objects to create an event.

6.4.17 XBee Bundle - Gateway.OSGi.XBee The bundle Gateway.OSGi.XBee provides classes for monitoring devices (the sensor box) with the embedded XBee RF modules. The bundle uses an online open source XBee JAVA API to communicate with XBee modules. The packages and subsequent JAVA classes which comprise the XBee bundle are shown in Table 11. The XBee bundle implements the XBeeService service and creates an IXBeeService interface object, which is then exported to the OSGi framework via the MANIFEST.MF file. The XBee bundle uses the IXBeeService interface provided by the utility bundle, therefore the package Gateway.OSGi.utility.xbeeservice must be imported via MANIFEST.MF as well.

Package JAVA files Descripton

.xbee Activator.java Utility.java XbeeServiceImpl.java

The activator for xbee bundle, the parameters needed for xbee devices, and the implementation of the XbeeService interface.

.applianceMonitor.sensorBox SensorBoxXBeePacket.java The class to output values of sensors from the raw Xbee binary package.

Table 11: XBee Bundle packages and files

6.4.18 GWAgent Bundle - Gateway.OSGi.GWAgent The bundle Gateway.OSGi.GWAgent provides communication between a Gateway Agent to the SEB Agent running on the Smart Energy Box. Gateway.OSGi.JADE bundle needs to be started before this bundle. The agent-based communication between Gateway Agent to the SEB Agent can have multiple scenarios. The one that is already implemented follows the sequence chart in Figure 7, where the SEB

DIADR Task 3


agent gives the Gateway agent an Indirect Signal of the percentage to shed at Gateway, and the Gateway will calculate and decide if it will apply the control. If the Gateway agrees to apply control to the plug loads, then it will return if the percentage is successfully achieved.

Gateway

Agent SEB Agent

REQUEST (Indirect Signal)

INFORM (OK)

REFUSE

CONFIRM (Success)

FAILURE (fail)

If agree to

start

control

Else

INFORM (?% to shed)

AGREE

Figure 7: JADE Communication

Gateway

Agent SEB Agent

CFP

PROPOSE

REFUSE

CONFIRM (Success)

FAILURE (fail)

If Propose

Else

ACCEPT_PROPOSAL

Figure 8: JADE Communication

Another scenario in plan is based on market-based approach, where the SEB will call for proposals from Gateway. Figure 8 shows the sequence chart. The bundle also provides a GUI for the Gateway Agent in Figure 9. The GUI shows the Desired Percentage as the requirement from SEB Agent, the total Power Consumption from all plug-in loads, the status of the Light Sensor and Occupancy Sensor, the Decision of the Gateway Agent if it will apply control, and the final Percentage Shed applied to the plug-in loads of the Gateway. The down-side window shows the communication to the SEB Agent.

DIADR Task 3


Figure 9: Gateway Agent GUI

The package description for the GWAgent bundle can be seen in Table 12.

Package JAVA files Descripton

.gwagent GatewayAgent.java GatewayAgentGUI.java GWAgentActivator.java

Gateway Agent class to communicate with SEB agent, a GUI for Gateway Agent and the activator for GWAgent bundle.

Table 12: GW Agent Bundle packages

6.4.19 Gateway JADE Bundle – Gateway.OSGi.JADE This bundle contains the JADE library and JADE OSGi add on. This bundle also contains a file called jade.properties which is read by the JADE OSGi activator and starts the JADE framework with the specified properties. The JADE library and OSGI add-ons can be found here (http://jade.tilab.com/).

7 External Bundles and External Simulations The Gateway relies on a few bundles that can be considered external bundles. The Gateway’s purpose of communicating and controlling appliances is simulated with virtual appliance simulations. These currently consist of a smart appliance simulation and a laptop simulation which can be controlled from the Gateway.

http://jade.tilab.com/

DIADR Task 3


7.1 Smart Appliance Simulation - Appliance.Simulation.WiFi

As there currently is a lack of smart appliances on the market, smart appliance simulations written in Java are used. A smart appliance refers to one that has communication capabilities, can accept commands, and monitor and control its own power usage. This appliance simulation uses the Gateway’s Net Service to communicate and uses the XML schemas to transmit data and obtain control commands. This simulation allows the user to specific what port to connect to the Gateway on, and what priority the virtual appliance will have (0 - 10). A thread is started that passively listens for commands from the Gateway and only acts once one is received. Another thread continuously runs and is where the four behaviors are coded.

Behavior Name Power Value Description

-1 Normal Operation User specific (in simulation) Simulates an appliance drawing a constant power value (default)

0 Off 0 Simulates an appliance having been turned off by the Gateway

1 Variable Power User specified (from GW) Simulates an appliance with ability to curtail its power use to a certain value

2 PWM Operation User specified (from GW) Simulates an appliance with ability to curtail its power use via PWM behavior, such as a fridge

Table 13: Appliance Simulation Behaviors

The appliance simulation also contains a GUI that allows the user to monitor the virtual appliances power consumption and to see Gateway interaction. This is also a powerful debugging tool. The GUI also contains two buttons, one that acts as a power switch for the appliance, and one that allows the user to opt out or opt in to the current or future DR Event.


.commandSchemaFiles ControlCommand.java XML schema for control command objects

ObjectFactory.java

.schemaFiles Appliance.java XML schema for appliance data objects

ObjectFactory.java

.sim runSim.java Class containing simulation algorithm and logic

wifiConnection.java Class creating socket connection and data transmission methods

ApplianceGUI.java GUI class for simulation Table 14: Appliance Simulation Bundle Packages

DIADR Task 3


Figure 10: Appliance Simulation GUI

Figure 10 displays a snapshot of the appliance simulation GUI. The simulation is currently in the default behavior mode and drawing about 500 W, with a sampling time of roughly one second.

7.2 Laptop Simulation - Laptop.Simulation.WiFi

Along with the appliance simulation, another important simulation needed is one for laptops. Graduate student Jay Taneja and researcher Nate Murthy are working on laptop charging and discharging schemas during DR events. This work will allow the Gateway to tell a laptop to utilize battery power during a DR event and to monitor its battery power so as to ensure that no laptops die during such events. As charging and discharging a laptop can take several hours, this simulation was created to mimic their work but at a much higher speed. The laptop simulation is very similar to the appliance simulation except the behaviors are slightly changed.

Behavior Name Power Value Description

-1 Normal Operation Simulation defined Simulates a laptop using a certain amount of power for computation and drawing up to a maximum amount of power for battery charging

0 Battery (Outlet Off) Simulation defined Simulates a laptop running on battery power with reduced computation power and battery discharging

1 Variable Power User specified (from GW) Simulates a laptop drawing a user specified amount of power. Power not used for computation is used for charging

2 Laptop Off 0 Simulates a laptop being turned off and not charging its battery

DIADR Task 3


Table 15: Laptop Simulation Behaviors

The laptop simulation also includes simulation of the virtual laptop battery, with its charge following a difference equation. This is used to determine the charging power and how long a laptop can last only using battery power. This also allows for more complex control simulations, as the laptop can turn itself off when its battery is low, can operate only using power for computation, send a command to the Gateway about its low battery status, or prompt the user to choose to opt out of the DR event.


.commandSchemaFiles ControlCommand.java XML schema for control command objects

ObjectFactory.java

.schemaFiles Appliance.java XML schema for appliance data objects

ObjectFactory.java

.sim LaptopSim.java Class containing simulation algorithm and logic

wifiConnection.java Class creating socket connection and data transmission methods

LaptopSimGUI.java GUI for simulation Table 16: Laptop Simulation Packages

Figure 11 displays the laptop simulation GUI. It is used for similar purposes as the appliance simulation GUI. The snapshot shows the laptop simulation drawing about 45 W for computation, and its maximum charging power of 35 W. It is in its default behavior and not under Gateway Control.

Figure 11: Laptop Simulation GUI

DIADR Task 3


7.3 Event.Test.Simulation

This bundle solely contains an activator that utilizes the constructor in EventService.java of the Event Bundle. This is used to create a simulated DR event within the OSGi framework for testing. Event parameters such as start time, duration, and desired curtailment coefficient are passed into Event Service.

7.4 Jade.Test.SEB

This is the implementation of a SEB Agent, running on the Smart Energy Box, and is used to communicate with the Gateway Agent. In addition to the negotiation process described in the Gateway.OSGi.GWagent bundle section, the SEB Agent is also responsible for the communication to the DataService Component of the Smart Energy Box to get DR signals. Based on the DR signal, the SEB Agent will make a decision on what percentage of power needs to be shed by the Gateway Agent. The SEB Agent related communications are described in Figure 12.

Gateway

Agent SEB Agent

REQUEST (Indirect Signal)

INFORM (OK)

REFUSE

CONFIRM (Success)

FAILURE (fail)

If agree to

start

control

Else

INFORM (?% to shed)

AGREE

SEB Data

Service

JADE ACL

MessageDR XML

Message

Poll for DR Event

New Event Coming

Figure 12: SEB, GW

It is also providing a GUI for the SEB Agent in Figure 13. The left-side window shows the events getting from the SEB runtime, and the right-side window shows communications with Gateway Agent. The “energy percentage to shed” is showing the number of percentage of power consumption that SEB Agent decides from the DR event for the Gateway Agent to shed.

DIADR Task 3


Figure 13: SEB Agent GUI

8 Web User Interface As the Gateway’s inner workings and processes are of no concern to the user as well as data difficult to glean out, a web user interface (WebUI) has been created. This consists of a website that will be hosted on the Gateway machine to allow the user to interact with the Gateway. The WebUI will have two versions, a complex one for system administrators, and a simplified version for regular users. [5]

Figure 14: Home page of WebUI

DIADR Task 3


Figure 14 depicts the home page of the WebUI. From here the user can select three pages: Configuration, Operation and DR Event Status. The Configuration page allows a user to set up their appliances in the Gateway, give these appliances a priority and choose to opt the appliances into or out of DR Events. The user can also select communication parameters for the appliances. The DR Event page allows a user to view current and future DR events, and to choose whether or not to participate.

Figure 15: WebUI Operation Page

The Operation page is where the user can monitor power use by his/her appliances or aggregate power use by appliances in the Gateway’s domain. Here the user can choose a sMAP feed to connect to, to view historical power use, and also get a look at individual appliance power data along with their preferences. This will allow a user to see what impact their choices make on individual and overall power and energy consumption.

9 Hardware Legacy or dumb appliances, so called because they have no communication or self-control capabilities, rely on load switches and power meters for control and power monitoring. Currently there are many products that fulfill this role, and the DIADR project utilizes two of those.

DIADR Task 3


9.1 Raritan Power Distribution Unit (PDU)

The Raritan DPX-8 PDU is a switchable power supply. It has eight outlets that can have their power turned on and off using internal relays. It also contains a suite of sensors, both for each outlet and for the entire unit that measure several variables. Table 17 displays the measurements that the PDU is capable of performing and reporting.

Locale Value Units Remarks

Outlet (1-8) Power State On/Off

Current A

Maximum Current A Resettable

Power Factor W/W

Apparent Power W

Actual (True) Power W

Unit Unit Voltage V Same as outlet voltage

Unit Frequency Hz

Unit Current A

Unit Max Current A Resettable

Unit RMS Power W

Unit Apparent Power W Table 17: Raritan DPX-8 Measurements

The DPX-8 has several communication and control media. The user is able to connect using a serial interface (RS-232) to access the command line prompt (CLP), the internal command line interface. Once the DPX-8 has a static IP address, it can be accessed using secure shell (SSH) which allows the user to use the CLP for queries and control. The DPX-8 web interface can be accessed by entering the IP into a browser and using the correct username and password. From here a host of setup parameters are available to the user. [6] The Gateway uses a Java SSH library to connect to the two DPX-8s using SSH. The Raritan Bundle provides the services to query for outlet and unit data, and turn specific outlets on and off. This is all done by executing CLP commands.

Figure 16: Raritan DPX-8 1U

Figure 17: ACme meter

DIADR Task 3


9.2 ACme WiFi Sensor and Switch

The ACme is a wireless plug-load energy meter capable of sampling real and reactive power at up 2.8 kHz. It communicates via IPv6 using 6LoWPAN header compression over an IEEE 802.15.4-compliant radio. ACme enables high-fidelity continuous measurement of electricity consumption at scale, providing the potential to view and correlate electricity activity across loads. Currently there are Acmes that contain relays capable of controlling power. [7]

9.3 Uninterruptible Power Supply (UPS)

One of main function of the Gateway is to reduce total power load during a DR event, including plug loads. A significant portion of the total plug load in commercial spaces is from desktop computers, their monitors, peripherals, networking equipment and laptop computers. However, cutting power to these devices ends their operation with possible unintended and unwanted results as only laptops are equipped with batteries. Therefore, a need for battery power storage that can switch from plug to battery power instantaneously is needed. The solution to this need is an uninterruptible power supply (UPS). The test office, 464 Sutardja Dai Hall at UC Berkeley, has four UPS units, each with an external battery to supplement their own battery. The UPS units are American Power Conversion Smart UPS XL-Modular 1500. They are able to supply 1500 VA (W) at 120 V. The UPS are plugged into outlets on the DPX-8s so that the Gateway can control their use of plug power or battery power. [8]

9.4 Sensor Box

The Sensor box is built in SCR, mainly containing four sensors and an XBee Pro RF module for wireless communication. The four sensors are a temperature sensor, a humidity sensor, a photo transistor for light sensing, and a motion sensor which detects occupancy status. The manufacturers and part numbers of the sensors are described in Table 18.

Sensor Manufacturer Part No.

Temperature sensor ANALOG DEVICES AD22100KTZ

Humidity sensor HONEYWELL S&C HIH-4010-001

Photo transistor Panasonic - SSG PNZ108

PIR Motion sensor Adafruit 189 Table 18: Sensor Box Components

XBee 802.15.4 OEM RF modules are used to provide wireless end-point connectivity from Gateway to the sensor box. These modules use the IEEE 802.15.4 networking protocol for fast point-to-multipoint or peer-to-peer networking. They are designed for high-throughput applications requiring low latency and

DIADR Task 3


predictable communication timing. The Gateway is connected to an XBee module with a USB to serial cable, and another XBee module is embedded in the Sensor box. Therefore, the Gateway can communicate with the Sensor box. [9]

10 Gateway Functionality The Gateway is a communication and control system, and control relies on communication. When initialized, the Gateway creates connection to appliances and polls for data or receives data continuously. The Gateway’s main functions are listed below:

- Create connections to appliances; smart appliances connect directly to the Gateway, dumb appliances use hardware such as the Raritan PDU.

- Obtain power use data from appliances - Aggregate and abstract power use data and send to data store such as sMAP or the WebUI - Obtain setup and preference information from the WebUI - Obtain DR Event Information from the Siemens Smart Energy Box - Provide priority based appliance and lighting control during DR event to achieve a load reduction

goal - Release control upon end of DR event so as not to cause a power spike.

Figure 18 depicts the functionality of the Gateway with respect to smart and dumb appliances. On the left are smart appliance simulations, which can be programmed to simulate any number of appliances or devices. The Gateway creates a socket server connection on its host machine, allowing the appliance to connect to it. The Gateway passively receives data from the appliance simulation, parsing the data and sending it to sMAP and the Web UI. During a DR event, the Gateway utilizes a suite of information to make control decisions, passing Control Command objects to appliances. The Gateway also monitors its efficacy in achieving the power reduction goal. On the right are dumb appliances, plugged into a Raritan PDU. The Gateway creates a SSH connection to the PDU, and uses Raritan’s CLP to query for data. This data is abstracted to Appliance data objects for use in the Control Bundle, and also passed on to sMAP and the Web UI. During a DR event, the Gateway uses outlet appliance and priority information to decide which outlet(s) to turn off.

DIADR Task 3


Figure 18: Gateway Interaction with Appliances

The Gateway utilizes its JADE Agent Service to obtain DR event information. DR events are created inside the framework, and kept track of using timing functions. When a DR event starts, the Event Service object associated with the specific DR event notifies the Control Service which then transitions into an active state. The Control Service then starts its algorithm to achieve its load reduction goal. This logic is described below and is detailed in Figure 19.

1. Control Service transitions to active state 2. Base power load (all appliances connected) calculated, power reduction goal formed 3. Gateway controls appliances with priority 0 4. After waiting for transient loads to die out (roughly 10 seconds), Gateway calculates total power 5. Current total power is compared to power reduction goal

a. If lower, Control Service transitions to passive state b. If higher, priority increased and process repeats from step 3

6. Control Service transitions to passive state at end of DR event 7. Gateway releases control and sends commands to return appliances to their previous or default

operation state

DIADR Task 3


Figure 19: Gateway Control Bundle logic during DR event

11. Gateway Testing As the Gateway is currently being developed, it is also constantly being tested to ensure its proper functionality and to debug and optimize its code. This testing occurs in room 464 of Sutardja Dai Hall (CITRIS) at the University of California, Berkeley. The room contains three desktops, named lemon, lime and grapefruit, and all on the same network default gateway, to avoid firewall issues. The room also has three APC Uninterruptible Power Supplies that provide backup power to the desktops. Several ACME meters have been placed around the room, monitoring loads and reporting to sMAP. Two Raritan PDUs also are stationed in the room providing control for dumb or legacy appliances. Several dumb appliances typically found in a commercial office setting are also used in the room for testing. These include a laser jet printer, mini fridge, 12” fan, and small desk lamp. Testing the Gateway consists of the following steps.

1. Set up appliances that the test will use. Smart appliance simulations are started and dumb appliances are plugged into the proper outlets on PDUs

2. Start the OSGi framework, and start the bundles in the correct order 3. Allow the smart appliance simulations to connect to the Gateway, if being used 4. Start the Event Activator bundle with proper parameters to register a DR event in the OSGi

framework 5. Monitor the results

DIADR Task 3


11.1 Sample Test

Below is a sample output of the OSGi console during a simple test. The test consists solely of controlling dumb appliances connected to a Raritan PDU. A fan is plugged into outlet 1, a lamp into outlet 2, a laptop that is charging into outlet 3, a UPS into outlet 7 and another laptop into outlet 8. The priority for each outlet is set as their number minus 1. OSGi> Starting to listen for CONTROL service events. Gateway Control Bundle: Service of type gateway.OSGi.utility.IEventService.IEventService registered. EventServiceFactory registered successfully Gateway Control Bundle: Service of type gateway.OSGi.utility.IRaritanService.IRaritanService registered. RaritanServiceFactory registered successfully Create object of IRaritanService for Gateway.OSGi.Raritan.Appliance Number of bundles using service 1 Gateway Control Bundle: Service of type gateway.OSGi.utility.IRaritanService.IRaritanControl registered. CONTROL: Raritan1 RaritanServiveControl registered successfully Create object of IRaritanService for Gateway.OSGi.Raritan.Appliance Number of bundles using service 1 Gateway Control Bundle: Service of type gateway.OSGi.utility.IRaritanService.IRaritanControl registered. CONTROL: Raritan1 RaritanServiveControl registered successfully

The OSGi framework is started with the bundles started in the following order: Control, Event, Raritan, Raritan.Appliance. This sequence allows the control service to start listening for control service events. The Event Bundle is started, and its service is registered with the framework. The Raritan bundle is started and its service is registered with the framework. The Raritan.Appliance bundle is started and consumes the Raritan service, creating a control service object. start 19 Create object of INetService for Event2.Test.Simulation Number of bundles using service 1 Gateway Control Bundle: Service of type gateway.OSGi.utility.IEventService.IEventControl registered. CONTROL: getting an EventService New instance of GC Logic created for event: User Event CONTROL: User Event eventControl registered successfully for: User Event

The Event.Activator bundle is started, creating and registering an event in the framework. This registers a Control Service object in the framework. This particular event had a one minute start delay and two minute duration. OSGi> CONTROL: Control Thread active Connected to Raritan Device at 128.32.156.187 ++++++++++++++++++++++++++++++++++++++++++ User Event: transitioning into active state 2011.04.26.09.38.31.654 Total Power Base Load [W]: 278 Desired Total Load [W]: 195

DIADR Task 3


Controlling appliances with priority: 0 set /system1/outlet1 powerState=off Current Load : 265 ----------------------------------------- Controlling appliances with priority: 1 set /system1/outlet2 powerState=off Current Load : 203 ----------------------------------------- Controlling appliances with priority: 2 set /system1/outlet3 powerState=off Current Load : 157 ----------------------------------------- Power Reduction Goal Met: Current Load [W] = 157 <= Desired Load [W] = 195 ++++++++++++++++++++++++++++++++++++++++++ When the event starts, the control bundle transitions to an active state. Here it can be seen as doing so at the date and time in format yyyy.mm.dd.hh.mm.ss.msmsms. The control bundle first uses the services registered to it to calculate the total base load, which is 278 W for this test. It then sends control commands to appliances with priority 0, in this case the fan which is plugged into outlet 1. The fan is turned off, and the control bundle waits approximately 10 seconds before calculating the current total load. This is to allow appliances such as fans and battery chargers to ramp down completely. The control bundle then sends a control command to appliances with priority 1, in this case the lamp plugged into outlet 2. As the goal is not met, appliances with priority 3 are turned off, in this case the laptop plugged into outlet 3. The power reduction is met so the control bundle transitions to a passive state. User Event: transitioning out of active state 2011.04.26.09.40.16.696 set /system1/outlet1 powerState=on set /system1/outlet2 powerState=on set /system1/outlet3 powerState=on set /system1/outlet4 powerState=on set /system1/outlet5 powerState=on set /system1/outlet6 powerState=on set /system1/outlet7 powerState=on set /system1/outlet8 powerState=on stop 19 Release object of IEventService for Event2.Test.Simulation Number of bundles using service 0 Gateway Control Bundle: Service of type gateway.OSGi.utility.IEventService.IEventControl unregistered. CONTROL: ungetting EventService CONTROL: ungetting event service for User Event Stop command in GC Logic issued for event: User Event The event ends, and the control service releases control of all appliances, turning on all outlets of the Raritan PDU. The Event.Activator bundle is stopped and the OSGi framework, and therefore the Gateway is stopped.

DIADR Task 3


DIADR Task 3


12. Conclusion and Future Work This report describes the Energy Information Gateway (Gateway), a communication and control system being developed between UC Berkeley and Siemens. This development is to fulfill Task 3 of the DIADR project. The Gateway, being in development, is constantly evolving and being modified; however, the primary functionality and operation are constant. The Gateway will remain in development for the duration of this project, as there is always room to streamline code, add new services, add capability to communicate with new hardware, and include more options and user preferences. In the immediate future, the Gateway will be modified to include the Wattstopper Service and merge SMAP Service into the Raritan Service. Many changes for the Gateway architecture are being planned at the moment. These include reconfiguring the Control Bundle and its services along with how appliance data and their corresponding connection information is stored and utilized within the framework.

DIADR Task 3


References 1. Residential Energy Gateway – Phase II Report, Dan Arnold, UC Berkeley, 10-6-2010 2. The Energy Information Gateway as a Sustainability Solution, Dan Arnold and Michael Sankur, 4-11-

2010 3. http://www.osgi.org/About/Technology 4. http://www.osgi.org/About/Technology

http://jade.tilab.com/papers/WhitePaperJADEEXP.pdf http://jade.tilab.com/papers/JADETutorialIEEE/JADETutorial_FIPA.pdf http://jade.tilab.com/ http://www.fipa.org/ http://jade.tilab.com/doc/tutorials/JadeOsgiGuide.pdf

5. Gateway Web UI – Nate Murthy and Kevin Ding 6. http://www.raritan.com/support/dominion-px/v1.4.1/user-guides/english/DPX-0N-v1.4.1-E.pdf 7. http://buzzing.cs.berkeley.edu/~xjiang/papers/jiang09acme.pdf 8. http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=SUM1500RMXL2U 9. http://code.google.com/p/xbee-api/

http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/point-multipoint-rfmodules/xbee-series1-module.jsp#overview

http://www.osgi.org/About/Technology

http://jade.tilab.com/papers/WhitePaperJADEEXP.pdf

http://jade.tilab.com/papers/JADETutorialIEEE/JADETutorial_FIPA.pdf

http://jade.tilab.com/

http://www.fipa.org/

http://jade.tilab.com/doc/tutorials/JadeOsgiGuide.pdf

http://www.raritan.com/support/dominion-px/v1.4.1/user-guides/english/DPX-0N-v1.4.1-E.pdf

http://buzzing.cs.berkeley.edu/~xjiang/papers/jiang09acme.pdf

http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=SUM1500RMXL2U

http://code.google.com/p/xbee-api/

Documents

Distributed Intelligent Automated Demand Response – …i4energy.org/downloads/projects/sutardja-dai/DIADR_Ta… · · 2014-05-28A DISTRIBUTED INTELLIGENT AUTOMATED DEMAND RESPONSE