Design and Implementation of a Microgrid Energy Management System

Abstract

A microgrid is characterized by the integration of distributed energy resources and controllable loads in a power distribution network. Such integration introduces new, unique challenges to microgrid management that have never been exposed to traditional power systems. To accommodate these challenges, it is necessary to redesign a conventional Energy Management System (EMS) so that it can cope with intrinsic characteristics of microgrids. While many projects have shown excellent research outcomes, they have either tackled portions of the characteristics or validated their EMSs only via simulations. This paper proposes a Microgrid Platform (MP), an advanced EMS for efficient microgrid operations. We design the MP by taking into consideration (i) all the functional requirements of a microgrid EMS (i.e., optimization, forecast, human–machine interface, and data analysis) and (ii) engineering challenges (i.e., interoperability, extensibility, and flexibility). Moreover, a prototype system is developed and deployed in two smart grid testbeds: UCLA Smart Grid Energy Research Center and Korea Institute of Energy Research. We then conduct experiments to verify the feasibility of the MP design in real-world settings. Our testbeds and experiments demonstrate that the MP is able to communicate with various energy devices and to perform an energy management task efficiently.

1. Introduction

A microgrid is a low-voltage distribution network that is composed of a variety of energy components such as controllable energy loads and Distributed Energy Resources (DERs). Controllable loads include HVAC (heating, ventilation, and air conditioning) systems and EVs (Electric Vehicles), and DERs include PV (Photovoltaic), WT (Wind Turbine), CHP (Combined Heat and Power), fuel cells, and ESS (energy storage systems) [1]. By integrating DERs and controllable loads within the distribution network, the microgrid is capable of operating either in a grid-connected mode (i.e., it is connected to the power grid) or in an islanded mode (i.e., it is disconnected from the grid and uses various DERs to supply power to the loads). While such integration differentiates the microgrid from conventional power systems, it also introduces new challenges to the way of power management and control. An Energy Management System (EMS) has been responsible for the management and control operations in the traditional power systems, and it is now necessary to advance the EMS so as to cope with emerging challenges.

A number of research ideas in the literature have discussed the advancement. Su and Wang examined the role of EMS in microgrid operations in detail [2]. They also listed four essential functionalities which a new EMS (say, a microgrid EMS) should support; they are forecast, optimization, data analysis, and human–machine interface. Authors in [3,4,5,6] proposed various types of EMS frameworks that can work in a microgrid environment. While previous research focuses on a list of design issues for the EMS, they hardly take into account engineering challenges that frequently occur in the implementation of a microgrid EMS. The first type of engineering challenge relates to operational properties of energy components in the microgrid. The operation of typical DERs like photovoltaics is characterized by intermittency and variability, and that of controllable loads by spatiotemporal uncertainty. These properties complicate the microgrid management, and the microgrid EMS must be able to handle them in an appropriate manner. Next, a microgrid operation involves running a list of energy applications including demand response and coordinated EV charging as well as running innovative control algorithms [7,8] that are not necessarily implemented in a single system. Therefore, the microgrid EMS must be able to interface with them seamlessly. Finally, various types of energy components from different vendors are deployed and interconnected in the microgrid, but most of them still use proprietary protocols, which hinders them from interoperating with each other [3]. The microgrid EMS must resolve the heterogeneity and interoperation challenges.

We believe that a microgrid EMS must be designed and implemented both to overcome engineering challenges and to satisfy aforementioned functional requirements. Unfortunately, few previous works have accomplished them simultaneously To address these two orthogonal concerns together, this paper proposes a Microgrid Platform (MP), an advanced EMS for efficient microgrid operations. We also develop and deploy its prototype and run experiments in real-world settings within two smart grid testbeds built in the UCLA Smart Grid Energy Research Center (SMERC) and Korea Institute of Energy Research (KIER). The contributions of this paper are three-fold:

(1)

We design a microgrid EMS with consideration of both the functional requirements and the engineering challenges. Many existing energy management systems have focused on one aspect. On the one hand, a system highlighting the functional requirements usually assumes the existence of computer systems, software, and communications and regards them as a black box. This setting, however, often uses proprietary technologies and thus is not extensible. Moreover, the system often provides predefined energy applications. It is hard to upgrade the system in order to support emerging applications. A microgrid EMS must be flexible from the software point of view to accommodate brand-new applications easily. There is an analogy in the cellular phone area. In the feature phone era, users used pre-installed applications that were very crude. Now, we observe that a user can develop any smartphone applications and sell them at APP stores. On the other hand, a system focusing on computer systems and communications usually implements specialized scheduling and control algorithms. Such algorithms are often customized to the underlying communication technologies and network topologies. In order to adopt new algorithms, the system may be rebuilt and these configurations are re-customized. To address these challenges, we design the MP with a modular system in mind. The MP is developed as a framework in which a variety of modules (e.g., scheduling algorithm module and communication module) are added and/or deleted seamlessly. For instance, a specific power generation model can be added and incorporated in an existing optimization module. In this way, the MP supports the functional requirements and addresses the engineering challenges.

(2)

We develop the MP prototype in a resource-oriented architecture (ROA) style [9]. Most previous microgrid systems have been implemented in a multi-agent system architecture or a service-oriented architecture (SOA) style that functions well in a homegeneous, proprietary, and server-centered system environment. However, an emerging microgrid environment includes deployment of heterogeneous energy devices using different communication technologies and use of a variety of standard message formats. A new microgrid system, therefore, must be able to cope with heterogeneity and diversity so as to communicate with energy devices seamlessly in an interoperable manner. A plug-and-play trend would be an example—say, a new smart meter from a random third-party vendor using new technologies is added to a microgrid. This device must be able to communicate with the microgrid system or with other energy devices (if necessary) with minimum configuration so as to be ready to be used. With traditional architecture styles, we must re-build a microgrid management system to customize so as to communicate with the brand-new device. The MP prototype addresses this system engineering issue by adopting the ROA that abstracts an energy device as a resource—a software conterpart of the hardware itself. Just as the concept of Class in a Java programming language, a resource in the ROA maintains states and takes actions. Unlike the Java, however, the resource makes real communications and interactions with other energy devices or the microgrid system. Because of this abstraction concept, our MP can work in a distributed environment. To implement the sofware part and the abstraction, we take an Energy Service Interface (ESI) technology [10].

(3)

We deploy the MP prototype in our testbeds and run experiments to evaluate performance of microgrid management and controls. A microgrid is a complicated and delicate system, and thus development, deployment, and evaluation of its management system must be carefully designed and performed. When deploying the prototype and connected energy devices, thus building a microgrid system testbed, we must consider how much data we can obatin from the testbed. The more we get data, the more accurately we are able to run and evaluate optimization algorithms. We also take into account the diversity of energy devices. Unlike a simulation study, there are many challenges in a testbed environment. For instance, it is not trivial to install EV charging stations on a testbed because of both technical problems and administrative issues. Even if installed, we may not obtain ample information mainly due to low penetration of EVs in the real world. The MP as an energy management system in a microgrid must be able to communicate with external systems such as a demand response server. For evaluation, we must consider what external signals are delivered into the microgrid because these signals directly affect performance of scheduling and control algorithms. This paper designs the deployment of the prototype and connected energy devices by taking into account all the major factors. As a result, we build two real-world testbeds of microgrid including the MP prototype.

A primary issue in the evaluation is about how to design and run scheduling algorithms. Unlike simulations, each microgrid testbed has intrinsic properties, and thus a specifically-designed algorithm may not operate well in every microgrid configuration. To address this challenge, we develop a generic system model of a microgrid and formulate the energy scheduling and demand response as optimization problems. The next question is about how well a generic model works in a real-world environment. Does the model require to customize itself to every testbed? Does the model work well in a specific configuration and bad in other ones? How different would experimental results be from simulation ones? While this paper may not answer all the questions this time, we try to design and run experiments step-by-step in order to disclose clues to the answers. In particular, we discuss what we learned from our evaluation about the difference between experimental results and those from simulations in Section 4.2.

The rest of the paper is organized as follows. Section 2 reviews the functionalities of a microgrid EMS and addresses its design issues. Section 3 shows our implementation of the MP in details. In Section 4, we deploy our MP prototype to two microgrid testbeds and conduct experiments. Section 5 concludes this paper.

2. Design of a Microgrid Energy Management System

In this section, we discuss two categories of design issues—functional requirements and engineering challenges—which are necessary for an EMS to work properly on an emerging microgrid environment. Figure 1 illustrates an overview of a microgrid EMS system for our discussion; internal boxes denote its roles. We refer to [2] for details.

2.1. Functional Requirements

2.1.1. Forecasting Energy Activities

As generation, storage, and consumption of energy in a microgrid become more dynamic and complex, it is critical to predict such activities accurately for the purpose of energy balance. Forecasting is preformed on different time scales (e.g., hour-ahead, day-ahead, etc.) and predicted data is fed into an optimization process for microgrid operations. Forecasting has been challenging in a microgrid setting because of operational properties—inherent intermittency and variability in DERs and spatiotemporal uncertainty in controllable loads (e.g., electric vehicles). Previous studies focused on developing various forecast models of high accuracy given this randomness. They use various types of data sources, from historical data to mathematical models, weather data, and other societal data [11,12]. Zhu et al. run demand forecast and solar generation forecast from history data, and then develop a battery (dis)charging scheduling algorithm [13]. Huang et al. propose a hybrid mathematical model that takes weather forecasts and history data to improve the prediction accuracy of a solar panel [11].

2.1.2. Optimization: Making a Control Decision for Optimal Operations

An EMS must be able to make control decisions to optimize the power flows by adjusting the power imported/exported from/to the grid, the controllable loads, and the dispatchable DERs. Different optimization decisions are made for different applications (e.g., demand response and energy/power management) that are typically formulated as non-linear optimization problems with different objectives. Extensive algorithms have been proposed for them [7,8]. Given EV owners’ charging profiles and real-time power price, Mal et al. developed a V2G scheduling algorithm working at a large scale EV charging structure [14].

2.1.3. Analysis on Energy Data

An EMS collects a huge amount of data from DERs, energy loads, and energy market. Data collected must be analyzed properly, providing insights to better understand the characteristics of energy activities. This can be further used to improve the performance of the forecast and the optimization models. Bellala et al. analyze time series data of energy usage in a commercial campus [15]. Then, they detect anomalous usage periods representing unusual power consumption. Detecting and correcting the anomaly can save on the electricity bill. The Monitoring-Based Commissioning (MBCx) project exploits the measurement data and diagnostic tools in order to perform commissioning. on 24 non-residential buildings throughout the state of California [16].

2.1.4. Human–Machine Interface

An EMS must provide a Human–Machine Interface (HMI) for real-time monitoring and controls of a microgrid. The HMI allows a microgrid operator to interact with other modules inside a microgrid system. It must be able to provide useful information and knowledge rather than raw data by means of visualization and archiving [17]. The HMI is expected to allow active customer interactions [2].

2.2. Engineering Challenges in Communications

A microgrid is a distributed system consisting of heterogeneous types of energy resources [3], in which an EMS is responsible for interacting with the resources in an interoperable manner. The EMS may adopt standard specifications for seamless interoperation, such as IEC 61850 (http://www.iec.ch/smartgrid/standards/), IEEE1574 (http://grouper.ieee.org/groups/scc21/1547/1547_index.html), OPC Unified Architecture (https://www.opcfoundation.org/UA), open Building Information eXchange (oBIX) (http://www.obix.org), Facility Smart Grid Information Model (FSGIM) (http://spc201.ashraepcs.org/standards.html). In academia, research has developed programmable APIs that allow us to access energy resources in a unified manner [18,19]. Dawson-Haggerty et al. leverage SensorML [20] and define a data model that fits to tiny sensor devices embedded into energy resources [21].

A microgrid EMS is also responsible for communicating with external systems outside the microgrid; it translates data and signals transmitted from external systems to internal protocols and semantics. Energy services instantiate such interoperation. Two pieces of literature presented use cases of energy services [22,23], and we classify the services into two categories: facility service and grid service. In the facility service, a customer facility such as a commercial building and a community microgrid provides service data to external systems sitting on a national grid, whereas it receives and consumes service data delivered from the grid in the grid service. The EMS must be able to support both services.

The communication interface in the microgrid EMS must be extensible. New energy applications and innovative algorithms will be continuously added to the microgrid, and they do not necessarily reside in a single system. It is essential that the EMS is able to connect to them seamlessly, and such new connection must not affect the operations of existing functionalities.

3. Microgrid Platform

To demonstrate the feasibility of the new design discussed in the previous section, we propose a Microgrid Platform, a new microgrid EMS, and develop its prototype implementation running on top of a Linux distribution. This section also describes two algorithms that the MP runs for efficient microgrid operations. Figure 2 illustrates the system architecture of the Microgrid Platform implementation.

3.1. System Architecture

We implement the MP in a Resource-Oriented Architecture (ROA) style [9], which abstracts energy components in a microgrid in the form of resources. Each resource implements well-defined interfaces that allows the MP to support plug-and-play of DERs, loads, and functionalities. As shown in previous works [3,4,5,6], the ROA has advantages over a Service-Oriented Architecture. It fits best for “linking and referring” to energy resources, thus maximizing the interactivity efficiency in the EMS. The ROA is more lightweight without complicated interface description.

3.1.1. Interoperation—Energy Services from the Facility

The MP provides energy services to the grid, which makes the microgrid play an energy service provider role in the smart grid. In addition to basic energy services, it realizes the facility-side forecasting that helps the grid understand the facility’s energy behaviors accurately.

Energy Services

The MP provides fundamental data services that most EMSs can do. These include (1) historical energy data for individual resource as well as for the aggregated one; (2) real-time measurement on resources’ status, their energy activities (consumption, generation, and storage), and power quality; (3) the MP also accepts command messages from the grid that eventually control the internal energy resources. This corresponds to a Direct Load Control (DLC) service on the grid side. In addition, the MP provides various types of future forecasting services including demand and generation forecasts.

Energy Service Interface

The MP develops the ESIs using the existing implementation model [10]. That is, the service data is represented via the open Building Information Exchange (oBIX) specification [24] and is then exchanged via the Web Service model with Representational State Transfer (RESTful) style [9]. Our security algorithm carries out access control on action levels (i.e., Read, Write, and Invoke) [25]. In addition to the oBIX, we extend the IEC 61850 specification [26] to represent data from our solar panels and energy battery.

3.1.2. Interoperation—Energy Services from the Grid

In addition to basic DLC services, our testbed implements two Facility-centric Load Control (FLC) type of services in which the microgrid is interested most—Automated Demand Response (ADR) service and Real-Time Pricing (RTP) service.

Open Automated Demand Response

We deploy an OpenADR 1.0 server [27] that provides the ADR service by exploiting the open source [28]. The server issues an EventState signal (All the XML schemas for data used in OpenADR are available at http://openadr.lbl.gov/src/1.) to initiate a new demand response event. It is able to communicate with both smart and simple clients. A smart client can interpret the EventInfo information within the EventState signal. Included in SmartClientDREventData entity, the EventInfo contains event details. For example, the eventInfoTypeID denotes an event type and takes one value out of $\mathrm{PRICE}$_$\mathrm{ABSOLUTE}$, $\mathrm{PRICE}$_$\mathrm{RELATIVE}$, $\mathrm{LOAD}$_$\mathrm{AMOUNT}$, etc. To communicate with a simple OpenADR client, the server translates the EventInfo information into a simpler form, named SimpleClientEventData. The entity contains two variables to describe the event state. The EventStatus element denotes the temporal state of the event ($\mathrm{FAR}$, $\mathrm{NEAR}$, or $\mathrm{ACTIVE}$). The OperationModeValue indicates the operational state of the energy loads in the event ($\mathrm{NORMAL}$, $\mathrm{MODERATE}$, or $\mathrm{HIGH}$). MP implements a Message Authentication Code (MAC) addressing the message integrity to address the security issue in the OpenADR. Following the NISTIR (National Institute of Standards and Technology, Internal/Interagency Reports) 7628 guideline [29], our testbed takes a hash-based MAC (HMAC) with SHA-256.

Real-Time Pricing for Retail Energy Market

To assess the feasibility of the RTP service, our testbed implements an RTP server that provides price forecast for a retail energy market. The server, in the absence of an RTP model in the real world, exploits the wholesale market price provided by California Independent System Operator (CAISO) (http://oasis.caiso.com/mrioasis/). More specifically, it obtains three types of price forecasts from CAISO—Day-Ahead Market (DAM); Hour-Ahead Scheduling Process (HASP); and Real-Time Market (RTM). The DAM provides an estimated power price of every hour for 24 h ahead. The HASP and RTM provide an hour-ahead/10-min-ahead price estimation of every 12/5 min, respectively. Since CAISO does not provide the price forecast for the location of our campus, the server takes the price value for the city of Long Beach. The RTP server also takes inputs of demand forecast and weather forecast from CAISO, and then eventually determines three types of price forecasts (DAM, HASP, and RTM) for the retail energy market.

Consuming the Service Data

The MP implements communication counterparts of the above two energy services for interoperations. With respect to the ADR service, it implements both smart and simple clients that periodically “pull” the EventState message from the server. This PULL mode is often preferred over a PUSH mode since the OpenADR client has more control over the communications, e.g., firewalls. It, then, identifies when the event starts and ends and other event contexts. The MP also pulls the price forecast from the RTP server periodically. Different applications may use three types of forecasts differently. Our testbed primarily fetches the HASP and RTM forecasts every hour and 10 min and executes scheduling algorithms according to the price changes.

3.1.3. Communication Model

The MP communicates with the energy resources via Ethernet, RS-485 serial, and IEEE 802.15.4. It supports various application protocols such as Modbus, IEC 61850, IEC DLMS, BACnet, SEP 1.0 (Modbus - http://www.modbus.org/; BACnet - http://www.bacnet.org; SEP - http://www.zigbee.org/Standards/ZigBeeSmartEnergy; DLMS - http://www.dlms.com/), and several proprietary protocols. The MP collects and stores both power-related measurements and status information from the energy resources every 5 min on average. In addition, it maintains meaningful meta data regarding each resource. For instance, each mini submeter is managed with a load type, location, and the load’s priority. A resource owner configures the meta data, and thus the data keeps reflecting physical characteristics of the plugged load and user contexts. The MP provides basic scheduling functions through which a user pre-schedules the operations of energy resources. The dimmable LED lights are now reserved to be ON only during office hours, while a user can still turn them on/off any time.

3.1.4. User Interface

The MP implements a web-based user interface (UI), as shown in Figure 3, for real-time monitoring and control of the microgrid. The UI also allows users to interact with the MP and eventually with energy components in a microgrid. The MP allows real-time data to flow and provides control services with which users can read real-time measurements and send control messages to the DERs and the loads. The UI includes a variety of data visualization tools such as interactive graphs and tables that illustrate energy data and derived knowledge (e.g., historical or forecast data of DERs and loads) at a glance.

3.2. Microgrid Control

We implement two algorithms in the MP that support optimal operations in a microgrid: An energy scheduling algorithm and a Demand Response (DR) algorithm. The MP also implements forecast services for optimization. In particular, it adopts three different models for forecasting: A persistence model, an auto regressive moving average (ARMA) model, and a machine learning model for load forecasting, PV forecasting [11], and EV forecasting [12], respectively. The MP uses the CAISO’s forecast data to provide market forecast services. Note that the algorithms here are designed based on the configuration of the two testbeds. Other algorithms [30,31] can also be implemented in the MP for different applications.

3.2.1. System Model

We present the system model of a microgrid and formulate the energy scheduling and demand response as optimization problems.

Let us consider a microgrid consisting of a set of Distributed Generation (DG) units denoted by $\mathcal{G}:=\{g_1,g_2,\dots ,g_G\}$, Distributed Storage (DS) units denoted by $\mathcal{B}:=\{b_1,b_2,\dots ,b_B\}$ and controllable loads denoted by $\mathcal{L}:=\{l_1,l_2,\dots ,l_L\}$. We use a discrete time model with a finite horizon in this paper. We consider a time period or namely a scheduling horizon which is divided into T equal intervals $\Delta t$, denoted by $\mathcal{T}:=\{0,1,\dots ,T-1\}$, where $t_0$ is the start time.

DG Model: For each DG unit $g\in \mathcal{G}$, we assume that there is an upper bound and a lower bound on its power:

$$p_g^{\min }\left(t\right)\le p_g\left(t\right)\le p_g^{\max }\left(t\right),\forall t\in \mathcal{T},$$

(1)

where $p_g^{\min }\left(t\right)$ and $p_g^{\max }\left(t\right)$ are the minimum and maximum output power, respectively. Typical DG includes PV, WT, diesel, and CHP. We note that we do not consider specific generation models for different types of DG. They can be easily incorporated into the optimization framework. If the DG unit is dispatchable (e.g., diesel), the output power $p_g\left(t\right)$ is a variable. If the DG unit is non-dispatchable (e.g., PVs and WTs), the output power $p_g\left(t\right)$ cannot vary and its value is equal to the forecasted value (i.e., $p_g^{\min }\left(t\right)=p_g^{\max }\left(t\right)=p_g^f\left(t\right)$ where $p_g^f\left(t\right)$ is the forecasted power at time t).

We denote the generation cost of a DG unit $g\in \mathcal{G}$ by $C_g\left(p_g\left(t\right)\right)$. We assume that the cost function is strictly convex. For renewable DG units such as PVs and WTs, the generation cost is zero.

DS Model: We consider batteries as the DS units in the microgrid. Given a battery $b\in \mathcal{B}$, we assume its output power $p_b\left(t\right)$ is positive when charging and negative when discharging. Let $E_b\left(t\right)$ denote the energy stored in the battery at time t. The battery can be modeled by the following constraints:

$$\begin{array}{c}{p}_b^{\min }\le p_b\left(t\right)\le p_b^{\max },\forall t\in \mathcal{T},\end{array}$$

(2)

$$\begin{array}{c}{E}_b(t+1)={\eta }_b{E}_b\left(t\right)+p_b\left(t\right)\Delta t,\forall t\in \mathcal{T},\end{array}$$

(3)

$$\begin{array}{c}{E}_b^{\min }\le E_b\left(t\right)\le E_b^{\max },\forall t\in \mathcal{T},\end{array}$$

(4)

$$\begin{array}{c}{E}_b\left(T\right)\ge E_b^e,\end{array}$$

(5)

where $p_b^{\max }$ is the maximum charging rate, ${\eta }_b\in (0,1]$ captures the battery efficiency, $-p_b^{\min }$ is the maximum discharging rate, $E_b^{\min }$ and $E_b^{\max }$ are the minimum and maximum allowed energy stored in the battery, respectively, and $E_b^e$ is the minimum energy that the battery should maintain at the end of the scheduling horizon.

We use a cost function to capture the damages to the battery by the charging and discharging operations. Three types of damages are considered: fast charging, frequent switches between charging and discharging, and deep discharging. We model the cost of operating a given battery b as [32]:

$$\begin{array}{cc}\hfill C_b\left({\mathbf{p}}_b\right)\triangleq & {\alpha }_b{\displaystyle \sum _{t\in \mathcal{T}}}{p}_b{\left(t\right)}^2-{\beta }_b{\displaystyle \sum _{t=0}^{T-2}}{p}_b(t+1)p_b\left(t\right)\hfill \\ & +{\gamma }_b{\displaystyle \sum _{t\in \mathcal{T}}}{\left(\min (E_b\left(t\right)-{\delta }_b{E}_b^{\max },0)\right)}^2+c_b,\hfill \end{array}$$

(6)

where ${\mathbf{p}}_b$ is the charging/discharging vector ${\mathbf{p}}_b\triangleq (p_b\left(t\right),t\in \mathcal{T})$, ${\alpha }_b$, ${\beta }_b$, ${\gamma }_b$, ${\delta }_b$, and $c_b$ are positive constants.

The above function is convex when ${\alpha }_b>{\beta }_b$. This cost function captures the damages to the battery by the charging and discharging operations. The three terms in the function penalize the fast charging, the charging/discharging cycles, and the deep discharging, respectively. We choose ${\delta }_b=0.2$.

Load Model: For each load, the demand is constrained by a minimum and a maximum power denoted by $p_l^{\min }\left(t\right)$ and $p_l^{\max }\left(t\right)$, respectively:

$$p_l^{\min }\left(t\right)\le p_l\left(t\right)\le p_l^{\max }\left(t\right),\forall t\in \mathcal{T}.$$

(7)

For deferrable loads such as EVs, the cumulative energy consumption of the loads must exceed a certain threshold in order to finish their tasks before deadlines. Let $E_l^{\min }$ and $E_l^{\max }$ denote the minimum and maximum total energy that the load is required to consume, respectively. The constraint on the total energy consumed by a deferrable load is given by:

$$\begin{array}{c}\hfill E_l^{\min }\le {\displaystyle \sum _{t\in \mathcal{T}}}{p}_l\left(t\right)\Delta t\le E_l^{\max }.\end{array}$$

(8)

We use a cost function to capture customer loss of comfort in the scheduling. The cost function $C_l\left({\mathbf{p}}_l\right)$ quantifies a customer’s loss or discomfort obtained by the load $l\in \mathcal{L}$ using the demand vector ${\mathbf{p}}_l\triangleq (p_l\left(t\right),t\in \mathcal{T})$. We assume the cost function is a convex function.

Supply–Demand Matching: The net demand of the microgrid is equal to the total demand minus the total generation:

$$P\left(t\right)=\sum _{l\in \mathcal{L}}{p}_l\left(t\right)+\sum _{b\in \mathcal{B}}{p}_b\left(t\right)-\sum _{g\in \mathcal{G}}{p}_g\left(t\right),\forall t\in \mathcal{T}.$$

(9)

If the microgrid is operated in islanded mode, then $P\left(t\right)=0$. If the microgrid is operated in grid-connected mode, then $P\left(t\right)$ is the power traded between the microgrid and the main grid. We note that islanded mode also involves other control and operational issues [33]. We model the cost of energy purchase from the main grid as $C_0(t,P\left(t\right))\triangleq \rho \left(t\right)P\left(t\right)\Delta t$, where $\rho \left(t\right)$ is the market energy price. Note that $P\left(t\right)$ can have a negative meaning that the microgrid can sell its surplus power to the main grid (We assume that the selling price is the same as the purchasing price. Depending on the market pricing scheme, the two prices may be different in reality).

3.2.2. Energy Scheduling

The objective of the energy scheduling is to schedule the day-ahead operation of the DERs and the loads in a way that (i) the total costs of generation, energy storage, load, and energy purchase are minimized; and (ii) the DER constraints, the load constraints, and the supply–demand matching constraint are satisfied. The scheduling horizon $\mathcal{T}$ in this problem is one day.

We define ${\mathbf{p}}_g\triangleq (p_g\left(t\right),t\in \mathcal{T})$, ${\mathbf{p}}_b\triangleq (p_b\left(t\right),t\in \mathcal{T})$, ${\mathbf{p}}_l\triangleq (p_l\left(t\right),t\in \mathcal{T})$, and $C_g\left({\mathbf{p}}_g\right)\triangleq {\sum }_{t\in \mathcal{T}}{C}_g\left(p_g\left(t\right)\right)$. The energy scheduling in the microgrid can be formulated as a convex optimization problem [34]:

$$\begin{array}{ccc}\hfill \underset{{\mathbf{p}}_g,{\mathbf{p}}_b,{\mathbf{p}}_l}{\min }& & {\xi }_g{\displaystyle \sum _{g\in \mathcal{G}}}{C}_g\left({\mathbf{p}}_g\right)+{\xi }_b{\displaystyle \sum _{b\in \mathcal{B}}}{C}_b\left({\mathbf{p}}_b\right)+{\xi }_l{\displaystyle \sum _{l\in \mathcal{L}}}{C}_l\left({\mathbf{p}}_l\right)\hfill \\ & & +{\xi }_0{\displaystyle \sum _{t\in \mathcal{T}}}{C}_0(t,P\left(t\right))\hfill \\ \hfill \mathrm{s}.\mathrm{t}.& & \left(1\right)-\left(9\right),\hfill \end{array}$$

where ${\xi }_l$, ${\xi }_g$, ${\xi }_b$, and ${\xi }_0$ are the parameters to trade off among the utility maximization and the cost minimizations.

Solving the problem gives the optimal schedules including the generation schedules ${\mathbf{p}}_g$, the battery schedules ${\mathbf{p}}_b$, and the load schedules ${\mathbf{p}}_l$.

3.2.3. Demand Response

Upon receiving DR event signals from the utility, the microgrid EMS responds by coordinating the operation of energy devices in the microgrid properly.

A DR event is characterized by a time schedule $\mathcal{T}$ that specifies the start time and the end time and a demand limit $P_{\max }\left(t\right)$ that is determined from the event information. The DR constraint on the net demand of the microgrid is given by:

$$P\left(t\right)\le P_{\max }\left(t\right),\forall t\in \mathcal{T}.$$

(10)

Similar to the day-ahead scheduling problem, the DR problem can be formulated as a convex optimization problem:

$$\begin{array}{ccc}\hfill \underset{{\mathbf{p}}_g,{\mathbf{p}}_b,{\mathbf{p}}_l}{\min }& & {\xi }_g{\displaystyle \sum _{g\in \mathcal{G}}}{C}_g\left({\mathbf{p}}_g\right)+{\xi }_b{\displaystyle \sum _{b\in \mathcal{B}}}{C}_b\left({\mathbf{p}}_b\right)+{\xi }_l{\displaystyle \sum _{l\in \mathcal{L}}}{U}_l\left({\mathbf{p}}_l\right)\hfill \\ \hfill \mathrm{s}.\mathrm{t}.& & \left(1\right)-\left(10\right).\hfill \end{array}$$

In the above problems, the control variables are assumed to be all continuous. However, some of them may be discrete in reality (e.g., on/off). A two-stage approach [35] can be used to solve this issue. In the first stage, a solution is obtained assuming that all the control variables are continuous. Then, the discrete variables are rounded to the nearest discrete levels and treated as constants in the second-stage solution.

4. Testbeds and Experiments

This section describes two microgrid testbeds in which we deploy various types of energy resources. For experiments, we also develop several external energy services. On top of the testbeds, we run experiments of microgrid operations. We note that this paper omits basic experimental results, i.e., measurement of energy usage and direct resource control. Instead, our experiments focus on the optimal energy scheduling and DR operations in the KIER and UCLA SMERC testbed, respectively. We refer to [10] for our previous results.

4.1. Microgrid Testbeds

4.1.1. UCLA Site

The energy resources in the UCLA SMERC testbed include smart submeters, office/home appliances, smart equipments, electric vehicle charging stations, and photovoltaics. Figure 4 presents some of them.

Smart Submeter

Unlike a conventional smart meter that measures aggregated energy usage, a smart submeter provides fine-grained measurement and control. Our testbed deploys two types of submeters. We instrument a panel-level multi-submeter that simultaneously connects up to 36 single phase circuits within a panel (http://www.satec-global.com/eng/products.aspx?product=42). Using it, we monitor two groups of energy loads—the lightings and power outlets at an office. We also install mini submeters that are instrumented to single power lines (http://www.bspower.co.kr/en/smartmeter.do). For instance, it can directly connect to a light switch that turns on/off a set of fluorescent lights. These submeters use current transformers to convert current to voltage, and an embedded microcontroller calculates the real, reactive, and apparent powers and energy usage. They are with relays, and the microcontroller switches the power upon requests.

Office Appliance with Plug-Load Meter

As the plug-loads including all the office appliances account for more than one third of the total power consumption in a building [36], it is necessary to manage them carefully. To this end, we deploy two types of plug-load meters: smart plugs and smart power strips. Office appliances are plugged into them: computers, monitors, desk lamps, and network switches. The plug-load meter is functionally the same as the submeter, i.e., energy measurement and control. It communicates with the MP using a ZigBee [37] module.

Smart Equipment

Smart equipment represents such energy resources that must be accessed directly. Recent programmable thermostats and LED lights fall into this category. Each piece of equipment has its own operation cycles beyond a simple on/off control and is able to adjust the operations upon external requests. Our testbed deploys dimmable LED panel lights that adjust their brightness and color temperature in eight steps. Each light uses a ZigBee module to transmit its status and to accept control commands to/from the MP. For scalable experiments, we additionally develop a light emulator that creates 200 LEDs, each of which operates exactly the same as the real device (brightness, temperature, and energy consumption).

Smart Home Appliance

The home appliances are functionally the same as the smart equipment. Each manages its own operation cycles and must be accessed directly. The MP connects to two types of appliances via the Ethernet: a clothes dryer and a refrigerator (http://smartgrid.ucla.edu/projects_adr.html). It is able to change the strength of the heat (high, low, or no heat) as well as turn on/off the operation by sending signals to the dryer. The refrigerator adjusts the operating cycles of compressor, defrost, and fan. To measure energy usage, the mini submeters are instrumented to their input power cables.

EV Charging Station

UCLA has instrumented a number of charging stations at campus parking structures [38]. Each station powers several EVs via J1772 connectors (http://smartgrid.ucla.edu/projects_evgrid.html) simultaneously and supports multiple charging levels (http://standards.sae.org/j1772_201210). It is capable of measuring charging capacity as well as charging rate. Each station sends the charging data in real-time to a management server in our laboratory that controls the stations based on subscribers’ profiles and preference. The MP communicates with the stations via the server. Because of low penetration of EVs, however, we could not collect enough data for experiments. As a complementary work, we simulate charging activities based on measurements and obtain an ample amount of data.

Solar Panel and Battery

The MP is connected to a photovoltaic panel and a Battery Management System (BMS) that performs the whole monitoring function of battery system (voltage/electic current/SoC/SoH/temperature). A 50 kW PV system is being installed on the roof and a 25 kWh BMS in the lab.

Table 1. Parameters of battery management system in the testbed.

Parameters	Description	Set Value
B	Capacity of BMS	25 kWh
$B_i$	Initial state of charge in BMS	25 kWh
γ	Charging/discharging rate	80%
$b^{-}$	Maximum state of charge in BMS	22.5 kWh
b_	Minimum state of charge in BMS	2.5 kWh

describes the parameters in BMS. The current version of testbed implements the PV and the BMS simulations where data is generated from the real devices. The PV and BMS also implements the IEC 61850 standard to communicate with the MP. The details of the simulators can be found in our previous research [39].

4.1.2. KIER Site

KIER is a research organization that focuses on improving energy efficiency and supporting energy policy in terms of technological development. It has built an entire building-level testbed having a peak demand of 300 kW that is mainly consumed by computers, air conditioners, lighting, and EVs. Figure 5 shows the system model of the testbed including two subsystems—a power hardware-in-the-loop simulation (PHILS) and real hardware—that our experiments use. The PHILS provides a real-time digital simulation of a hybrid power system with power hardware that can produce kW—level electrical power. It allows a flexible modeling of DERs, such as PVs, EVs, and ESS, and a real DC–AC inverter, and is expected to effectively fill the gap between the analytical simulation and practical implementation. The PHILS is built with Regatron’s Integrated bidirectional power supply TopCon TC.GSS and family TC.G (http://www.regatron.com/en/products-topcon/bidirectional-power-supply-gss), and Figure 6 pictures the PHILS testbed system. The other subsystem in the testbed is a real hardware system that includes three types of DERs connected: PVs, EVs, and ESS. The real hardware DER system is partially under development.

Our experiments use the real-time power hardware-in-the-loop PV/ESS simulation systems for DERs and real-hardware slow/quick EV charging systems for controllable loads. The PHILS system is also used to verify the operation of the microgrid. Figure 7 illustrates the architecture of our testbed, and

Table 2. Specification details of energy devices used in the testbed.

Device	Capacity	Power Max/Min	Energy Max/Min
PV simulator	64 kW	-	-
ESS simulator	64 kW	10 kW/−10 kW	50 kWh/5 kWh
Quick EV simulator	64 kW	64 kW/0 kW	[18 kWh, 23 kWh]/[13 kWh, 18 kWh]
Slow EV1 system	2.5 kW	2.5 kW/0 kW	[18 kWh, 23 kWh]/[13 kWh, 18 kWh]
Slow EV2 system	2.5 kW	2.5 kW/0 kW	[18 kWh, 23 kWh]/[13 kWh, 18 kWh]
200 LEDs	12.6 kW	12.6 kW/0 kW	-
PV: Photovoltaic	ESS: Energy storage system	EV: Electric vehicle	LED: Light-emitting diode

shows the specification details of energy devices used in the testbed.

The testbed adopts IEC 61850 as the communication and control interface. The devices are all connected to two IEC 61850 gateways and one commercial gateway supporting also the IEC 61850 standard. The MP communicates with the gateways using the manufacturing message specification (MMS) as well as REST/oBIX.

4.2. Energy Scheduling

The devices in the KIER testbed considered in the energy scheduling include a 16 kW PV, a 5 kW ESS, a 16 kW quick charging EV system, two $2.5$ kW slow charging EV systems, and two hundred 63 W dimmable LEDs. The maximum energy allowed to be stored in the battery $E_b^{\max }$ is 50 kWh, and we set $E_b^{\min }=5$ kWh. We set $E_b\left(0\right)=E_b^e=12.5$ kWh. The parameters in the battery cost function are chosen to be ${\alpha }_b=1$, ${\beta }_b=0.75$, and ${\gamma }_b=0.5$. We choose $C_l\left(p_l\left(t\right)\right):={\sum }_{t\in \mathcal{T}}{\eta }_l{(p_l\left(t\right)-p_l^f\left(t\right))}^2$ for the LEDs and $C_l\left(p_l\left(t\right)\right):={\eta }_l({\sum }_{t\in \mathcal{T}}{p}_l\left(t\right)\Delta t-{\sum }_{t\in \mathcal{T}}{p}_l^f\left(t\right)\Delta t)$ for the EVs, where $p_l^f\left(t\right)$ is the forecasted load and ${\eta }_l$ is the priority of the load given by the customer. The higher the priority is, the more important the load is to the customer. Our experiment assumes that the LEDs can be shedded and the EVs can be shifted. The maximum shedding precentage of the LEDs $\frac{E_l^{\max }-E_l^{\min }}{E_l^{\max }}$ is assumed to be $30\%$. The energy upper bound of the EVs $E_l^{\max }$ is chosen randomly from $[18\mathrm{kWh},23\mathrm{kWh}]$ and the energy lower bound of the EVs $E_l^{\min }$ is chosen randomly from $[13\mathrm{kWh},18\mathrm{kWh}]$. Perfect forecasting of the DERs and loads is assumed. We use the Korean time-of-use (TOU) price in the experiment as shown in Figure 8. The parameters in the algorithm are chosen as ${\xi }_l=1$, ${\xi }_g=1$, ${\xi }_b=0.01$, and ${\xi }_0=1$.

Figure 9a shows the forecast of the devices, serving as the baseline consumption. We then run the algorithm in Matlab (v8.x, MathWorks, Natick, MA, U.S.) to produce the optimized schedules as shown in Figure 9b. Comparing Figure 9b with Figure 9a, we observe the battery charging/discharging cycles: the battery is charged when the energy price decreases and discharged when the price increases. We can also observe load shedding and load shifting from the results: the LEDs are shedded, the EVs are shifted to the time when the price is low, and the total charging energy of the EVs is also reduced. The total operational cost of the testbed using the optimized schedule is $12,424$ KRW, compared with 7899 KRW without scheduling, saving the cost by $\frac{12,424-7899}{12,424}=36.43\%$.

Next, we use the schedule produced by the algorithm to control the hardware-in-the-loop simulators in the testbed in order to validate the simulation in real-hardware settings. The experimental results are presented in Figure 10. Compared with the simulation results in Figure 9b, the result of using the real-time hardware simulators roughly follows the optimized schedule obtained from the simulation. The main cause of the differences between them lies in the resolution of the inputs for the hardware simulators. The hardware simulators are not able to accept inputs of any precision. The effect of communication delay can be also observed in the LED control: the total power of the LEDs changes linearly in time. This is because we have 200 LEDs, and it takes time to control all of them and wait for them to respond to the control signals. Both the input resolution and the communication delay need to be considered for optimal energy scheduling in a real microgrid system.

4.3. Demand Response Algorithm

In the experimental scenario, the MP changes the demand in response to the change of real-time energy prices. In order to highlight the DR effect, the dimmable LEDs only participate in the DR—that is, they respond to the price changes. The DR optimization is then simplified as a problem to be solved at each time t:

$$\begin{array}{ccc}\hfill \underset{p_l\left(t\right)}{\min }& & {\displaystyle \sum _{l\in \mathcal{L}}}{\eta }_l{(p_l\left(t\right)-p_l^f\left(t\right))}^2\hfill \\ \hfill \mathrm{s}.\mathrm{t}.& & p_l^{\min }\left(t\right)\le p_l\left(t\right)\le p_l^{\max }\left(t\right),\forall l\in \mathcal{L}\hfill \\ & & {\displaystyle \sum _{l\in \mathcal{L}}}{p}_l\left(t\right)\le P_{\max }\left(t\right),\hfill \end{array}$$

where $\mathcal{L}$ includes only the LEDs and $p_l^f\left(t\right)$ corresponds to the brightness preferred by the customer. In our DR experiment, $P_{\max }\left(t\right)$ is defined as a linear piecewise function that translates the real-time price $\rho \left(t\right)$ from the CAISO to the maximum allowed total power:

$$P_{\max }\left(t\right)=\left\{\begin{array}{cc}\sum _{l\in \mathcal{L}}{p}_l^f\left(t\right),\hfill & \rho \left(t\right)<6¢/\mathrm{kWh},\hfill \\ 0.8\sum _{l\in \mathcal{L}}{p}_l^f\left(t\right),\hfill & 6¢/\mathrm{kWh}\le \rho \left(t\right)\le 10¢/\mathrm{kWh},\hfill \\ 0.7\sum _{l\in \mathcal{L}}{p}_l^f\left(t\right),\hfill & 10¢/\mathrm{kWh}<\rho \left(t\right)\le 14¢/\mathrm{kWh},\hfill \\ 0.6\sum _{l\in \mathcal{L}}{p}_l^f\left(t\right),\hfill & \mathrm{otherwise}.\hfill \end{array}\right.$$

(11)

The LEDs are assumed to be equally deployed in four offices with different priorities (${\eta }_l=5,10,15,20$). The brightness is dimmed in the range $[0,100]$. The minimum, maximum, and preferred brightness are set to 20, 100, and 80, respectively. We implement the DR algorithm as a web service using JOptimizer (http://www.joptimizer.com/). Upon receiving DR signals from a DRAS (Demand Response Automation Server), the MP sends control commands to the LEDs.

Figure 11 shows the changes of the real-time price, the total power consumption, and the power consumption grouped by priority. The figure also observes that the total power consumption reduces as the price changes. A demand reduction rule uses priority—that is, the devices having lower priorities reduce more power consumption than those with higher priorities.

5. Conclusions

This paper proposes a Microgrid Platform, an EMS for a microgrid, by taking into account both the functional requirements and the engineering challenges. The MP is flexible and extensible in the sense that it supports plug-and-play of DER devices, loads, and functionalities by adopting the resource-oriented architecture style. The MP fulfills interoperability via energy service interfaces. We develop and deploy a prototype system both in the UCLA and KIER testbeds and run experiments to show the feasibility of the microgrid management and control in real-world settings. Our experimental results demonstrate that the MP is able to (i) manage various devices in the testbed; (ii) interact with external systems; and (iii) perform efficient energy management. Integral parts of our future works include conducting more experiments for statistical analysis and implementing/evaluating various control algorithms. We note that this work has extended our previous research [40].