Microgrid Energy Management System - CAE Usershomepages.cae.wisc.edu/~manur/MS_Research_AshrayManur.pdf · Microgrid Energy Management System by ... 1.1 Introduction ... 4 Microgrid

Microgrid Energy Management System

by

Ashray Gururaja Manur

A project report submitted in fulfillment of the

requirements for the degree of

Master of Science

(Electrical Engineering)

at the

UNIVERSITY OF WISCONSIN-MADISON

December 2015

http://homepages.cae.wisc.edu/~manur/

http://www.wisc.edu

© Copyright by Ashray Gururaja Manur 2015All Rights Reserved

APPROVED BY :

Advisor: Prof. Giri Venkataramanan

Advisor Title

Date

2

Professor

26 Jan 2016

Abstract

The concept of microgrid is emerging to be a viable approach to integrate var-ious types of electricity sources and storage devices within or close to load loca-tions. While the fundamental technical features of microgrids have been demon-strated in laboratory and field settings, a large number of operational issues re-main to be solved before they can become widespread. Chief among them is anapproach for asset or energy management within the microgrid. In contrast to thewell-established centralized electricity grid enterprise, microgrids are expected tobe small in scale and maintain a peer-to-peer interaction among devices with roughparity between supply and demand in terms of size. In this scenario, it is critical tohave a robust operational protocol within the microgrid to prioritize and manageloads, sources and storage to prevent the collapse of the microgrid. This studypresents the design framework for a Microgrid Energy Manager (MEM) whichuses the internet of things (IoT) paradigm and wireless sensor networks (WSN)to overlay a communication and control layer for real-time energy management inmicrogrids.

i

AcknowledgementsMy deepest gratitude is to my advisor, Prof. Giri Venkataramanan. His passion

towards the subject and thrust to take engineering research beyond the walls of thelaboratory is phenomenal. I’m thankful for his time, support and mentorship whichhas shaped my abilities as an engineer and a researcher.

My sincere thanks to Prof. Suman Banerjee (Computer Sciences), Prof. Sarada(School of Business), Prof. Alfonso Morales (Urban and Regional Planning) and Prof.Nancy Wong (School of Human Ecology). I am grateful to them for lending me theirexpertise, guidance and collaborating with me on some exciting projects.

I would like to thank Raul Martins, Zeng Fan and Jared Pierce for helping me inthe development and de-bugging of the hardware platform. I would like to extendmy gratitude to the Wisconsin Electric Machines and Power Electronics Consortium(WEMPEC) faculty, students and the administrative staff for making it a world classresearch group.

All of this would not have been possible without the constant support and encour-agement of my family and friends. I’m grateful to my father, Gururaja Manur for hisspot-on pragmatic advice on academics, life and beyond, my mother, Rekha Manur forencouraging the dreamer in me and my sister, Anusha Manur for the sheer brilliancethat she is.

ii

Contents

Abstract i

Acknowledgements ii

1 Introduction 11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Microgrids: Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Overview of Microgrid Energy Manager . . . . . . . . . . . . . . . . . . . 21.4 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Microgrid Energy Management: State of the Art 62.1 Microgrid Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Wireless Communication Framework for Microgrids . . . . . . . . . . . . 92.3 Cloud Computing for Microgrids . . . . . . . . . . . . . . . . . . . . . . . 112.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Microgrid Network (MN) 133.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Microgrid Sensor Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Microgrid Cloud 244.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 Microgrid Cloud (MC) Physical Infrastructure . . . . . . . . . . . . . . . 254.4 MC Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Experiments and Results 315.1 Microgrid Network Architecture . . . . . . . . . . . . . . . . . . . . . . . 315.2 MEM Hardware Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3 Wireless Sensor Network (WSN) for Microgrids . . . . . . . . . . . . . . 355.4 MSN Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.5 Cyberphysical System (CPS) for Microgrids . . . . . . . . . . . . . . . . . 475.6 CPS Tests Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Conclusion and Future Work 52

A MEM Gateway and Node Schematics 53

iii

List of Figures

1.1 Typical microgrid architecture . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Microgrid Energy Manager Architecture . . . . . . . . . . . . . . . . . . . 4

2.1 Centralized Energy Management System . . . . . . . . . . . . . . . . . . 8

3.1 Network Topologies in IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . 143.2 Mesh Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Tree Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 IEEE 802.15.4 communication stack . . . . . . . . . . . . . . . . . . . . . 153.5 IEEE PHY Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 163.6 IEEE MAC frame structure . . . . . . . . . . . . . . . . . . . . . . . . . . 163.7 LWM Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.13 MSN algorithm overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.14 MSN ACK handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.15 MSN response handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 MC system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 MicroE command set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Sample request and response commands . . . . . . . . . . . . . . . . . . 274.4 Setting up MEM users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5 Setting up MEM grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.6 MEM heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.7 MicroE command set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1 MicroE request-response mechanism . . . . . . . . . . . . . . . . . . . . . 325.2 MEM hardware architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3 MEM Communication Board . . . . . . . . . . . . . . . . . . . . . . . . . 345.4 MEM Power Interface Board . . . . . . . . . . . . . . . . . . . . . . . . . . 345.5 Physical Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.6 Linear Topology Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.7 RSSI and LQI variation for linear topology in the laboratory . . . . . . . 385.8 PRR and RRR for linear topology in the laboratory . . . . . . . . . . . . . 385.9 Microgrid Reliability Test for linear topology in the laboratory . . . . . . 395.10 Distributed Topology in the laboratory . . . . . . . . . . . . . . . . . . . . 395.11 RSSI and LQI for distributed topology in lab . . . . . . . . . . . . . . . . 405.12 PRR and RRR for distributed topology in the laboratory . . . . . . . . . . 405.13 Distributed topology in home . . . . . . . . . . . . . . . . . . . . . . . . . 415.14 RSSI and LQI for distributed topology in home . . . . . . . . . . . . . . 415.15 PRR and RRR for distributed topology in home . . . . . . . . . . . . . . . 425.16 Microgrid reliability test for home environment . . . . . . . . . . . . . . 425.17 RSSI and LQI for linear topology in field . . . . . . . . . . . . . . . . . . 435.18 PRR and RRR for linear topology in field . . . . . . . . . . . . . . . . . . 435.19 MRF for linear topology in an open field . . . . . . . . . . . . . . . . . . . 445.20 PRR and RRR for distributed topology in an open field . . . . . . . . . . 44

iv

5.21 RSSI and LQI for distributed topology in field . . . . . . . . . . . . . . . 455.22 PRR and RRR for distributed topology in field . . . . . . . . . . . . . . . 455.23 RTT variation over the course of the experiment . . . . . . . . . . . . . . 485.24 RTT variation per day basis . . . . . . . . . . . . . . . . . . . . . . . . . . 495.25 RTT variation due to interference . . . . . . . . . . . . . . . . . . . . . . . 50

v

List of Tables

5.1 MicroE Sample Request and Response Commands . . . . . . . . . . . . . 32

vi

List of Abbreviations

SCADA Supervisory Control and Data AcquisitionPCC Point of Common CouplingWSN Wireless Sensor NetworkIoT Internet of ThingsMN Microgrid NetworkMC Microgrid CloudMG Microgrid GatewayMEM Microgrid Energy ManagerDER Distributed Energy ResourceDSM Demand Side ManagementEMS Energy Management SystemUC Unit CommitmentPLC Power Line CommunicationDNO Distribution Network OperatorMGCC Microgrid Central ControllerLC Local ControllerCAN Controller Area NetworkWLAN Wireless Local Area NetworkLAN Local Area NetworkAP Access PointCSMA/CA Carrier Sense Multiple Access with Collision AvoidanceQoS Quality of ServiceDoS Denial of ServicePRR Packet Reception RatioLQI Link Quality IndicatorRSSI Received Signal Strength IndicatorMAC Medium Access ControlTCP Transmission Control ProtocolIP Internet ProtocolIaaS Infrastructure as a ServicePaaS Platform as a ServiceIaaS Software as a ServiceSOAP Simple Object Access ProtocolLWM Light Weight MeshFFD Fully Functional DeviceRFD Reduced Function DevicePAN Personal Area NetworkPLME Physical Layer Mangement EntityPPDU PHY Protocol Data UnitsMPDU MAC Protocol Data UnitsAODV Ad-hoc On Demand Distance VectorHTTP Hyper Text Transfer Protocol

vii

SOA Service Oriented ArchitectureRRR Respone Reception RatioMRF Microgrid Reliability FactorCPS Cyber Physical SystemsISP Internet Service ProviderACK AcknowledgmentRF Radio FrequencyRTT Round Trip Time

viii

Chapter 1

Introduction

1.1 Introduction

Today’s electricity grid can be broadly sub-divided into four categories: electricity gen-eration, transmission, distribution and utilization systems. Generating stations areconnected to the distribution system through transmission lines and the distributionsystem connects all the loads in a particular region. For a number of reasons, bothtechnical and economical, individual power systems are connected together to formpower pools. These regional or area electric grids operate independently, but are alsointerconnected to form a national grid. This paradigm is based on a centralized infras-tructure. However, there is an emerging trend to move towards a more de-centralizedenergy supply and control with the emergence of microgrids [1]. Microgrids are aimedat solving some problems of centralized grid system such as

• Environmental challenges - traditional power generation systems are a majorcause of man-created carbon dioxide emissions [2]. This needs a shift towardsgreener sources of energy. Also, natural catastrophes such as earthquakes, hurri-canes, tornado make the electricity grid highly susceptible to failure.

• Infrastructure challenges - with decreasing investments and ageing infrastruc-ture, it has become difficult for making improvements to meet the increasing loaddemand leading to congestion and unreliable power supply.

• Integration of innovative technologies - with the existing infrastructure, it willbe difficult to integrate advancements in materials, power electronics and com-munication technologies.

While the basic principles of a power system remain the same for a centralized gridand a microgrid, they differ in many aspects.

• Energy sources - microgrids tend to have a higher mix of renewable energysources when compared to a traditional grid.

• Coordination and Protection System - Due to high penetration of power elec-tronic interfaces, microgrids show a lower inertial characteristics. This meansthat the conventional control and design concepts are insufficient for microgrids.

• Critical demand-supply balance - In islanded microgrids, coordination amongdifferent entities in the microgrid is a complex problem. This is challenging dueto the critical demand-supply balance.

This illustrates that traditional communication and control infrastructure used in cen-tralized grids cannot be applied directly in microgrids. There is a need for an advancedcontrol and communication scheme which is intelligent, low-cost, low-power and time-sensitive.

1

Chapter 1. Introduction 2

1.2 Microgrids: Definition

Microgrid is defined as a small cluster of distributed generation units, loads, energystorage systems that can work when connected to the main grid or as an island in adisconnected state from the main grid [3].

FIGURE 1.1: Typical microgrid architecture

A microgrid can operate in grid connected mode and island mode with the capa-bility of handling the transitions between these two modes of operation [4]. In gridconnected mode, the power deficit can be supplied by the main grid. When the micro-grid is operated in an island mode, the microgrid controller or manager is responsiblefor the balance between the real/reactive power, loads and the storage units.

1.3 Overview of Microgrid Energy Manager

The concept of microgrid is emerging to be a technically viable approach for meetingreliable supply of electricity with increased availability in the presence of large scalegrid disturbances induced by severe weather events, as well to integrate various typesof electricity sources and storage devices. A microgrid is expected to have severalfeatures such as, scalability, stable operation in grid-tied and islanded modes of oper-ation, among others. Several researchers have developed techniques to ensure stableoperation of the microgrid with various types of configurations, controllers, generators,


loads, etc [5]. However, all these approaches that ensure stability are predicated uponthe condition that the total demand in the system is less than the total supply in thesystem, and that the system operates without reaching its capacity margins. When thetotal demand exceeds the supply capacity, the question of stability is moot, and the sys-tem collapses. Nevertheless, when the total generation capacity is roughly in par withthe nominal demand, and that loads typically operate asynchronously at-will, and thatgeneration sources may potentially be non-dispatchable, such scenarios would be com-mon enough, calling for a suitable energy management system. It is designed to havethe following functional capabilities

• Immediate wireless remote switching control of loads

• Scheduled switching control of loads and sources

• Prioritized switching of loads to maintain margin between supply and demand

• Real-time load or source status tracking

• Time of use for each load or source

• Daily, weekly and monthly load or source based reports for each user

In order to perform these functions with a high degree of flexibility in communi-cations, various technologies are integrated to develop a platform with a general ar-chitecture illustrated in figure 1.2. All the user interactions with the microgrid, sourcesand loads take place through personal input/output devices such as smart phones,personal computer or mobile phones. These interactions are mediated through theMicrgorid Cloud (MC). The microgrid cloud interacts with the microgrid through theinternet with the Microgrid Gateway (MG) using a local Access Point (AP). The MGcommunicates to all the load and sources through various microgrid nodes (MN).


FIGURE 1.2: Microgrid Energy Manager Architecture


1.4 Goal

As the electricity grid makes a transition from a centralized scheme to a distributed anda greener paradigm, several challenges arise. Energy management is one of the mostimportant challenges in a microgrid in both grid connected state (when it is connectedto the utility grid) and islanded mode of operation (disconnected from the main gridand works as a standalone system). In instances where the energy supply is roughlyin par with the nominal load, a robust control and management system is necessary.The inherent or the primary layer of control based on droop control mechanisms areinsufficient when there is a critical energy supply-demand balance. There is a needfor a secondary and tertiary control and management systems to maintain grid sta-bility. This study presents a new framework for energy management system whichhas the capabilities to provide secondary and tertiary control. Integrating advancedcommunication capabilities, an end-to-end solution is presented which includes bothhardware and software solutions. The asset management system is built on Internetof Things (IoT) paradigm and Wireless Sensor Networks (WSN). The study focuses ondeveloping hardware and software platforms for management system and studyingthe interaction between different cyber components and the physical system.

1.5 Document Organization

In Chapter 2, a detailed literature review is presented. It includes topics directly andindirectly related to control and management of microgrids. Since the core componentof a management system is the communication framework, different wireless technolo-gies have been reviewed. Chapter 3 and Chapter 4 present the Microgrid Sensor Net-work (MSN) and the Microgrid Cloud (MC) respectively. Chapter 5 describes the ex-periments and results of two studies conducted on cloud and embedded system frame-work and the performance evaluation of Microgrid Sensor Network (MSN). In Chapter6, a summary of the document is presented along with conclusions and future work.

Chapter 2

Microgrid Energy Management:State of the Art

2.1 Microgrid Control

Since a microgrid significantly differs from a traditional grid in regard to DistributedEnergy Resource (DER) integration, size and few other parameters, there is a needto re-design some of the control and protection systems. The typical reliability andsafety assumptions from a traditional power system cannot be applied here. The keychallenges and desired features [6] of a control system for a microgrid are as follows

• Time sensitive power control - microgrids usually show a low-inertia charac-teristic due to the lack of high number synchronous generators typically foundin traditional power systems. This can lead to severe frequency deviations veryquickly. The microgrid controller should be capable of making sudden changesto keep frequency and voltage deviations within desired limits.

• Entity monitoring and control - Due to the critical balance of demand and sup-ply, the control should be capable of monitoring the output voltage and currentof various sources and loads and take immediate actions to prevent deviationsfrom the set operating points. This requires advanced measurement sensors andcontrols with a robust communication setup.

• Demand Side Management (DSM) - It is essential to deploy DSM techniques foreffective load management and to boost utilization of renewable energy sources.Well planned and executed DSM schemes can increase user interaction and helpmake the microgrid more energy efficient and reliable.

• Economic Dispatch - Appropriate dispatch of the energy sources can increasethe profitability of microgrid operation. For example, priority utilization of PVduring sunny days and utilization from central grid during off-peak periods.

• Transition - the control system should be able to function in both grid connectedmode and island mode with the capability to transition seamlessly between thetwo modes of operation. The sophistication and complexity of a microgrid con-troller or control system will depend on its primary mode of operation. In gridconnected mode, importance is given to the interconnection to the main gridwhereas in an island mode reliability becomes an issue of prime importance.

It is clear that a robust control system is needed for reliable functioning of the mi-crogrid and this differs from the control system, techniques and tools applied to con-ventional power systems. Microgrid control scheme usually consists of three controllevels: primary, secondary and tertiary which is presented in the following sections.

6

Chapter 2. Microgrid Energy Management: State of the Art 7

2.1.1 Primary Control

This is the internal or inherent control in the power system which usually provides thefastest of all responses. In systems with synchronous machines, the control and shar-ing is performed by the voltage regulator, governor and the inertia of the machine. Inmicrogrids with power electronic interfaces for DC sources, control systems have tobe designed to simulate the inertia characteristics of synchronous generators which isusually done by emulating droop characteristics. The main advantage of droop con-trol is that it eliminates a need for an extra layer of control and communication. Thisworks well when is there no critical supply-demand balance and the supply is muchhigher than the demand requirements of the power system. However, there are somedisadvantages [7], [8], [9] which can be seen below.

• Fast/large changing load dynamics - droop controllers cannot adopt to large orfast change in load dynamics.

• Poor performance due to low X/R ratio - leads to poor performance due to lowX/R ratio which increases the coupling of active and reactive power.

• Inability to handle large deviations - there might be large voltage and frequencydeviations due to failures, sudden changes and this cannot be handled by thedroop controllers if the deviation is too large.

• Inaccurate power sharing - since there are no extra sensing mechanisms accuratepower sharing will be tough to achieve due to uncertainties in output impedances.

All the above disadvantages lead to the adaption of another layer of control in mi-crogrids which is referred to as secondary control or microgrid Energy ManagementSystem(EMS).

2.1.2 Secondary Control

This type of microgrid control is usually referred to as microgrid Energy ManagementSystem (EMS) in literature. This layer of control sits on the primary control mecha-nism and is responsible for reliable operation of the microgrid in grid-connected or inisland mode of operation. EMS is responsible for taking actions to minimize frequencyand voltage deviations and restore the microgrid to desired set-points of operation. Itusually involves a framework consisting of a communication system and an intelligentcontroller which can find an optimal Unit Commitment(UC) and dispatch the availableenergy resources. EMS architecture can be of two types:

Centralized architecture

In this framework, the centralized controller acts as the brain of the microgrid and willbe single point of information from all sources, loads, network parameters and the com-munication framework. Based on information it gathers, it has the capability to makeintelligent decisions based on the pre-determined objectives and with an ultimate goalof maintaining a reliable grid operation. A practical implementation of a similar archi-tecture can be seen in [10]. Here a centralized controller is implemented with a numberof local controls at entity level. This system uses ethernet and PLC for communication.In centralized approach, the controller can make decisions online or locally. A typicalstructure and functionality of a centralized EMS is shown in figure 2.1.


FIGURE 2.1: Centralized Energy Management System

In general, a centralized EMS scheme is more suitable for isolated microgrids wherethere is a critical balance between energy demand and supply.

De-centralized architecture

In this framework, highest autonomy is given to the different entities in the microgridlike loads and energy resources. A three level structure which includes DistributionNetwork Operator(DNO), Microgrid Central Controller (MGCC) and Local Controllers(LC) is presented in [11] .

• Distribution Network Operators - These are responsible for coordination andmanagement of multiple microgrids in a specific area. They interact with theMicrogrid Central Controller (MGCC).

• Microgrid Central Controller - MGCC is the brain of a specific microgrid. Itensures grid stability, optimizes power generation and consumption in terms ofprice, user based set-points and also handle transition between grid connectedmode and island mode of operation.

• Local Controller - LCs receive instructions from MGCC but may also have cer-tain level of intelligence. The LC controls the DER units and the controllableloads within a microgrid. One of the differences between centralized and de-centralized scheme lies in the operation of LCs. In centralized control, LCs get setpoints from the MGCC and it then takes the necessary actions. In de-centralizedapproach, LC makes decisions locally.

2.1.3 Tertiary Control

This is the highest layer of control. The function of this layer of control is to set longterm goals and optimize on the economics of energy supply and demand. It also playsan important role when coordinating the operation of multiple microgrids and han-dling power import/export between them. Since this study focuses mainly on the sec-ondary control of microgrids, this control level is not discussed further.


2.2 Wireless Communication Framework for Microgrids

Since this study is more aligned towards control and management of microgrids, sec-ondary and tertiary control of the microgrid becomes extremely important for reliableand cost-effective operation of the microgrid. Last section presented some of the chal-lenges in using droop control techniques in microgrids and particularly in islandedmode of operation. A centralized microgrid secondary control can achieve higher per-formances in island and grid-connected mode of operation. However, this is highlydependent on an efficient, reliable, low cost and low power communication frame-work. Connecting all loads and sources by wired communications like CAN, serial orethernet becomes really complex, expensive and tough to manage when the numberof loads and resources increases and the microgrid occupies a large geographical area.This section reviews different communication frameworks and topologies in literature.

A number of different communication technologies, protocols and sensor networkshave been adopted in power system. While some are aimed at microgrid management,many wireless frameworks are designed for a building or a particular setting. Thissection reviews wireless communication schemes and energy management systems forgeneric power systems, microgrids, smartgrids, buildings and homes as there is a pos-sibility that architectures in other settings can be adopted in a microgrid with somedesign modifications. A Wireless Local Area Network (WLAN) and IEEE 802.11g Wi-Fi based system for monitoring and control purposes is presented in [12]. Althoughcertain performance parameters like speed and throughput can be higher for LocalArea Network (LAN), the advantages of Wi-Fi include easy installation, wireless, lowcost and flexibility of installation. This architecture involves using a wireless node forevery entity in the microgrid. However, it does not take into account the high powerconsumption of Wi-Fi enabled devices and the possibility of the Access Point (AP) be-ing a bottle neck. A three layer microgrid control architecture with an operation center,microgrid control center and switches at entity level is presented in [13]. CSMA/CAbased communication scheme is adopted in this study. However, no specifics on thecommunication protocol or a practical implementation of mentioned architecture hasbeen implemented. The advantages of using Wi-Fi based wireless sensor network hasbeen highlighted in [14]. Comparing it to other wireless sensor protocols, Wi-Fi offerscapabilities such as extended range, higher data transmission and better non-line-of-sight transmission. However, the disadvantages include higher power consumption,cost and AP bottleneck issues.

2.2.1 Wireless Sensor Networks for Microgrids

This section deals with Wireless Sensor Networks (WSNs) for control and managementin smart grids, microgrids or residential and industrial establishments. WSNs have anumber of advantages over wired or traditional wireless technologies like low cost,low power, flexibility and ease of deployment. However, there are some challenges ofimplementing WSNs in microgrids [15]:

• Environmental factors - In power system environments, sensors may be sub-jected to RF interference, caustic or corrosive environment, dirt, dust and otherconditions that affect the performance of WSN [16].

• Reliability and latency requirements - control and management of an islandedmicrogrid is a time-sensitive operation. It becomes a difficult task to achieve


different Quality-of-Service(QoS) requirements and other network specificationssuch as latency, jitter, packet loss, congestion control etc.

• Large scale deployment and autonomy - WSNs in power systems will have largenumber of nodes spread over the deployment field. In many cases, the placementof these nodes can be random and this requires the WSN nodes to establish con-nections and maintain network connectivity autonomously.

• Security - This plays a crucial role in the design of WSN to prevent attacks and in-trusions. These include external Denial-of-Service (DoS) attacks, eavesdroppingusing packet analyzers and other active attack techniques like node capturing,routing attacks or flooding.

• Integration with Internet and other wireless/wired networks - For remote ac-cess of data or control of WSN, it becomes necessary to integrate WSN with in-ternet through a gateway. This adds complexity to the architecture as there is aprotocol translation needed for all data packets from an IEEE 802.15.4 to IEEE802.11(b/g/n) and vice-versa.

Several experimental studies have been conducted to understand WSNs [17], [18],[19]. Performance parameters have been assessed in different physical environments.Energy management tool based on IEEE 802.15.4 protocol has been proposed in [20].This study is aimed at residential energy management in smart grids through loadmanagement using an optimization scheme. The simulation study uses a ZigBee sen-sor network to control loads. However, it does not provide a hardware and practicalimplementation to support simulation results. Apart from providing an optimizingscheme, the simulation study does preliminary analysis of sensor network parametersuch as delay and jitter. It was found that sensor network performance decreased withincreasing packet size and the jitter was negligible. Wireless sensor network in powersystems for monitoring and control of segments in power transmission and deliveryhas been presented in [21],[15], [22], [23]. A wireless sensor network has been imple-mented in [15] for a substation, industrial power control room and an undergroundnetwork transformer fault. This study uses the radio chip CC2420 from Texas Instru-ments that supports IEEE 802.15.4. It operates in the 2.4 GHz spectrum with an effec-tive data rate of 250 kb/s. Apart from modeling the wireless channel model, the studyalso makes noise and interference measurements. The average noise level was foundto be -90 dBm. It was also found that the background noise changes with temperatureand interference levels. Introduction of a microwave oven varied the Packet ReceptionRatio (PRR) between 35 - 100% and introduced a 15-dBm interference in the 2.4 GHzchannel. LQI and RSSI were used to measure the radio link quality. On measuring PRRand LQI for an indoor room, it was found that there is a strong correlation between LQIand PRR and it was concluded that LQI is a good measurable indicator of the packetreception probability. Also, experimental results show that RSSI does not provide anycorrelated behavior with PRR.

Packet delivery measurement for different environments has been performed in[18]. This study uses about 60 sensor nodes in the 433 MHz range. The study assessedpacket delivery performance at two layers of the communication stack: PHY and MAClayer. It was found that, when physical layer is taken into consideration (in the ab-sence of interfering transmissions), packet delivery performance is a function of theenvironment, physical layer coding scheme and individual sensor characteristics. Thestudy uses a linear topology with a single sender in three environments: office build-ing, local habitat and a parking lot. Experiments in these environments showed that the


packet loss in the physical layer was about 10-30% and 50-80% communication energyis wasted in overcoming packet collisions.

The quality of wireless communication depends on the environment, the frequencyspectrum its using, the modulation schemes in use and the communicating devices.Some important parameters and takeaways for WSN design and testing include

• RSSI and LQI- RSSI and LQI are important hardware measurement metrics inassessing radio link quality. Experimental studies have shown strong correlationbetween LQI and Packet Reception Ratio (PRR).

• Noise and interference due to external appliances - instruments and appliancesaffect WSN performance and this can be assessed by measuring PRR. Appliancesoperating in the 2.4GHz spectrum like microwave oven and cordless phones havea direct but a variable impact on PRR.

• Background noise - choosing a frequency channel with the least backgroundnoise may aid sensor network performance. Experimental studies have shownthat the noise continuously changes over time which can be caused by changesin temperature and interference levels.

• Packet Reception Ratio (PRR) - one of the most basic evaluation criteria is thePacket Reception Ratio (PRR). Sensor networks are usually configured for multi-hop fashion. This scheme is much more reliable and energy-efficient than a singlehop. Assessing cumulative PRR will help assess application level performance.

• Transmit power - radio transmit power has a direct influence on the networkperformance. There is a direct correlation between increase in transmit powerand performance in the absence of noise and other interference levels. However,the trade-off will be increased use in battery power. However, some experimentsin literature have reported that lower transmit power improved delivery perfor-mance.

• Data Rate - most of the experimental studies have pointed towards an increasedperformance with reduced data rate.

2.3 Cloud Computing for Microgrids

Although cloud computing has not been studied deeply in the context of power sys-tems and microgrids, few studies have tried to explore the possibility of integratingcloud computing in power system technologies. A survey of integrating energy effi-ciency technologies with networking and cloud computing technologies is explored in[24]. Popularity of mobile smart phone and internet technologies such as Internet ofThings (IoT) and cloud computing along with increased awareness of smart grid andmicrogrid technologies has led to increased attempts to integrate these technologies.With the advent of smart or intelligent buildings with sensors for lighting, HVAC,security, water, temperature, metering and automation, there is a need to store andanalyze the data on a centralized platform which can be achieved by using widelyadopted communication protocols such as TCP/IP and cloud computing technologies.Energy monitoring system using smart phones was proposed in [25]. It uses cloudcomputing for data storage, modeling and analysis. A cloud platform for a smart gridplatform is described in [26]. The cloud platform in this study is used for storage, in-telligence, web and a mobile application. The intelligence is mainly used for deploying


dynamic demand response techniques which entails real time detection, notificationand response to adapt to instantaneous changes in the power system. The study usesboth private and public clouds and IaaS (Infrastructure as a Service) and PaaS (Plat-form as a Service) clouds. Cloud applications for energy management has been listedin [27]. The advantages a cloud infrastructure include elasticity, easy implementationof control and management techniques and resilience against failure of central commu-nication center (utility operator) and real time management of different entities in thegrid. A cloud based demand response architecture for smart grids has been proposedin [28]. This is in contrast to the master/slave demand response where the participantsdirectly interact with the utility. A cloud service based intelligent power monitoringand early warning system has been proposed in [29]. A smart power managementand service system on cloud computing platform has been implemented in [30]. Thisstudy uses ZigBee communication protocol for in-home communication and uses IPto communicate with the cloud through Simple Object Access Protocol (SOAP). It usesthis framework for transferring energy, temperature and other statistics to the cloud.While several studies try to integrate cloud computing and IoT with power systems, acomprehensive experimental or practical deployment of this integrated system has notbeen implemented. Algorithms to handle multiple connections, data acquisitions, in-telligence and reliability have not been assessed or implemented. This study presentsthe design framework of a cloud platform suitable for a microgrid scenario and alsoanalyses the RTT performance of this system.

2.4 Summary

This chapter presents a detailed literature review of microgrid control and manage-ment, wireless sensor networks and cloud computing for microgrids. Several studiespropose different techniques for microgrid control. The need for secondary and tertiarycontrol for microgrids to maintain grid stability has been highlighted. Several studiespropose different communication technology frameworks for several energy manage-ment systems in homes, buildings and power systems. However, they do not makea comprehensive effort to implement and evaluate these technologies in the domainof microgrids where latency and reliability is very critical. Lastly, cloud computingtechnologies for power systems has been reviewed. Exhaustive evaluation and perfor-mance analysis of the server framework for power systems and IoT systems has notbeen explored in literature. The next chapter deals with the Microgrid Network whichconsists of the power systems and the wireless sensor network for monitoring, controland management.

Chapter 3

Microgrid Network (MN)

This is an IEEE 802.15.4 based network with Atmel’s Light Weight Mesh (LWM) as thecommunication stack. This sensor network forms part of the communication frame-work which is responsible for controlling and monitoring loads and energy sources atthe microgrid level. A simple application layer was written for exchange of messagesbetween the Microgrid Node (MN) and the Microgrid Gateway (MG).

3.1 Introduction

The key challenges and desired features [6] of a microgrid control system include timesensitive control, entity monitoring and management, demand side management, eco-nomic dispatch and capability to handle transitions. This requires a reliable, low costand low power communication framework. Wired technologies become really expen-sive and complex as the number of loads and resources increase. Enabling every loadand resource in the microgrid with a wired communication channel might not be anoptimum solution. Wireless technologies aim to solve issues of cost, scalability andpower constraints [31].

3.2 IEEE 802.15.4

This section gives an overview of the IEEE 802.15.4 standard [32]. IEEE 802.15.4 belongsto the category of Wireless Personal Area Network(WPAN). IEEE 802.15.4 based sensornetworks are low data rate and low cost communication. Some of the characteristics ofa WPAN are

1. Over-the-air data rates ranging from 20 kb/s to 250 kb/s

2. Implementation of Carrier Sense Multiple Access with Collision Avoidance(CSMA)

3. Low power consumption

4. Star or peer-to-peer operation

5. Allocated 16 bit short or 64 bit extended addresses

6. Link Quality Indication

7. Energy Detection

8. Allocation of guaranteed time slots

Two devices can participate in WPAN; Fully Functional Device (FFD) and a Re-duced Function Device (RFD). The FFD can talk to FFDs and RFDs whereas RFD canonly talk to an FFD.

13

Chapter 3. Microgrid Network (MN) 14

3.2.1 Network Topologies

The standard defines two network topologies: star topology and peer-to-peer topologyas shown in figure 3.1.

FIGURE 3.1: Network Topologies in IEEE 802.15.4

In the star topology, the communication is between the devices and a single centralcontroller called PAN coordinator. Each of the nodes can communicate with each otheronly through the PAN coordinator. If the end device has to send a message from onenode to another, it has to be sent to the PAN coordinator which then relays it to the des-tination device. The disadvantage of this topology is that there is no alternative route ifthe RF link fails between the PAN coordinator and the source/destination node. Also,the PAN coordinator can be a bottle-neck. The PAN coordinator may also be respon-sible for initiating the network or terminating the network. In peer-to-peer topology,any device can communicate with the other as along as they are in the communicationrange.

Two other topologies can be implemented by application layer protocols using IEEE802.15.4: tree topology and mesh topology illustrated in figure 3.3 and 3.2 respectively.

FIGURE 3.2: MeshTopology

FIGURE 3.3: TreeTopology

The tree topology has a parent-child relationship based architecture. Each nodeexcept the main PAN coordinator has a parent. The nodes may have one or morechildren. Each node can only communicate with its parent and children. Cluster tree


topology is a slight modification of the tree topology where each parent-children groupis regarded as a cluster and is given a cluster ID.

In mesh topology, the devices can be identical and are deployed in an ad-hoc ar-rangement. Even if the nodes are not in range with each other, the message is relayedthrough the network till it reaches the final destination.

3.2.2 IEEE 802.15.4 Protocol Stack

The IEEE 802.15.4 protocol stack is slightly different from the traditional WSN stack. Itis illustrated in the figure below.

FIGURE 3.4: IEEE 802.15.4 communication stack

IEEE 802.15.4 PHY layer

The physical layer (PHY) standard is defined by IEEE 802.15.4 and is utilized by dif-ferent custom software stacks and applications. The PHY provides two services: PHYdata service and PHY management service interfacing to the Physical Layer Manage-ment Entity (PLME). The PHY data service enables the transmission and reception ofPHY protocol data units (PPDU) across the physical radio channel. It’s functionalitiescan be broadly defined as

1. Activation and de-activation of the radio transceiver.

2. Link quality indication for received packets - The LQI measurement is a charac-terization of the strength and/or quality of a received packet.

3. Clear channel assessment of CSMA/CA packets - The clear channel assessmentis performed according to one of following methods

(a) Energy above threshold - CCA will report a busy medium upon detectingany energy above the ED (Energy Detection) threshold.

(b) Carrier Sense - CCA will report a busy medium only upon detection of asignal with modulation and spreading characteristics of IEEE 802.15.4 aboveor below the ED level.

(c) Carrier sense with energy above threshold- CCA will report a busy mediumupon detection of a signal with modulation and spreading characteristics ofIEEE 802.15.4 above the ED level.


4. Energy detection with the current channel - This measurement is done by thePHY layer and this used for the channel selection algorithm. It is an estimate ofthe received signal power within the bandwidth of the IEEE 802.15.4 channel.

5. Channel frequency selection - This is done based on the value received from theenergy detection.

6. Data transmission and reception

PHY Frame Structure

The frame structure has the following components

• Preamble (32 bits) - for synchronization

• Start of Packet delimiter (8 bits) - to identify new data packet

• PHY header (8 bits) - PHY Service Data Unit (PSDU) length

• PHY Service Data Unit (127 bytes)

FIGURE 3.5: IEEE PHY Frame Structure

IEEE 802.15.4 MAC Layer

The MAC layer provides two services: MAC data service and MAC Management Ser-vice Interfacing to the MAC sub layer management entity. The MAC data service en-ables the transmission and reception of MAC protocol data units (MPDU) across thePHY data service. MAC Data service (MCPS) provides a mechanism for passing datato and from the next higher layer. The MAC Management Services (MLME) providesthe mechanism to control the settings for communication, radio and networking func-tionality from the next layer.

FIGURE 3.6: IEEE MAC frame structure


3.3 Microgrid Sensor Network

MSN implements LWM which is a low power wireless mesh network protocol fromAtmel [33]. LWM does not require a dedicated node to start a network and it definestwo types of devices: routing and non-routing. The routing nodes form the core of thenetwork and are involved in routing. Non-routing nodes are not involved in routingpurposes but can send and receive messages. These serve as end nodes in the net-work. LWM supports two types of routing protocols: native LWM routing where theroute discovery happens based on the data from the received and transmitted framesand Ad hoc On-Demand Distance Vector (AODV) routing. The stack has a small foot-print which is typically about 8KB Flash and 4KB RAM. The LWM network headerand application payload are encapsulated inside the standard IEEE 802.15.4 data framepayload and it uses the standard MAC header but does not process IEEE 802.15.4 com-mand frames. This means that it uses the standard physical frames but does not followthe MAC specifications. Instead, it implements the mesh routing protocol. Zigbee Prois a common network stack used in IEEE 802.15.4 networks. However, it has higherresource requirements and bigger footprint compared to LWM. Performance compar-ison between LWM and ZigBee was conducted in [34]. The study found that LWMperformed better than Zigbee Pro in throughput and latency.

3.3.1 Features of LWM

LWM protocol has the following features

1. No dedicated node is required to start a network

2. Has a theoretical limit of 65k nodes

3. No periodic service traffic occupying bandwidth

4. It has 2 distinct nodes: routing and non-routing

5. Route discovery can happen automatically

6. No child-parent relationship between the nodes

7. Routing table is updated automatically based on data from the received andtransmitted frames.

Network Topology

The IEEE 802.15.4 standard [32] defines two network topologies: star and peer-to-peer.MSN deploys a mesh topology through LWM. In this topology, the devices can be iden-tical and in an ad-hoc arrangement. If the nodes are not in range with each other, thedata packet is relayed through the network till it reaches the final destination. An-other advantage of the mesh network is the self-healing capabilities of the sensor net-work where it can autonomously react to network disruptions. If the packet between asource node and a destination node is relayed through an intermediate node, a disrup-tion to the intermediate node will initiate a route discovery to relay the packet throughanother available intermediate node to ultimately reach the destination.

The network topology is illustrated in the figure below. Sensor nodes in blue arerouting nodes and the non-routing nodes are indicated in green. Non-routing nodescan send and receive data but will not be used for routing purposes and hence cannotbe used as range extenders.


FIGURE 3.7: LWM Network

3.3.2 LWM Routing

The LWM protocol implements native routing in this energy management system.

LWM native routing

Native Routing This is the native LWM routing algorithm. When compared to AODV,this is simple, compact and does not use additional commands to perform route dis-covery. One of the disadvantages of this algorithm is that it cannot guarantee that thediscovered routes are optimal since it performs only local optimization. There is nospecial route discovery procedure; routes are discovered as part of normal data de-livery. The following set of figures will illustrate the routing protocol. The followingassumptions are made:

• Nodes 1, 2 and 3 are capable of routing packets

• Routing tables on all nodes are empty

• Node 1 has to send a data packet to node 3

• Node 3 is out of range for node 1 and hence it has to take a multi-hop paththrough node 2

FIGURE 3.8: Initial Network Configuration


Figure 3.8 shows the initial network configuration.Since node 1 has to send a data packet to node 3 and the route is unknown, the route

discovery takes place. Node 1 sends a packet with network destination address set to3 and the MAC address set to 0xffff (which stands for broadcast). This is illustrated infigure 3.9. The destination MAC address is set to broadcast because the routing table isempty and the packet has to be sent to all nodes to learn the route. Node 2 receives thispacket and adds this entry for node 1 to its routing table.

FIGURE 3.9: First Step in Routing

In the next step, node 2 broadcasts the frame. Node 3 receives the frame and addsthe entry for node 2 to its routing table. It also adds an entry for node 1 from thenetwork source address since it is the destination node. This is illustrated in figure 3.10.

FIGURE 3.10: Second Step in Routing

In the third step, node 3 sends an ACK. This is done to establish a reverse route.Since node 3 now knows the reverse route, it sends an unicast frame back to node 1.This is shown in figure 3.11

FIGURE 3.11: Third Step in Routing

In the final step, node 2 receives the frame from node 3. Since it has an entry fornode 1, it forwards the packet to node 1. Node 1 then adds the entry for node 3. This isillustrated in figure 3.12


FIGURE 3.12: Final Step in Routing

3.3.3 MSN Algorithm

This section deals with the algorithm deployed for the MSN network. In-depth ex-planation of network configuration, packet transmission and reception, ACKs, packetre-tries and microE has been provided.

MSN deploys an IEEE 802.15.4 based WSN which uses Atmel’s LWM as the com-munication stack. The algorithm first sets few critical network parameters: networkaddress, network identifier, frequency channel, transmit power and receiver state. These pa-rameters define the configuration of the sensor network and affect individual nodeperformance. Each node in MSN has an unique network address which helps identifyit in the network. This is set by network address. Network identifier sets the PAN ID forthe sensor network. There is a possibility of multiple PANs to exist in the same fre-quency channel. It is important that all radios designed to be in the same network havethe same PAN ID. Frequency channel and transmit power help set the frequency channeland the transmit power of the radios. The lower level part of the stack is initialized bycalling a system initialization function. This function performs the low level hardwareinitialization. Once this is completed, the system task handler function runs the internalstack tasks. This includes handling the transceiver, encryption, modulation, data trans-mission and reception at the physical level. The application task handler is responsiblefor handling tasks at an application level. An overview of the algorithm is shown infigure 3.13. The application task handler implements a state machine model.

The application task handler defines four states: initialization, idle, queue and send.The flow between the states is shown in figure 3.13. During the network setup, thetask handler goes to initialization state which sets various parameters such as networkidentifier, network address, frequency channel, transmit power etc. When data packets haveto be sent, the data is encapsulated in the right format in the queue state. In the sendstate, the message send handler sends the data packet. The transmission and receptionof the data packet is a synchronous operation. In the event of an incoming ACK, theACK handler emits a status indicator to notify if the acknowledgment was received orif message transmission failed. On success, the application task handler goes to an idlestate. If the ACK fails, the task handler executes a packet retry. This depends on thetype of retry mechanism implemented. This is illustrated in figure 3.14.

In the event of an incoming message, response handler handles the incoming messageand implements the necessary action. At this level, the request and response packetsare implemented in microE. The response handler is responsible for decoding the com-mand header from the microE data packet and executing the necessary task. MicroEcommands are shown in table 5.1. If the data packet received has a request command,the response handler will send the specific response to the source node or MG. This re-sponse may include node health, relay status indicators or grid parameters like voltage,current, frequency, power factor etc. If the data packet received is a response packet,which is usually sent from MN to MG, MG decodes the response command header andrelays the response to MC. The event handlers ACK and response handlers are executed


by the stack in the event of ACK and message reception respectively. The data packetis received and processed by the stack and the application handler is notified which thenhandles the task at the application level. In the case of message send handler, the appli-cation handler calls it in the event a data packet has to be sent. The data packet is thenprocessed and sent by the lower levels of the stack.

FIGURE 3.13: MSN algorithm overview


FIGURE 3.14: MSN ACK handler

FIGURE 3.15: MSN response handler


3.4 Summary

An introduction to IEEE 802.15.4 protocol and Atmel’s Light Weight Mesh (LWM) hasbeen presented in this chapter. IEEE 802.15.4 based WSN has several advantages overother wireless technologies such as low cost, low power, higher reliability and self-healing capabilities. Over the IEEE 802.15.4 protocol, Atmel’s LWM was implementedwhich can be compared with ZigBee. It offers advantages such as lower footprint,latency, easy network configuration and start. However, it does not implement theIEEE 802.15.4 MAC layer. The stack also has the capability to implement the nativerouting protocol or AODV routing. For this study, native routing was chosen. TheMSN algorithm is also presented for transmission and reception of ACKs and messagesthrough the RF network is also presented. The next chapter presents the MicrogridCloud (MC).

Chapter 4

Microgrid Cloud

4.1 Introduction

This chapter introduces the concept of cloud computing and the cloud architectureused for the Microgrid Cloud (MC). Cloud computing is becoming ubiquitous in to-day’s era. With increasing data generation from social media, services and businessesthere is a need for storage, analysis and access from different mobile platforms in realtime. Cloud computing solves these issues by providing a number of hardware andsoftware services. Although word "cloud" seems ubiquitous, a clear definition is neces-sary to understand its importance and relevance in microgrid energy management. Thenext few sections define cloud computing and various technologies associated with it.The Microgrid Cloud (MC) is then discussed in detail.

4.2 Cloud Computing

4.2.1 What is a Cloud?

Cloud computing refers to both the applications delivered as services over the internetand systems software in the datacenters [35]. The datacenter hardware and the soft-ware together is referred to the cloud. Cloud computing infrastructure offers a numberof features and capabilities that an ordinary remote or a private server cannot offer.

• Elasticity and Scalability - cloud computing platform gives the users an illusionof infinite computing resources on demand. This eliminates the need for usersto plan ahead for provisioning. As the load on the application decreases or in-creases, the users can request for a scale down or up of resources very easily.

• Pay for use - the flexibility to only for pay for the resources used. The resourcescan be acquired and released whenever required by the user.

• Resiliency - data centers and cloud computing service provides implement anumber of fault tolerance techniques to guarantee server up-time to users.

• Shared Resources - multiple tenants can share the same set of physical resourceswhich is virtualized to accommodate multiple users.

4.2.2 Cloud Service Models

Cloud computing services follow a Service Oriented Architecture (SOA) modelwhich can be classified as below:

24

Chapter 4. Microgrid Cloud 25

• Infrastructure as a Service (IaaS) - this is the basic cloud service model wherethe users lease physical/virtual machines, storage and networks. In this model,the users are responsible for managing the operating file system. Example of thismodel include Amazon EC2, Microsoft Azure, Google Compute Engine, Rackspaceetc.

• Platform as a Service (PaaS) - in this model, the cloud service providers delivera platform which will typically include an operating system, execution environ-ment, database solution and web servers. The users can lease this platform to runapplications in a specific language or environment. Examples include MapRe-duce, java runtimes, databases (MySQl, Oracle) and webservers (Apache, Tom-cat) etc.

• Software as a Service (SaaS) - the cloud service providers manage the infrastruc-ture and the platform and let users access to specific software which can be usedon a subscription or pay-per-use basis. Examples include Concur, Salesforce, Net-Suite etc.

4.2.3 Cloud Deployment Models

The cloud can be deployed in different ways: private, public, virtual private and hybrid

• Private Cloud - this model is usually adopted by organizations which have se-curity and privacy restrictions or the need to support specific and higher perfor-mance in the cloud. It is usually implemented behind a firewall and the infras-tructure is usually located in the organization premise. The advantages of thismodel include higher speed, flexibility, security and higher performance. How-ever, the cost of establishing such infrastructure is exorbitant.

• Public Cloud - this is the most common model which is adopted by millions ofusers for development and deployment. This is provided as a service by cloudproviders which let users remotely access hardware and software services. Ithas a shared pool of computing and network resources like servers, networks,storage and applications. The advantages include low cost and ease of use whilethe disadvantages can be lower performance, privacy and security concerns.

• Virtual Private Cloud - for uses who need a higher level of security and regula-tory compliance without the investment of a private infrastructure, this model isbeneficial. It provides a private solution using the public cloud infrastructure ofa service provider. This is achieved by dedicated VLANs, providing network iso-lation, virtual private networks and dedicated firewalls. The advantages includehigher security, performance while the disadvantage can be cost.

4.3 Microgrid Cloud (MC) Physical Infrastructure

The MC has been deployed separately in two locations: Amazon EC2 and WisconsinWireless and Networking Systems (WiNGS) Laboratory at the University of Wisconsin-Madison. One t2.micro instance on Amazon EC2 has been deployed which offers a 64bit VM with 1 CPU, 613 MB RAM with high frequency Intel Xeon Processor with turboup to 3.3GHz. The operating system deployed is an Ubuntu Server 14.04 LTS 64 bitversion. The WiNGS machine runs a 64 bit Ubuntu Server 14.04 LTS with 4 GB RAMand 20 GB storage. Both machines have public IP and run similar software stacks.


4.4 MC Framework

The overall system architecture of MC has been illustrated in figure 4.1. It can be seen

FIGURE 4.1: MC system architecture

that the internally, two Node.js servers have been deployed. Node.js HTTP is a HTTPserver to cater to the MEM Web app and the Node.js TCP is a TCP server which is thecore back-end engine for the MEM network.

4.4.1 Node.js

Node.js is a framework that provides event-driven I/O and asynchronous platform forserver-side JavaScript [36]. It is a single-threaded server-side JavaScript environmentimplemented in C and C++ and utilizes the JavaScript V8 engine. Traditional serverframeworks have an explicit client and server side implementation with a differentset of languages for both. This meant using languages and frameworks like HTML,CSS, JavaScript, AJAX on the client end and server languages such as PHP, Perl, ASP,Java, Python etc. which are used to implement server frameworks such as ApacheHTTP, LIGHTTPD, NGINX, LITESPEED, ZEUS etc. Node.js simplifies some of theimplementation by having full stack JavaScript using which programmers could usethe same programming language on client and server side. While this is one of themajor advantages, other advantages include non-blocking asynchronous model andeasier implementation of sockets.

4.4.2 Implementation Details

The MEM nodes are connected to each other directly or indirectly through a wirelessmesh network which is not TCP/IP based. This is a sensor network which is used forintra-grid communication. Every node or gateway in the Microgrid Network (MN) hasan associated address. This is used by the sensor network communication and also forMC to individually identify the nodes. The MEM system implements a hybrid push-pull mechanism for communication. This means the MEM nodes have the ability to


respond to requests sent by the MEM gateway (pull mechanism) or MC and send in-formation independently to the MG/MC through a push mechanism. This is usuallyan energy log which is sent every minute automatically. The MEM gateway receivesthis and automatically pushes it to MC. An application layer called microE was writ-ten to handle application level communication in the microgrid network. The MC isresponsible for encapsulating the data packets in this format. A sample command setis shown in figure 4.2.

FIGURE 4.2: MicroE command set

A sample request and response is shown below.

FIGURE 4.3: Sample request and response commands

The web application helps users control and manage the microgrid. While the de-velopment of the web application is in progress, it is aimed to have the following fea-tures

• Grid Network - this feature of the web application gives the user a completeoverview of the microgrid. This features the list of active nodes, total energy con-sumption, grid voltage and current. The user also has the capability to remotelyturn on or off a source or a load.

• Microgrid Scheduler - the user can set schedules for each load or source in themicrogrid to turn on or off at a particular time.

• Health - the stability of the microgrid depends on MG and MN being active. Thisenables the commands from MC to be executed immediately on these nodes. The


back-end engine sends a ’heartbeat’ to MN to assess if all the nodes are active andnotify the user if two successful heartbeats to a particular node fail. This sectionof the web application constantly updates to tell the user the health of the grid.

• Spending - tracking energy costs is one of the most important features. This willhelp users how their spending varies over hour, day, week or month of the year.

MEM User and Grid setup

This section illustrates few basic steps in setting up the web application and theback-end engine. Each user has an unique keyword called MEM ID which isused to authenticate the TCP connection and also identify the user across theweb application and the TCP back-end engine.

FIGURE 4.4: Setting up MEM users

Figure 4.4 shows the first step to setup MEM users. Each user is given an uniquecode called MEM ID. To get access to the microgrid network on the web app and tounlock full functionality, the user has to enter this the first time the application is used.Once the user enters the MEM ID, the back-end engine authenticates this and on asuccess, enables full functionality of the application.

The TCP sever constantly handles multiple connections from different gateways. Itacts on the connections only after authentication. Un-authenticated TCP connectionsare discarded by the back-end engine. Figure 4.5 shows the flow for setting up the grid.On every attempt of a TCP connection establishment between MC and MG, MG emitsthe MEM ID as the first set of bytes. This helps MC to authenticate each connectionbefore processing it. Once the connection is authenticated, Node TCP sends a heartbeatto assess the configuration of the grid. MG receives this and sends it as a broadcast toall the nodes. An example is shown in figure 4.6.

The broadcast takes place in the MSN and all active nodes respond back with aspecific response command. The gateway then relays these messages back to the cloud.This gives the back-end engine the complete grid configuration.


FIGURE 4.5: Setting up MEM grid

FIGURE 4.6: MEM heartbeat


Once the MC gets a list of all active nodes, it is now ready to send or receive com-mands to the MN.

FIGURE 4.7: MicroE command set

4.5 Summary

Cloud computing technologies provide a number of advantages such as scalability,resource sharing, elasticity etc. Its been increasingly used for social media and util-ity applications. An introduction to cloud computing and its features has been pre-sented in this chapter. Integrating cloud computing technologies to a power systemis particularly interesting as it enables easy implementation of applications like IoTand help deploy intelligence and big data stacks. The implementation of a Node.jsbased cloud platform for MEM has been presented in detail. The core back-end en-gine has been de-coupled from the web application making all subsystems modularand fault tolerant. The Node.js TCP server is responsible for handling communicationwith the MN and the Node.js HTTP handles the web application. The two serversshare a MySQL database. Node.js is an event-driven framework which has the abilityto handle thousands of connections and execute asynchronous actions smoothly. Thenext chapter presents the Microgrid Network (MN) architecture and MEM hardwareplatform. Performance analysis of MSN and the CPS for microgrids has also been pre-sented in-depth.

Chapter 5

Experiments and Results

5.1 Microgrid Network Architecture

The Microgrid Network (MN) forms the core of the entire framework. The architectureis illustrated in figure 1.2. It consists of the following components.

• Microgrid Power Network - In figure 1.2, network in red indicates the power topol-ogy. The microgrid connects to the utility at the Point of Common Coupling(PCC). The loads are connected to the microgrid through their respective switchesand DC entities like PV, battery banks are interfaced through inverters. The mi-crogrid is capabable of operating in island mode (when it is disconnected fromthe utility grid) or in grid connected mode (when it is connected to the utility).

• Microgid Sensor Network (MSN) - This is an IEEE 802.15.4 based network withAtmel’s Light Weight Mesh (LWM) as the communication stack. This sensor net-work forms part of the communication framework which is responsible for con-trolling and monitoring loads and energy sources at the microgrid level. A simpleapplication layer was written for exchange of messages between the MicrogridNode (MN) and the Microgrid Gateway (MG).

• Microgrid Gateway (MG) - This integrates the Microgrid Sensor Network with theMicrogrid Cloud. It acts as a translator between IEEE 802.11 communication pro-tocol and IEEE 802.15.4 network. MG is responsible for analyzing and convertingthe IEEE 802.15.4 data from MN and packaging it into IEEE 802.11 protocol fortransmission to MC. MG should also be capable of converting data from IEEE802.11 protocol to IEEE 802.15.4 protocol for communicating with MSN.

• Microgrid Node (MN) - Every load and energy source is connected to MN. MNoffers a number of features in addition to WSN capabilities like energy measure-ment, control relays, time-stamping of all events through Real Time Clock (RTC)and local storage through Secure Digital (SD) card.

• MicroE - This is an application for controlling and monitoring entities in the mi-crogrid. It sits on the mesh communication stack. Every microE packet sent orreceived has a command header and a value header as shown in figure 5.1. TheMG acts as a central controller for the MSN and dispatches request commands tothe desired MN. The MN responds with a microE packet which consists of a re-quest command and a value. Sample request and response commands are shownin table 5.1.

31

Chapter 5. Experiments and Results 32

FIGURE 5.1: MicroE request-response mechanism

TABLE 5.1: MicroE Sample Request and Response Commands

Request Command Response Command

TEST RADIO ACK RADIOGET VRMS ACK VRMSGET IRMS ACK IRMSGET ACEN ACK ACEN

GET PERIOD ACK PERIODSET RELAY ON ACK RELAY ONSET RELAY OFF ACK RELAY OFF

GET RELAY STATUS ACK STATUS

5.2 MEM Hardware Platform

In order to implement various communication and utility functionality such as Wi-Fi,RF, storage, RTC (Real Time Clock), a robust embedded platform is required. Thissection deals with the hardware used for this study.

5.2.1 MEM Hardware Architecture

FIGURE 5.2: MEM hardware architecture

The core functionality of MG is to act as a translator between different communica-tion protocols. It consists of a central CPU with an integrated IEEE 802.15.4 compliantRF transceiver. It also consists of a Wi-Fi module, SD storage and a RTC. The MEMnode shares a similar platform without wireless internet capabilities. However, it has


energy metering capabilities to measure current, voltage, energy, frequency and powerfactor of each entity in the microgrid. This is shown in figure 5.2.

MCU

The MEM MN and MG use Atmel’s ATmega256RFR2 as the core CPU. It has the fol-lowing features

• 256K bytes of In-System Programmable (ISP) flash

• 8K bytes EEPROM

• 32K bytes SRAM

• Max. operating frequency up to 16 MHz

• Integrated 2.4 GHz RF transceiver.

• Supports 250 kb/s, 500 kb/s, 1 Mb/s and 2 Mb/s data rates

• USART, SPI, I2C interfaces

• Supports ZigBee, IEEE 802.15.4 stacks, RF4CE, SP100, WirelessHART, IPv6, 6LoW-PAN

Energy Measurement

One of the important functions of MN is to measure grid parameters at the entity levelsuch as voltage, current, energy, frequency and power factor. MN uses ADE7763 en-ergy metering IC to accomplish this task. The energy IC is interfaced with the MicroController Unit (MCU) through Serial Peripheral Interface (SPI).

Data Logging

MN logs all measured data and events locally onto a Secure Digital (SD) module. Incase of loss of connection to the MC, data can be retrieved. Also, once the connectionto MC is re-established, MC can sync with the MGN by requesting history data fromMN.

Time Stamping

All measurements, data logging and activity at MN are times-stamped using DS1337Real Time Clock (RTC). This helps understand the behavior of the individual entityand the grid for future data analysis.

The hardware platform consists of a communication board and a power interfaceboard as shown in figure 5.3 and 5.4.

The communication board hosts the microcontroller unit, the communication andstorage systems. The power interface board hosts the latching relays, relay interfacecircuitry, load current and input voltage filtering and divider circuitry. The two boardsinterface through a ribbon cable or jumper wires. The advantage with this kind ofarchitecture is that the communication board is not exposed directly to high voltageand current. This reduces noise on the communication lines. The communication boardprovides digital signal lines which interface withe LED indicators, relays, voltage and


current measurement circuitry on the power interface board. The other advantage isthat the interface board can be easily modified to accommodate higher or lower ratingrelays depending on the application or user requirements.

FIGURE 5.3: MEM Communication Board

FIGURE 5.4: MEM Power Interface Board


5.3 Wireless Sensor Network (WSN) for Microgrids

While a number of studies have evaluated WSNs in different environments such asbuildings, residential establishments or power substation, they fall short of a compre-hensive evaluation which takes into account all the key factors that affect the perfor-mance of WSN like spatial arrangement, physical environment and interference. An-other key concept which several studies fail to take into account is variation of applica-tion reliability in wireless sensor networks. For microgrids, the application reliabilitycan be defined as the ability of the system to perform microgrid specific tasks suchas sending request messages through MSN to energy sources and loads to obtain gridparameters such as voltage, current, frequency or to send instructions from the MG toturn ON/OFF a specific load or energy source. It is important to evaluate the effect ofwireless sensor network on the ability to complete these tasks. The paper evaluates theWSN with the traditional performance metrics such as PRR, LQI and RSSI and buildson that by introducing two new metrics RRR (Response Reception Ratio) and Micro-grid Reliability Factor (MRF) which assess WSN in a microgrid context. The study aimsto focus on interesting topics such as

• Performance of MSN in different physical environments both indoor and outdoor

• Effect of spatial arrangement (physical topology) of sensor nodes (linear and dis-tributed topology) on the performance of MSN

• Assessment of application level reliability in MSN for microgrid applications.

• Study of correlation between RSSI, LQI and network performance

5.3.1 Physical Environments

Three physical environments were chosen to evaluate the performance of MSN. Theseinclude a home, an open field and an electrical engineering lab. The home was chosento emulate the physical environment of a home microgrid where WSN would be usedto monitor and control different loads like TV, washer, dryer and energy sources andstorage systems such as PV and a battery system. The electrical engineering lab whichhouses electric machines, power electronics and mechanical tools and machines waschosen to emulate an industrial setup. An open field was chosen to understand theperformance in outdoor environments.

5.3.2 Performance Metrics

This study defines a new performance metric: Microgrid Reliability Factor (MRF) toassess the WSN performance in a microgrid context. It also takes into account tradi-tional evaluation of the network performance through Packet Reception Ratio (PRR)and Response Reception Ratio (RRR). Link Quality Indicator (LQI) and Received Sig-nal Strength Indicator (RSSI) are defined as correlation performance metrics and exper-iments have been conducted to understand if there is a strong correlation between LQI,RSSI and network performance.

• Microgrid Reliability Factor (MRF) - application layer reliability is extremely im-portant in microgrid control and management. MRF can be defined as the abilityof the communication framework to perform microgrid related tasks such as


(a) Open Field (b) Engineering Lab (c) Home

FIGURE 5.5: Physical Environments

1. Sending a request packet to a MN to obtain voltage, current, frequency orenergy production or consumption values of the energy source or load.

2. Sending operation set points to provide corrective control of the energysource or loads.

3. Sending command packets to MNs to remotely turn ON/OFF a source orload.

These activities are referred to as application level tasks in this microgrid frame-work. In case of packet loss, application level reliability is maintained by execut-ing packet retries. The packet retry mechanism is enabled at both MN and MGlevel so that delivery of request and response packets can be ensured. Acknowl-edgements (ACKs) are requested by both the MG and MN. On sending a requestpacket to MN, MG waits n milliseconds for an ACK and on failure re-sends therequest packet. The MN sends a response packet and waits m milliseconds for anACK and on failure re-sends the response packet.

1. Immediate Retry - in the event of failure to receive an ACK, both MN andMG re-send the request or the response packet immediately. After a certainnumber of re-tries, the management system declares the node to be inactiveand sends a notification to the user.

2. Waited Retry - when the ACK reception fails, MG ignores this and continuesto process the packets to other MNs. It waits for a certain time period andthen re-tries sending a packet to the MN. After a certain number of waitedretries, the node is declared to be inactive. If the MN fails to receive an ACKfor a response packet it sent, it waits for a certain time period before sendinga response packet to MG.

3. Hybrid Retry - this implements both immediate retry and waited retry mech-anisms. If MN or MG fail to receive an ACK, they re-send the packet im-mediately and in the event of failure in the second attempt, it switches towaited retries. After a certain number of waited retries, the node is declaredto be inactive.


Packet Reception Ratio (PRR) and Response Reception Ratio (RRR) are used toevaluate the WSN in the traditional wireless networking context. Two correla-tion parameters RSSI (Received Signal Strength Indicator) and LQI (Link QualityIndicator) are also measured to evaluate their correlation with PRR and RRR.

• Packet Reception Ratio (PRR) - this is defined as the ratio of packets sent by thesource node to the number of packets received by the destination node.

• Response Reception Ratio (RRR) - this study defines a new parameter RRR which isthe ratio of packets sent by the source node to the destination node to the numberof response packets received for the request packets. This parameter is particu-larly important in a microgrid framework where delivery of response packets isequally important for grid stability.

Correlation Metrics

• Received Signal Strength Indicator (RSSI) - This is the measure of the RF power in achannel.

• Link Quality Indicator (LQI) - This is a cumulative value usually used in multi-hopnetworks to assess the cost of the link. The source node assigns a LQI value toa packet it sends out and this is modified as it propagates through a multi-hopnetwork.

Linear Topology Test

This experiment was conducted to analyze the performance of MSN in a laboratory(to emulate an industrial environment). 7 sensor sending request messages to receivernodes. The data packets were sent at a rate of a packet per 2 seconds and the desti-nation node was chosen randomly during each transmission. For this test, the nodeswere placed in a linear arrangement as shown in figure 5.6. The adjacent nodes wereplaced 15.8 feet apart with MN6 at a distance of 95 feet from MN0. The lab houseselectrical machines, power electronics equipment, electrical and mechanical tools andlab benches.

FIGURE 5.6: Linear Topology Test

Over the course of the experiment, a total of 555 data packets were sent by thecentral node (MN0). In response to these request data packets, 549 ACKs and 546 re-sponses were received. Figure 5.8 shows the individual node and overall system perfor-mance of the sensor network. Background noise was measured during every messagereception and it remained constant at -90 dBm throughout the course of the experiment.Several interesting observations were made from this experiment. The constitution ofthe physical environment plays a big role in the performance of the nodes. MN6 wasplaced in an area which also housed a large metal cabinet, metal frames and a woodendoor. On analyzing the performance of MN6 which experienced packet delivery fail-ures, a major reason was found to be packet delivery failure at the physical mediumlevel which can be attributed to the proximity of MN6 to the physical obstructions


and metal objects. Figure 5.7 shows the RSSI and LQI variation for each node. MN6showed high variation in LQI values and this can be correlated with its poor perfor-mance in comparison with the rest of the MNs. Similar correlation can be seen for theLQI variation for MN3 and its PRR and RRR values. Although MN5 shows the greatestvariation in RSSI values among MNs, it exhibits 100% PRR and RRR. On the contrary,MN6 shows almost constant RSSI value throughout the course of the experiment. Forthe laboratory environment, LQI served as a good indicator of network performancewhereas RSSI does not provide any correlated behavior with network performance.

FIGURE 5.7: RSSI and LQI variation for linear topology in the laboratory

FIGURE 5.8: PRR and RRR for linear topology in the laboratory

Microgrid Reliability Test for Linear Topology

A series of five experiments were conducted to evaluate the Microgrid Reliability Fac-tor (MRF) in WSN. The nodes were placed in a linear topology with a distance of 10feet between adjacent nodes and 60 feet between the farthest two nodes. With eachexperiment, the nodes were re-arranged to evaluate effect of physical placement on theoverall system and the individual node. The goal of these experiments is to evaluatethe number of retries it takes for MG (MN0 in this case) to relay a message successfullyand get back an ACK. These experiments implement a hybrid retry mechanism andACKs are enabled at both MN and MG (MN0). Figure 5.9 shows the result for MN0


in all five experiments. Similar results can be generated for the rest of the MNs. Per-formance of MN0 is shown and discussed here as it performs the role of the centralcontroller.

FIGURE 5.9: Microgrid Reliability Test for linear topology in the labora-tory

The experiments show 100% application reliability with a hybrid packet retry sys-tem. All packets were successfully delivered to the MNs from MN0 either on the firstattempt or on a re-try. It can be observed from the figure that nearly 99% of the packetswere delivered in the first attempt. It can also be observed that all the packets weresuccessfully delivered within the first retry.

Distributed Topology Test

In this experiment, the MN nodes were placed in a distributed arrangement in thelaboratory. The nodes were spread across the lab as shown in figure 5.10. A total of 563packets were sent by MN0 and it received 563 ACKs and 560 responses. The overallsystem PRR was 100% and RRR was 99.46% . Background noise was measured at thereception of every message and it remained constant at -90 dBm. It was found that LQIand RSSI values do not provide any correlated behavior with network performance.LQI remained constant at 255 throughout the experiment for all nodes with variationfor MN4. This contradicts the 100% PRR and RRR observed for MN4. The PRR andRRR for all the nodes is visualized in Figure 5.12. The RSSI and LQI variation for thistopology can be seen in Figure 5.11.

FIGURE 5.10: Distributed Topology in the laboratory


(a) RSSI for distributed topology in lab (b) LQI for distributed topology in lab

FIGURE 5.11: RSSI and LQI for distributed topology in lab

FIGURE 5.12: PRR and RRR for distributed topology in the laboratory


5.3.3 Home Environment

This experiment was conducted to evaluate the physical environment in a home. Thephysical configuration of MNs are shown in figure 5.13. A total of 647 packets weresent by MN0 and it received 528 ACKs and 520 responses. The overall system PRRwas 82% and RRR was 80.3% . PRR and RRR for each node can be seen in Figure 5.15.Packet delivery failures were mostly observed due to failure at the physical mediumlevel which can be attributed to obstructions due to walls and doors. The RSSI and LQIvariation for this topology can be seen in Figure 5.14.

FIGURE 5.13: Distributed topology in home

(a) RSSI for distributed topology in home (b) LQI for distributed topology in home

FIGURE 5.14: RSSI and LQI for distributed topology in home

MN0 and MN1 shared Line-of-Sight (LoS) configuration. The rest of nodes wereseparated by walls and closed doors. It was observed that both LQI and RSSI show highvariation for all nodes and it is difficult to use them to estimate the performance of thenetwork. In a home environment, the nodes may or may not share a LoS configuration.This depends on the home occupants and also the number of loads and sources. Inthe case of weak links between nodes, range extenders can be added to boost network


FIGURE 5.15: PRR and RRR for distributed topology in home

performance. The only objective of these range extenders will be to relay messages andboost range and performance. They will not serve as MN or MG.

Microgrid Reliability Test

A series of five experiments were conducted to evaluate the Microgrid Reliability Fac-tor (MRF) in a home environment for a distributed placement topology. The nodeswere re-arranged with each experiment to introduce variability. Typically each roomin the house had a node with the living room having two due to its larger size. Theseexperiments implement a hybrid retry mechanism and ACKs are enabled at both MNand MG (MN0). Figure 5.16 shows the result for MN0 in all five experiments.

FIGURE 5.16: Microgrid reliability test for home environment

In a home environment, 100% application reliability was achieved. The percentageof packets delivered to MNs in the first attempt varied from 82% to 88% for the ex-periments. When the packet delivery fails at the first attempt, the MN0 retries to sendthe packet immediately. In the event of first re-try failure, it backs-off and re-sends thepacket after a certain time period.

5.3.4 Field

Linear and distributed topology was tested for an outdoor environment. An open fieldwas chosen to emulate the physical environment of an outdoor microgrid. 7 sensor


nodes were used with one node (MN0) acting as a central node. The packet transmis-sion rate was set at 1 packet/2s and the destination node was chosen randomly at eachtransmission.

5.3.5 Range Test

This experiment was conducted to assess the maximum range between two nodes in anoutdoor environment with PRR and RRR greater than 99% . In an open field this wasfound to be 225 feet when the two nodes are at an elevation of 2 feet from the ground.

Linear Topology Test

The sensor nodes were placed in a linear arrangement as shown in Figure 5.5(a). Adja-cent nodes were separated by distance of 15.8 feet and the farthest nodes were 95 feetapart. A total of 570 packets were sent by MN0 and it received 560 ACKs and 560 re-sponses. The overall system PRR and RRR was 98.2% . PRR and RRR for each nodecan be seen in Figure 5.18. It is difficult to draw conclusive estimate of the network per-formance by looking at the LQI and RSSI values as they showed great variation whichdid not correlate with the performance. The RSSI and LQI variation for this topologycan be seen in Figure 5.17.

(a) RSSI for linear topology in field (b) LQI for linear topology in field

FIGURE 5.17: RSSI and LQI for linear topology in field

FIGURE 5.18: PRR and RRR for linear topology in field


Microgrid Reliability Test

A series of five experiments were conducted to evaluate the Microgrid Reliability Fac-tor (MRF) in an outdoor environment.The nodes were placed in linear topology witha distance of 10 feet between adjacent nodes and 60 feet between the farthest. Witheach experiment, the nodes were re-arranged to introduce variability. These experi-ments implement a hybrid retry mechanism and ACKs are enabled at both MN andMG (MN0). Figure 5.19 shows the result for MN0 in all five experiments.

FIGURE 5.19: MRF for linear topology in an open field

Distributed Topology Test

In this experiment, the nodes were placed in a distributed arrangement as shown infigure 5.20. MN0 sent a total of 642 packets and received 618 ACKs and 600 responseswith a 96.26% PRR and 93.45% RRR. Individual node and overall system performancecan be seen in Figure 5.22. The RSSI and LQI variation is illustrated in Figure 5.21. It canbe seen that both RSSI and LQI show great variation throughout the experiment and itis difficult to estimate network performance based on these parameters.

FIGURE 5.20: PRR and RRR for distributed topology in an open field


(a) RSSI for distributed topology in field (b) LQI for distributed topology in field

FIGURE 5.21: RSSI and LQI for distributed topology in field

FIGURE 5.22: PRR and RRR for distributed topology in field


5.4 MSN Conclusion

This study introduces a new communication framework for microgrid control andmanagement called Microgrid Network (MN) which consists of Microgrid Cloud (MC)and Microgrid Sensor Network (MSN). In-depth performance evaluation of MSN wasconducted which implements an IEEE 802.15.4 based sensor network. An engineeringlab, home and open field were chosen to emulate physical environments of microgridswith linear and distributed physical topologies. The performance of the MSN due tophysical environment and spatial arrangement was studied. The correlation betweenLQI, RSSI and network performance was evaluated.

• Effect of physical environments on the network performance is significant. Forboth the spatial arrangement topologies, the engineering lab performed signifi-cantly better compared to an open field and a home environment.

• It was observed that elevation of the nodes have a huge impact on the perfor-mance of network. For outdoor environment tests, the packet transmission failedat a physical medium level when the nodes were placed on the ground. Raisingthe elevation of the nodes to about 2 feet from the ground increased PRR and RRRto greater than 97%

• The constitution of the physical environment also affected the performance. Nodesplaced close to metal structures, wall corners, behind solid objects exhibited poorperformance.

• While LQI showed correlation with the network performance for linear topol-ogy in the laboratory, it failed to show any correlation in other environments andtopology. RSSI shows no correlation with the network performance in any topol-ogy or environment.

• The MSN framework achieved 100% application reliability through packet retrymechanisms for all environments and topologies.

• The rate of packet transmission was maintained at 1 packet/2s for all experi-ments. However, it was found experimentally that the rate could be increased to1 packet/300ms maintaining the same network performance. This is particularlyuseful in case of sub-second operation for microgrids.

• Self healing and mesh capabilities of MSN framework has several advantagesover traditional wireless capabilities. Introducing extender nodes (meant only forrouting messages) increased the range and reliability of the network link betweensource and destination nodes. This was experimentally verified by placing a MNat relatively low elevation behind physical objects. As expected, the number ofretries for successful delivery was high. A router node was placed between MN0and the destination node and this improved the performance of the link drasti-cally. Similar experiments were conducted to increase the range between nodesby placing intermediate router nodes.

• It was found experimentally that the communication range between 2 nodes(without multi-hop) depended on transmit power and the elevation. Elevationof the nodes to about 2-3 feet above the ground showed highest performance.The transmitter has different transmit power levels (-16.5 dBm to 3.5 dBm) whichcan be set by the user. It was observed that the communication range increasedwith increase in transmit power.


5.5 Cyberphysical System (CPS) for Microgrids

5.5.1 Objective and Importance

The objective of this study is to characterize parameters of a computer network and em-bedded computing system in an integrated environment. While studies [37], [38], [39],[40], [41] have been conducted to measure and assess network performance which in-clude latency, packet loss and jitter, extensive studies have not been conducted to studythe behavior of a cyberphysical system. Cyberphysical system consists of an integra-tion of cyber components such as servers, wireless and wired networks, data storageand physical components such as measurement sensors, embedded systems, powersystems etc. In some cases, these systems are time-sensitive: power systems, industrialcontrol environments etc. The cyber system in this study consists of a cloud (server), In-ternet Service Provider(ISP) network/ university network, switches and routers. Theembedded system platform consists of a low power RF System-on-Chip that is inte-grated with peripherals such as energy metering, storage, real time clock and wirelesscapabilities (MG). Tests were conducted to measure the RTT (Round Trip Time) be-tween the cloud and the physical system which in this case is the embedded platformor MG. Second set of experiments were conducted where interference was introducedto assess the behavior of the system and identify the variation of the RTT. RTT is animportant parameter for systems which are connected to the cloud or which run a localsensor network. For time sensitive applications, it is important for the RTT to be withinthe critical value to avoid failure of the system.

This study deals with introducing secondary and tertiary control for managing dif-ferent entities in the microgrid. The central intelligence in this control scheme is acloud(server) which makes intelligent decisions based on information relayed fromdifferent entities in the microgrid. The process of message transmission, processingand relaying back has to take place in the range of milliseconds or less than three-fourseconds. This is critical to prevent grid failure. To achieve this kind of time sensitiveperformance, one has to understand individual subsystems behavior in a cyberphysi-cal environment and its effects on overall system performance. The experiments con-ducted in this section help us assess important parameters in a cyberphysical system.

5.5.2 Round Trip Time (RTT) assessment without interference

This experiment characterizes the RTT for a simple cyberphysical system. The physicalsystem is a MEM gateway (MG). The cyber system consists of a router, university net-work and a cloud in WiNGS lab. The architecture of the remote server is described inchapter 4. The experiment was setup to measure RTT between MG and MC. MC sendsa TCP packet (50 bytes) to MG every 5 seconds. The MG receives this packet and sendsback a response. This RTT is recorded by the server. The objective of this performanceis to assess how RTT varies for a cyberphysical system over hour, time of day and dayof week. If the TCP connection fails at the physical or the server end, MEM gatewayresets the connection immediately.


(a) Average RTT per day basis (b) Peak RTT per day basis

(c) Average RTT per hour basis (d) RTT Cumulative Distribution Function

(e) RTT Probability Mass Function

FIGURE 5.23: RTT variation over the course of the experiment


(a) RTT variation on Friday (b) RTT variation on Saturday

(c) RTT variation on Sunday (d) RTT variation on Monday

(e) RTT variation on Tuesday (f) RTT variation Wednesday

FIGURE 5.24: RTT variation per day basis


5.5.3 RTT assessment with microwave appliance interference

Home and industrial environments have a number of sources of radio interference.This might cause reliability issues for wireless links. This can affect wireless networkssuch as IEEE 802.11 or IEEE 802.15.4. Performance of IEEE 802.11 networks in home isstudied in [42]. Interference due to microwave appliances was observed which causedpacket loss as high as 60 percent when the appliance was placed at a distance of 0.5 feetfrom Wi-Fi. A number of studies have tried to characterize Wi-Fi performance due toboth narrow and wide-band interference [43], [44], [45]. The study [45] observed thata residential microwave caused a Continuous Wave (CW) like interference which wascentered around 2.45 GHz. It was observed that the total active interference period wasabout 8 ms (out of 20 ms power cycle at 50 Hz or 16 ms at 60 Hz). In order to assess howinterference affects RTT in a cyberphysical system, an experiment was setup to measurethe variation of RTT with a microwave close to the Wi-Fi on the MEM gateway. Theexperiment was setup similar to the previous section. During packet transmission andreception between MC and MG, the microwave was operated intermittently. A sectionof the experiment is shown in figure 5.25(a).

(a) RTT variation with interference (b) RTT Cumulative Distribution Function

(c) RTT Probability Mass Function

FIGURE 5.25: RTT variation due to interference


5.6 CPS Tests Conclusion

5.6.1 RTT without interference

• The average RTT over the course of 6 days was measured to be around 15- 20 ms.This is illustrated in figure 5.23(a).

• Peak RTT variation was observed between 2 - 5 am. One of the factors could bedue to regular network updates on the university network which are scheduledduring this time.

• RTT variation was seen throughout the day for all 6 days of the experiment. Thiscan be a combination of factors - increased network traffic, increased traffic on theaccess point to which the Wi-Fi module was connected to and higher bandwidthapplications on connected devices.

• The peak RTT varied from 1468 ms - 4662 ms. This can be seen in figure 5.23(b).

• From the probability cumulative distribution function, it can be observed that99% of the RTT values occur within 37 ms.

5.6.2 RTT with interference

The microwave oven was placed in close proximity with the Wi-Fi module on MG.The microwave appliance was operated intermittently and it was observed that RTTincreased drastically when the microwave oven was switched on. This can be seen infigure 5.25(a). It was also observed that there was no loss of data at the applicationlevel. Possible reason for this behavior could be that the microwave appliance causedinterference which resulted in packet loss at the Wi-Fi module. This caused TCP packetre-ordering which resulted in application level reliability. The cumulative distributionfunction and probability mass function plots can be seen in figures 5.25(b) and 5.25(c)respectively.

Conclusion and Future Work

Advancements in power electronics, communication and a thrust to move towards agreener and decentralized power system has led to the popularity of microgrids. Themicrogrid global market is estimated to grow to a $ 40 billion industry in 2020 withnearly 24000 industrial and commercial sites ready for microgrid installation. A corecomponent of a microgrid is the energy management system which is responsible forensuring reliable operation of the microgrids in grid-connected and island mode ofoperation. This study aims to develop a complete end-to-end framework for this man-agement system. The proposed microgrid energy management system is built on theInternet of Things (IoT) and Wireless Sensor Network (WSN) paradigm. This uniqueframework of integrating a power system with advanced communication technologieslike cloud computing, wireless mesh networks etc. gives better control, managementand monitoring system for microgrids. This study aims to develop and test the infras-tructure in this context. Microgrid cloud was developed with an event-based serverframework with capability to handle thousands of connections in a time sensitive en-vironment. The performance of wireless sensor networks and the cyberphysical in-frastructure for a power system was studied in detail. With a goal of achieving 100 %application reliability in communication frameworks, the MSN was tested in variousphysical environments, spatial orientation and message transmission rates. 100 % ap-plication reliability was achieved using different types of retry mechanisms. The sensornetwork performance was also assessed with traditional parameters such as PRR, RSSIand LQI. Second part of the study focuses on assessing network performance when thepower system is integrated with cyber components such as cloud, computer networksetc. It gives good insight on RTT variation over time of day or week and will help setdesign rules to deal with increased packet transmission or reception times. An embed-ded platform was designed and developed with capabilities such as energy metering,time-stamping, storage, RF network and Wi-Fi capabilities.

Future work includes developing intelligent algorithms for the energy managementsystem which extends beyond monitoring capabilities. Secondary and tertiary controlfor microgrids have to be implemented using the infrastructure developed in this study.Another potential for future work lies in extending the functionalities of the web ap-plication built in this study to include rich visualization, energy pricing and scheduler.Another potential for future work lies in modeling a power system connected to a cy-ber environment and assessing if the practical implementation follows the theoreticaland simulated models closely. While several studies have modeled power systems andcommunications separately, not much work has been to comprehensively model thisintegrated system.

52

Appendix A

MEM Gateway and NodeSchematics

This section contains the schematics for the MEM node and gateway embedded plat-form. Altium Designer was used to layout the schematics and design the printed circuitboard.

53

1

1

2

2

3

3

4

4

D D

C C

B B

A A

Title

Number RevisionSize

A

Date: 12/1/2015 Sheet ofFile: C:\Users\..\Antenna_MCU.SchDoc Drawn By:

Antenna Design

Ashray Manur7

Balanced Diff. Port3

Balanced Diff. Port4

GN

D5

GN

D6

Unbalanced Port 1

GN

D2

B12450BM15A0015E

GND

GND

RFN

RFP

J2 3

GND 2

J3 1

V14

J15

V26

RF1

AS222-92 RF Switch

DIG1

DIG2

GND

J700

SMA PCB mounted connector19-46-1-TGG

GND

GND 2

GND 3

GND 4

Feeding Point1

A700

Ceramic Ant-2450AT18D0100

GND

REV.18

C70

22pF

C71

22pFC72

22pF

R700.0

O50_0 O50_1

O50_2

O50_4

O50_3

O50_5

O50_6PIA70001

PIA70002

PIA70003

PIA70004

COA700

PIB101

PIB102

PIB103

PIB104

PIB105 PIB106

COB1

PIC7001 PIC7002

COC70 PIC7101 PIC7102

COC71

PIC7201 PIC7202

COC72

PIJ70001

PIJ70002PIJ70003PIJ70004PIJ70005

COJ700

PIR7001

PIR7002

COR70

PIRF101

PIRF102

PIRF103PIRF104

PIRF105

PIRF106

CORF1

PIRF104

PIRF106

PIA70002

PIA70003

PIA70004

PIB102

PIB105 PIB106

PIJ70002PIJ70003PIJ70004PIJ70005

PIRF102PIB101 PIC7001NLO5000

PIC7002 PIRF105NLO5001

PIC7101PIRF103NLO5002

PIC7102

PIJ70001

NLO5003

PIC7201PIRF101NLO5004

PIC7202

PIR7001NLO5005

PIA70001

PIR7002NLO5006

PIB103

PIB104

1

1

2

2

3

3

4

4

D D

C C

B B

A A

Title

Number RevisionSize

A

Date: 12/1/2015 Sheet ofFile: C:\Users\..\EnergyIC_ADE7763.SchDoc Drawn By:

VCC_EXT_5V

1 2

J500

Energy_IC

VDD_ENERGY

VDD_ENERGY

GND GND

GND

V2N_IC

V2P_IC

GND GND

MOSI_MCUMISO_MCUSCK_MCU

CF 11

ZX 12SAG# 13IRQ# 14

CLKIN 15

CLKOUT 16

CS# 17SCLK 18DOUT 19DIN 20

V1P4

V1N5

V2N6

V2P7A

GN

D8

REF9D

GN

D10

AV

DD

3

DV

DD

2

RES

ET#

1

U500 ADE7763_ENERGY_IC

ENERGY_RST

ENERGY_IRQ

ENERGY_CS

GND GND

CLKOUT

CLKIN

CLKIN CLKOUT

Energy_IC_ADE_7763

REV.1

Ashray Manur5

Energy IC current measurement

Crystal for Energy_IC

GND

Connection from Power Interface Board

Quartz Crystal, HC-49 (US)

ECS Part No. ECS-35-17-4Digi-Key Part No. X079-ND

Relay1_ONRelay1_OFF

VCC_Reg_3.3V

8

V1N_IC

V1P_IC

C5722pF

C5822pF

C5310µF

C540.1µF

C5210µF

C510.1µF

C510µF

C560.1µF

X5

3.579545MHz

D52

1N4148

D53

1N4148

D50

1N4148

D51

1N4148

Relay2_OFFRelay2_ON

GND

1 23 45 67 89 1011 1213 1415 1617 18

J501

Header 9X2

V2P_ICV2N_IC

V1N_ICV1P_IC

PIC501

PIC502COC5

PIC5101

PIC5102

COC51PIC5201

PIC5202

COC52PIC5301

PIC5302

COC53PIC5401

PIC5402

COC54

PIC5601

PIC5602COC56

PIC5701

PIC5702COC57

PIC5801

PIC5802COC58

PID500A PID500K

COD50

PID510A PID510K

COD51

PID520APID520K

COD52

PID530APID530K

COD53

PIJ50001 PIJ50002

COJ500

PIJ50101 PIJ50102

PIJ50103 PIJ50104

PIJ50105 PIJ50106

PIJ50107 PIJ50108

PIJ50109 PIJ501010

PIJ501011 PIJ501012

PIJ501013 PIJ501014

PIJ501015 PIJ501016

PIJ501017 PIJ501018

COJ501

PIU50001PIU50002PIU50003

PIU50004

PIU50005

PIU50006

PIU50007

PIU50008

PIU50009

PIU500010

PIU500011

PIU500012

PIU500013

PIU500014

PIU500015

PIU500016

PIU500017

PIU500018

PIU500019

PIU500020

COU500

PIX501PIX502

COX5

PIC5701

PIU500015

PIX502

NLCLKIN

PIC5801

PIU500016

PIX501

NLCLKOUT

PIU500017

PIU500014

PIU50001

PIC502

PIC5102PIC5202 PIC5302 PIC5402

PIC5602

PIC5702 PIC5802

PID520A

PID530A

PIJ50102

PIJ50104

PIJ50106

PIJ50108

PIJ501010

PIJ501012

PIJ501014

PIJ501016

PIJ501018

PIU50008 PIU500010

PIU500019

PIU500020

PIC501 PIC5601 PIU50009 PIU500011

PIU500012

PIU500013

PIJ501013

PIJ501011

PIJ501017

PIJ501015

PIU500018

PIJ50107

PIU50005NLV1N0IC

PIJ50109

PIU50004NLV1P0IC

PID510A

PID520K

PIJ50103

PIU50006NLV2N0IC

PID500A

PID530K

PIJ50105

PIU50007NLV2P0IC

PIJ50001

PIJ50101

PIC5101PIC5201 PIC5301 PIC5401

PID500K

PID510K

PIJ50002

PIU50002PIU50003

1

1

2

2

3

3

4

4

D D

C C

B B

A A

Title

Number RevisionSize

A

Date: 12/1/2015 Sheet ofFile: C:\Users\..\Indicators and Headers.SchDocDrawn By:

JTAG_TDI

JTAG_TDO

JTAG_TMS

JTAG_TCK

GND

GND

RST

VCC_Reg_3.3V

VCC_Reg_3.3V

MCU RESET

13

24

SW800PTS645SL50SMTR92 LFS

GND

1

3

5

7

9

2

4

6

8

10

J1

STL21-0730 G TT-10U

VCC_Reg_3.3V

GND

RST

RST

JTAG Interface for MCU

WiFi_RESET

13

24


GND

WiFi_RESET

13

24


WiFi_GPIO_9

WiFi Factory Reset

VCC_Reg_3.3V

GND

AP_ASSOC_IND

TCP_OPEN_INDWiFi_TCP_OPEN

WiFi_AP_ASSOC

WiFi_TCP_Req TCP_Req_IND

8Ashray Manur

AP_ASSOC_IND

TCP_Req_IND

TCP_OPEN_IND

GND

LED Indicators for WiFi

Appliance Status Indicators

GND

STAT_RELAY_OFF

STAT_RELAY_ON

GND

STAT_RELAY_ON

STAT_RELAY_OFF

Indicators and Headers

GND

8REV.1

RELAY_ON_IND

RELAY_OFF_IND

VCC_Reg_3.3V

WiFi Reset

GND

GREEN_LED GREEN_LED_IND

GND

GREEN_LED_IND

GENERAL INDICATORS

C810.1µF

C804700pF

R80100k

R94

100k

R89

100k

R88

100k

R82

100kR83

100k

R84

100k

R8139

R97

240

R91

240

R90

240

R85

120

R87

120

R86

240

GRN (571nm)

1 2D80

YEL (587nm)

1 2D81

RED (631nm)

1 2D82

GRN (571nm)

1 2D87

RED (631nm)

1 2D83

GRN (571nm)

1 2D84

R98

10k

R99

10kGND

VC

C_R

eg_3.3V

R100

240RED (631nm)

12

D88

GND

PIC8001

PIC8002COC80

PIC8101

PIC8102

COC81

PID8001 PID8002

COD80

PID8101 PID8102

COD81

PID8201 PID8202

COD82

PID8301 PID8302

COD83

PID8401 PID8402

COD84

PID8701 PID8702

COD87

PID8801PID8802

COD88

PIJ101PIJ102

PIJ103PIJ104

PIJ105PIJ106

PIJ107PIJ108

PIJ109PIJ1010

COJ1

PIR8001

PIR8002COR80

PIR8101

PIR8102COR81

PIR8201 PIR8202

COR82

PIR8301 PIR8302

COR83

PIR8401 PIR8402

COR84

PIR8501 PIR8502

COR85

PIR8601 PIR8602

COR86

PIR8701 PIR8702

COR87

PIR8801 PIR8802

COR88

PIR8901 PIR8902

COR89

PIR9001 PIR9002

COR90

PIR9101 PIR9102

COR91

PIR9401 PIR9402

COR94

PIR9701 PIR9702

COR97

PIR9801 PIR9802

COR98PIR9901 PIR9902

COR99

PIR10001PIR10002

COR100

PISW80001 PISW80002

PISW80003 PISW80004COSW800 PISW80101 PISW80102

PISW80103 PISW80104

COSW801

PISW80201 PISW80202

PISW80203 PISW80204

COSW802

PID8002

PIR8201

NLAP0ASSOC0IND

PIC8002

PIC8102

PIJ102

PIJ1010

PIR8202

PIR8302

PIR8402

PIR8501

PIR8601

PIR8701

PIR8802

PIR8902

PIR9001

PIR9101

PIR9402

PIR9701

PIR9902

PIR10001

PISW80001 PISW80002

PISW80101 PISW80102

PID8702

PIR9401NLGREEN0LED0IND

PIJ101

PIJ109

PIJ103

PIJ105

PID8001PIR8502

PID8101PIR8602

PID8201PIR8702

PID8301PIR9002

PID8401PIR9102

PID8701PIR9702

PID8801PIR10002

PIJ107PIJ108

PIR8102

PISW80003 PISW80004

PIC8001

PIJ106

PIR8002PIR8101

NLRST

PID8402

PIR8901

NLSTAT0RELAY0OFF

PID8302

PIR8801

NLSTAT0RELAY0ON

PID8202

PIR8401

NLTCP0OPEN0IND

PID8102

PIR8301

NLTCP0Req0IND

PIC8101

PID8802

PIJ104

PIR8001

PIR9801

PISW80201 PISW80202NLVCC0Reg0303V

PIR9901

PISW80203 PISW80204PIR9802

PISW80103 PISW80104

1

1

2

2

3

3

4

4

D D

C C

B B

A A

Title

Number RevisionSize

A

Date: 12/1/2015 Sheet ofFile: C:\Users\..\MEM_Sch.SchDoc Drawn By:

PF2:ADC2:DIG2 1PF3:ADC3:DIG4 2PF4:ADC4:TCK 3PF5:ADC5:TMS 4PF6:ADC6:TDO 5PF7:ADC7:TDI 6

PF1:ADC1 64

PF0:ADC0 63

PB0:SSN:PCINT036

PB1:SCK:PCINT137

PB2:MOSI:PCINT238

PB3:MISO:PCINT339

PB4:OC2:PCINT440

PB5:OC1A:PCINT541

PB6:OC1B:PCINT642

PB7:OC0A:OC1C:PCINT743

PD0:SCL:INT025

PD1:SDA:INT126

PD2:RXD1:INT227

PD3:TXD1:INT328

PD4:ICP129

PD5:XCK130

PD6:T131

PD7:T032

PE0:RXD0:PDI:PCINT8 46PE1:TXD0:PDO 47PE2:XCK0:AIN0 48PE3:OC3A:AIN1 49PE4:OC3B:INT4 50PE5:OC3C:INT5 51PE6:T3:INT6 52PE7:ICP3:INT7:CLKO 53

PG0:DIG314

PG1:DIG115

PG2 / AMR16

PG3:TOSC217

PG4:TOSC118

PG5:OC0B19

DEVDD 23

DEVDD 34

DEVDD 44

DEVDD 54

DVSS 24

DVSS 35

DVSS 45

DVSS 55

AV

SS_R

FP7

RFP

8

RFN

9

AV

SS_R

FN10

AVSS 58

AVSS:ASVSS 61

EVDD 59AVDD 60

DVDD21

DVDD22

DVSS:DSVSS20

XTAL2 56XTAL1 57

AREF 62

CLKI33

Paddle 65

TST11

RSTN12

RSTON13

U100 ATmega256RFR2

SD_CS

SD_WRT_PROT

GND

Ashray Manur

VCC_MCU_3V3GND

GND

RST

GND

GND

GNDGND

GND

GNDGND

AREF

1

VCC_MCU_3V3

GND

UART_RX_1UART_TX_1

GND

GND

11

33

GND 2

GND 4

X1

16MHz

MCU_ATmega256rfr2

1 2

J100

MCU Current Measurement

VCC_Reg_3.3V

VCC_MCU_3V3

WiFi_TX0WiFi_RX0

WiFi_TCP_OPEN

WiFi_RESET

WiFi_AP_ASSOC

WiFi_TCP_Req

WiFi_SYS_Ready

MISO_MCUMOSI_MCU

SCK_MCU

SD_CS

SD_WRT_PROT

REV.1

ENERGY_RST

ENERGY_IRQ

ENERGY_CS

RTC_SCLRTC_SDA

Relay1_ON

Relay1_OFF

GND

GND

GND

DM_MCUDP_MCU

GNDGND

VBUS_MCU

DM_MCU

DP_MCU

VBUS_MCU

UART_RX_1UART_TX_1

Serial to USB setup for MCU

RFN RFP

DIG1DIG2

VBUS1

D-2

D+3

GND5

ID 6

U105

USB_micro_B

JTAG_TDIJTAG_TDOJTAG_TMSJTAG_TCK

RST

GREEN_LED

8

RELAY_ON_IND

RELAY_OFF_IND

INTA_RTC

C111

10pF

C112

10pFC1510pF

C1610pF

C110

1µF

C2310µF

C240.1µF

C110.1µF

C120.1µF

C130.1µF

C140.1µF

C17

0.1µF

C18

1µF

C19

0.1µF

R12

10k

R11

10k

X232.768kHz

VC

CIO

1

RXD 2

RI 3

GN

D4

DSR 6

DCD 7CTS 8

CBUS4 9

CBUS2 10

CBUS3 11

USBDP14

USBDM15

3V3OUT16

GN

D17

RESET18

VC

C19

GN

D20

CBUS1 21CBUS0 22

AG

ND

24

TEST26

OSCI27

OSCO28

TXD 30

DTR 31

RTS 32

GN

D33

U101IC_FT232RQ

VCC_MCU_3V3

12

J101

Relay2_OFF

Relay2_ON

1 23 4

FTDI_UART

Header 2X2

1/8 inch mounting hole

M1

Mount_Hole_0_125


M2

Mount_Hole_0_125


M3

Mount_Hole_0_125

PIC1101

PIC1102

COC11PIC1201

PIC1202

COC12PIC1301

PIC1302

COC13PIC1401

PIC1402

COC14

PIC1501

PIC1502COC15

PIC1601

PIC1602COC16

PIC1701 PIC1702

COC17

PIC1801 PIC1802

COC18

PIC1901 PIC1902

COC19

PIC2301

PIC2302

COC23PIC2401

PIC2402

COC24

PIC11001 PIC11002

COC110

PIC11101 PIC11102

COC111

PIC11201 PIC11202

COC112

PIFTDI0UART01 PIFTDI0UART02

PIFTDI0UART03 PIFTDI0UART04

COFTDI0UART

PIJ10001 PIJ10002

COJ100

PIJ10101

PIJ10102

COJ101

COM1

COM2

COM3

PIR1101 PIR1102

COR11

PIR1201 PIR1202

COR12

PIU10001

PIU10002

PIU10003

PIU10004

PIU10005

PIU10006

PIU10007PIU10008PIU10009PIU100010PIU100011

PIU100012

PIU100013

PIU100014

PIU100015

PIU100016

PIU100017

PIU100018

PIU100019

PIU100020

PIU100021

PIU100022

PIU100023

PIU100024

PIU100025

PIU100026

PIU100027

PIU100028

PIU100029

PIU100030

PIU100031

PIU100032

PIU100033

PIU100034

PIU100035

PIU100036

PIU100037

PIU100038

PIU100039

PIU100040

PIU100041

PIU100042

PIU100043

PIU100044

PIU100045

PIU100046

PIU100047

PIU100048

PIU100049

PIU100050

PIU100051

PIU100052

PIU100053

PIU100054

PIU100055

PIU100056

PIU100057

PIU100058

PIU100059

PIU100060

PIU100061

PIU100062

PIU100063

PIU100064

PIU100065

COU100

PIU10101PIU10102

PIU10103

PIU10104

PIU10106

PIU10107

PIU10108

PIU10109

PIU101010

PIU101011

PIU101014

PIU101015

PIU101016

PIU101017

PIU101018

PIU101019

PIU101020

PIU101021

PIU101022

PIU101024PIU101026

PIU101027

PIU101028

PIU101030

PIU101031

PIU101032

PIU101033

COU101

PIU10501

PIU10502

PIU10503

PIU10505

PIU10506

COU105

PIX101 PIX102

PIX103 PIX104

COX1PIX201

PIX202COX2

PIC1901

PIU100062

NLAREF

PIU100015

PIU10001

PIU101015

PIU10502NLDM0MCU

PIU101014

PIU10503NLDP0MCU

PIU100019

PIU100053

PIU100032

PIC1102 PIC1202 PIC1302 PIC1402

PIC1502PIC1601

PIC1702

PIC1802

PIC1902

PIC2302 PIC2402

PIC11001

PIC11101

PIC11201

PIR1101

PIR1201

PIU10007PIU100010

PIU100020

PIU100024

PIU100035

PIU100045

PIU100055

PIU100058

PIU100061

PIU100065

PIU10104

PIU10108

PIU101017 PIU101020PIU101024PIU101026

PIU101032

PIU101033

PIU10505

PIX102

PIX104

PIU100052

PIU100043

PIU10003

PIU10006

PIU10005

PIU10004

PIU100039

PIU100038

PIC1501

PIU100057

PIX101

PIC1602PIU100056

PIX103

PIC1801

PIU100060

PIC11002

PIU100021

PIU100022

PIC11102

PIU100016PIX202

PIC11202

PIU100017

PIX201

PIFTDI0UART01PIU101030

PIFTDI0UART03PIU10102

PIJ10101

PIU10101

PIR1102PIU100033

PIR1202

PIU100011

PIU10002

PIU100013

PIU100014

PIU100030

PIU10103

PIU10106

PIU10107

PIU10109

PIU101010

PIU101011

PIU101016

PIU101018

PIU101021

PIU101022

PIU101027

PIU101028

PIU101031

PIU10506

PIU100042

PIU100048

PIU100036

PIU100050

PIU100018

PIU100040

PIU10009 PIU10008PIU100012

NLRST

PIU100025

PIU100026

PIU100037

PIU100029NLSD0CS

PIU100031NLSD0WRT0PROT

PIFTDI0UART02

PIU100027

NLUART0RX01PIFTDI0UART04

PIU100028

NLUART0TX01

PIC2301 PIC2401

PIU101019

PIU10501NLVBUS0MCU

PIC1101 PIC1201 PIC1301 PIC1401

PIC1701

PIJ10002

PIJ10102

PIU100023

PIU100034

PIU100044

PIU100054

PIU100059

PIJ10001

PIU100063

PIU100051

PIU100046

PIU100041

PIU100049

PIU100064

PIU100047

1

1

2

2

3

3

4

4

D D

C C

B B

A A

Title

Number RevisionSize

A

Date: 12/1/2015 Sheet ofFile: C:\Users\..\power_supply.SchDoc Drawn By:

DC Power Supply

2Ashray Manur

Q100IRLML6402PBF

GNDGND

GND

1 2

J201

Total Current Measurement

Polarity Protection

3.3V Regulated

VCC_Reg_3.3V

REV.1

VCC_EXT_5V

GND

GNDGND

VBUS_DC_Power

Polarized

VBUS_DC_Power

DC Power Supply for Entire Board through USB mini-B wall adapter

GND

VBUS1

D-2

D+3

GND5

ID 6

U304

USB_micro_B

GND

8

3.3V

1 2

J202

Total Current Measurement5V

C2533µF

C260.1µF

C290.1µF

C2810µF

C270.47µF

VOUT 3G

ND

2

VIN1

U303

LM39

40_3

.3V

_1A

_LD

O

SW1

GN

D2

FB 3SHDN4 VIN

5

U305 Boost_LMR62421

GND

C2010µF

R2010k

R2210k

R21

30k

C2210µF

C21

1500pF

D20

MBRA210LT3G

L20

1.8 uH

12

J203

1 2

J204

+ 1

- 2

Battery200

3_AA_Holder

Boost_VIN Boost_VOUT

LDO_OUT

PIBattery20001

PIBattery20002

COBattery200

PIC2001

PIC2002

COC20

PIC2101 PIC2102

COC21

PIC2201

PIC2202

COC22

PIC2500COC25

PIC2601

PIC2602

COC26PIC2701

PIC2702

COC27

PIC2801

PIC2802COC28

PIC2901

PIC2902COC29

PID200A PID200K

COD20PIJ20101 PIJ20102

COJ201

PIJ20201 PIJ20202

COJ202

PIJ20301

PIJ20302

COJ203

PIJ20401 PIJ20402

COJ204

PIL2001 PIL2002

COL20

PIQ10001

PIQ10002

PIQ10003COQ100

PIR2001

PIR2002

COR20 PIR2101 PIR2102

COR21

PIR2201

PIR2202

COR22

PIU30301

PIU30302

PIU30303

COU303

PIU30401

PIU30402

PIU30403

PIU30405

PIU30406

COU304

PIU30501

PIU30502PIU30503PIU30504

PIU30505

COU305

PIC2001

PIJ20402PIL2001

PIR2001 PIU30505NLBoost0VIN

PIC2102

PIC2201

PID200K

PIJ20301

PIR2102

NLBoost0VOUT

PIBattery20002

PIC2002 PIC2202

PIC2500 PIC2602PIC2702

PIC2802 PIC2902

PIQ10002

PIR2202

PIU30302

PIU30405

PIU30502

PIC2500 PIC2601

PIJ20102

PIU30303NLLDO0OUT

PIBattery20001

PIJ20401

PIC2101

PIR2101

PIR2201

PIU30503

PID200APIL2002

PIU30501

PIJ20202PIQ10001

PIR2002PIU30504

PIU30402

PIU30403 PIU30406

PIC2801 PIC2901

PIJ20201

PIU30401

NLVBUS0DC0PowerPIC2701

PIJ20302

PIQ10003 PIU30301

PIJ20101

1

1

2

2

3

3

4

4

D D

C C

B B

A A

Title

Number RevisionSize

A

Date: 12/1/2015 Sheet ofFile: C:\Users\..\RTC.SchDoc Drawn By:

GND

GND

SQW

Ashray Manur

RTC_DS1337 and microSD

REV.14

MISO_MCU

MOSI_MCUSCK_MCU

SD_CS

GND

SD_WRT_PROT

Real Time Clock DS 1337

microSD

RTC_SCL

RTC_SDA

VCC_Reg_3.3V

GND GND

Coi

n C

ell B

atte

ry H

olde

r - 1

2mm

8

VCC_RTC

INTA_RTC

C4510µF

C430.1µF

R34.7k

R14.7k

R2

4.7k

X4

32.768kHz

VCC 8

SQW 7

SCL 6

SDA 5

X11

X22

INTA3

GND4

U401

RTC_1337

BT1CR1225

SHIELD2 GND2SHIELD1 GND1CD2 CD2CD1 CD1

RSV 8DO 7GND 6SCK 5VCC 4DI 3CS 2NC 1U400

microSD

1 23 45 67 8

SPI_HEADER

Header 4X2

VCC_Reg_3.3V

VCC_Reg_3.3V

VCC_Reg_3.3V

PIBT101

PIBT102COBT1

PIC4301

PIC4302COC43

PIC4501

PIC4502COC45

PIR101

PIR102COR1

PIR201PIR202

COR2

PIR301

PIR302COR3

PISPI0HEADER01 PISPI0HEADER02




COSPI0HEADER

PIU40001

PIU40002

PIU40003

PIU40004

PIU40005

PIU40006

PIU40007

PIU40008

PIU4000CD1

PIU4000CD2

PIU4000GND1

PIU4000GND2

COU400

PIU40101

PIU40102

PIU40103

PIU40104 PIU40105

PIU40106

PIU40107

PIU40108

COU401

PIX401PIX402

COX4 PIBT102

PIC4302 PIC4502

PIU40006

PIU4000GND1

PIU4000GND2

PIU40104

PIR301

PIU40103

PISPI0HEADER08

PISPI0HEADER04

PISPI0HEADER01

PIU40002

PISPI0HEADER03

PIU40003

PISPI0HEADER05

PIU40005

PISPI0HEADER07

PIU40007

PIU40001

PIU40008

PIU4000CD1

PIU40101

PIX401

PIU40102

PIX402

PIR202PIU40106

PIR102

PIU40105

PISPI0HEADER06

PISPI0HEADER02

PIU4000CD2

PIU40107NLSQW

PIC4301 PIC4501

PIR101

PIR201

PIR302

PIU40004

PIBT101

PIU40108

1

1

2

2

3

3

4

4

D D

C C

B B

A A

Title

Number RevisionSize

A

Date: 12/1/2015 Sheet ofFile: C:\Users\..\WiFi_RN131.SchDoc Drawn By:

3

WiFi System

Ashray Manur

G1

19

G2

36

G3

37

G4

38

G5

39

G6

40

G7

41

G8

42

G9

43

G10

44

3V3_IN 183V3_OUT 17

SUPCAP 8

DMA_TX 22DMA_RX 23

SENSPWR 33

SENS7 4SENS6 1SENS5 3SENS4 2SENS3 32SENS2 31SENS1 30SENS0 34

EPCB7 EPCA6

FORCE_WAKE9 RESET_L5

SPI_MISO14 SPI_CLK15 SPI_MISO16

GPIO924 GPIO825 GPIO726 GPIO627 GPIO528 GPIO429 GPIO_1310 GPIO_1211

URX12 UTX13

VD

_BA

T20

VD

_3V

_IN

21

U300 RN131_WiFi

VCC_Reg_3.3V

1 2

J300

WiFi_Current Measurement Header

WiFi_TX0WiFi_RX0

VCC_Reg_3.3V

GND

RESET_L

DRXDTX

DRX

DTX

TXDOUTRXDIN

TXDOUT

RXDIN

RESET_L

CTSINRTSOUT

CTSINRTSOUT

1 23 45 67 89 1011 12

J301

WiFi_Debug

WiFi_RESET

WiFi_SYS_Ready

WiFi_TCP_OPENWiFi_TCP_Req

WiFi_AP_ASSOC AP_ASSOC

TCP_OPEN

AP_ASSOC

TCP_OPEN

GND

GND

TCP_Req

CTSINRTSOUT

RXDIN_HEADERTXDOUT_HEADER

GND

DM

DP

DMDP

GND

VBUS

REV.1

Serial to USB setup for WiFi

GNDGND

VBUS VBUS1

D-2

D+3

GND5

ID 6

U302

USB_micro_B

GNDGND

WiFi_GPIO_9

8

C3310µF

C340.1µF

C3210µF

C310.1µF

R343.3kR353.3k

R363.3kR373.3k

VC

CIO

1

RXD 2

RI 3

GN

D4

DSR 6

DCD 7CTS 8

CBUS4 9

CBUS2 10

CBUS3 11

USBDP14

USBDM15

3V3OUT16

GN

D17

RESET18

VC

C19

GN

D20

CBUS1 21CBUS0 22A

GN

D24

TEST26

OSCI27

OSCO28

TXD 30

DTR 31

RTS 32

GN

D33

U301 IC_FT232RQ

1 23 4

J302

MCU_WiFi_UART_Header

1 23 4

J303

FT_WiFi_UART_Header

TXDOUTRXDIN

TXDOUT_HEADERRXDIN_HEADER

12

J304

3V3_WiFi

3V3_WiFi

PIC3101

PIC3102

COC31PIC3201

PIC3202

COC32

PIC3301

PIC3302COC33

PIC3401

PIC3402COC34PIJ30001 PIJ30002

COJ300

PIJ30101 PIJ30102

PIJ30103 PIJ30104

PIJ30105 PIJ30106

PIJ30107 PIJ30108

PIJ30109 PIJ301010

PIJ301011 PIJ301012

COJ301

PIJ30201 PIJ30202

PIJ30203 PIJ30204

COJ302

PIJ30301 PIJ30302

PIJ30303 PIJ30304

COJ303

PIJ30401

PIJ30402

COJ304

PIR3401 PIR3402COR34




PIU30001

PIU30002

PIU30003

PIU30004

PIU30005

PIU30006

PIU30007

PIU30008

PIU30009

PIU300010

PIU300011

PIU300012

PIU300013

PIU300014

PIU300015

PIU300016

PIU300017

PIU300018

PIU300019

PIU300020 PIU300021

PIU300022

PIU300023

PIU300024

PIU300025

PIU300026

PIU300027

PIU300028

PIU300029

PIU300030

PIU300031

PIU300032

PIU300033

PIU300034

PIU300036 PIU300037 PIU300038 PIU300039 PIU300040 PIU300041 PIU300042 PIU300043 PIU300044

COU300

PIU30101PIU30102

PIU30103

PIU30104

PIU30106

PIU30107

PIU30108

PIU30109

PIU301010

PIU301011

PIU301014

PIU301015

PIU301016

PIU301017

PIU301018

PIU301019

PIU301020

PIU301021

PIU301022

PIU301024PIU301026

PIU301027

PIU301028

PIU301030

PIU301031

PIU301032

PIU301033

COU301

PIU30201

PIU30202

PIU30203

PIU30205

PIU30206

COU302

PIC3301 PIC3401PIJ30002

PIJ30401

PIU300021NL3V30WiFi

PIJ30104

PIU300029

NLAP0ASSOC

PIJ30107

PIR3602

PIU300011

NLCTSINPIU301015

PIU30202NLDM

PIU301014

PIU30203NLDP

PIJ30102

PIU300023

NLDRX

PIJ30108

PIU300022

NLDTX

PIC3102PIC3202

PIC3302 PIC3402 PIJ301011 PIJ301012

PIU300019 PIU300036 PIU300037 PIU300038 PIU300039 PIU300040 PIU300041 PIU300042 PIU300043 PIU300044 PIU30104 PIU301017 PIU301020PIU301024PIU301026

PIU301033

PIU30205

PIJ30402

PIU30101PIR3401PIU301030

PIR3501PIU30102

PIR3601PIU301032

PIR3701PIU30108

PIU30001

PIU30002

PIU30003

PIU30004

PIU30006

PIU30007

PIU30008

PIU30009

PIU300014

PIU300015

PIU300016

PIU300017

PIU300018

PIU300020

PIU300025

PIU300026

PIU300030

PIU300031

PIU300032

PIU300033

PIU300034

PIU30103

PIU30106

PIU30107

PIU30109

PIU301010

PIU301011

PIU301016

PIU301018

PIU301021

PIU301022

PIU301027

PIU301028

PIU301031

PIU30206

PIJ30105

PIU30005

NLRESET0LPIJ30106

PIR3702

PIU300010

NLRTSOUT

PIJ30109

PIJ30204 PIJ30303

PIU300012

NLRXDIN

PIJ30304

PIR3402NLRXDIN0HEADER

PIJ301010

PIU300027

NLTCP0OPEN

PIU300028NLTCP0Req

PIJ30103

PIJ30202 PIJ30301

PIU300013

NLTXDOUT

PIJ30302

PIR3502NLTXDOUT0HEADER

PIC3101PIC3201

PIU301019

PIU30201

NLVBUS

PIJ30001

PIJ30101

PIU300024

PIJ30201

PIJ30203

1

1

2

2

3

3

4

4

5

5

6

6

D D

C C

B B

A A

Title

Number RevisionSize

B

Date: 12/10/2015 Sheet ofFile: C:\Users\..\Interface.SchDoc Drawn By:

Pow

er In

put

NEM

A 5

-15P

- IEC

320

C13

AC Power Input

AC_N

AC_GAC_N

AC_G

255-2053-ND

NEG 1

VS 3

VOUT 4

SET6

RST5

Relay_1

AC_P_IN

AC_P_OUT1

AC_P_OUT1

D1 6G25 S24

S11

G12 D2 3

BSS138BKS,115Q610

GND

AC Power Output

NEMA 5-15PConnector

from Appliance

Relay and Interface Circuitry

Interface

Ashray Manur

REV.1

6Inpu

t 110

V A

C

Neutral

Phase

GND

GND

V2N_Sig

V2P_Sig

Input Voltage Attenuation and Filter Network

GND

Connection from Main board

VCC_3.3V_Reg

V_AC_P

AC_N

Panasonic Latching Relay

Cab

le

Pow

er In

put V_AC_P

AC_N

AC_G

U601 is default. U602 will be used if necessary.

Pow

er O

utpu

t

U6X0 is default. J6X0 will be used if necessary.

THIS IS A SEPARATE BOARD

Rel_1_OFFRel_1_ON

VCC_3.3V_Power

GNDGND

VCC_3.3V_Reg

Cle

ar la

bels

on

PCB

for

P, N

& G

Cle

ar la

bels

on P

CB

for

P, N

& G

8

GNDGND

12345

U501

3.5 MM Jack 5 pinGND

GND

V1P_Sig

V1N_Sig

CT

with

3.5

MM

Aud

io J

ack

Current Input from CT

GND

GND

Rel_1_ONRel_1_OFF

GND

External Relay Driver (if necessary)

Power Interface Board

C600.033µF

C610.033µF

C640.033µF

C650.033µF

C6210µF

C630.1µF

R60

1k

R61

1k

R616100

R617

100R618100k R619

100k

R6100.0

R611

0.0

R651k

R64

1k

R63

255k

R62

255k

D612

1N4148D611

1N4148

R61210

R61310

12

J602

1 2

J603

- 2

+ 1U605

CR8348_1000_CST

V1P_IN

V1N_IN

V1P_IN

V1N_IN

255-2053-ND

NEG 1

VS 3

VOUT 4

SET6

RST5

Relay_2

AC_P_IN

AC_P_OUT2

D1 6G25 S24

S11

G12 D2 3

BSS138BKS,115Q620

GNDVCC_3.3V_Reg

Panasonic Latching Relay

Rel_2_OFFRel_2_ON

GNDGND

R626100

R627

100R628100k R629

100k

R6200.0

R621

0.0

D622

1N4148D621

1N4148

Phase P

Neutral N

GND G

U601

IEC 320 C14 - male

1 1

2 2

3 3

U602

3_Pin_AC_Terminal

11

22

33

J610

3_Pin_AC_Terminal

11

22

33

J620

3_Pin_AC_Terminal

PhaseP

NeutralN

GNDG

U610

IEC 320 C14 - Female

PhaseP

NeutralN

GNDG

U620

IEC 320 C14 - Female

AC_G

AC_G

AC_N

AC_N

AC_N

AC_G

11

22

J604

2_Pin_AC_Terminal

1 1

2 2

J605

2_Pin_AC_Terminal

AC_P_IN

AC_P_OUT2

VCC_3.3V_PowerV2N_SigV2P_Sig

Rel_1_ONRel_1_OFF

V1P_SigV1N_Sig

Rel_2_OFFRel_2_ON

GND

GND

AC_P_OUT1

AC_P_OUT2

Rel_2_ONRel_2_OFF

GND

1 23 45 67 89 1011 1213 1415 1617 18

P699

Header 9X2

AC_P_IN

1 23 45 67 8

P601

Header 4X2

VCC_3.3V_Power

GND


M1

Mount_Hole_0_1251/8 inch mounting hole

M2

Mount_Hole_0_125


M4

Mount_Hole_0_1251/8 inch mounting hole

M3

Mount_Hole_0_125

12

J607

PIC6001

PIC6002

COC60

PIC6101

PIC6102COC61

PIC6201

PIC6202

COC62PIC6301

PIC6302

COC63

PIC6401

PIC6402

COC64

PIC6501

PIC6502COC65

PID6110A PID6110K

COD611

PID6120A PID6120K

COD612

PID6210A PID6210K

COD621

PID6220A PID6220K

COD622

PIJ60201PIJ60202

COJ602

PIJ60301 PIJ60302

COJ603

PIJ60401

PIJ60402

COJ604

PIJ60501

PIJ60502

COJ605

PIJ60701

PIJ60702

COJ607

PIJ61001

PIJ61002

PIJ61003

COJ610

PIJ62001

PIJ62002

PIJ62003

COJ620

COM1 COM2

COM3 COM4

PIP60101 PIP60102

PIP60103 PIP60104

PIP60105 PIP60106

PIP60107 PIP60108

COP601

PIP69901 PIP69902

PIP69903 PIP69904

PIP69905 PIP69906

PIP69907 PIP69908

PIP69909 PIP699010

PIP699011 PIP699012

PIP699013 PIP699014

PIP699015 PIP699016

PIP699017 PIP699018

COP699

PIQ61001PIQ61002 PIQ61003

PIQ61004PIQ61005 PIQ61006

COQ610

PIQ62001PIQ62002 PIQ62003

PIQ62004PIQ62005 PIQ62006

COQ620

PIR6001 PIR6002

COR60

PIR6101 PIR6102

COR61

PIR6201 PIR6202

COR62PIR6301 PIR6302

COR63

PIR6401 PIR6402

COR64

PIR6501

PIR6502COR65

PIR61001 PIR61002

COR610

PIR61101 PIR61102

COR611

PIR61201

PIR61202

COR612

PIR61301

PIR61302COR613

PIR61601 PIR61602

COR616

PIR61701 PIR61702

COR617

PIR61801

PIR61802COR618 PIR61901

PIR61902COR619

PIR62001 PIR62002

COR620

PIR62101 PIR62102

COR621

PIR62601 PIR62602

COR626

PIR62701 PIR62702

COR627

PIR62801

PIR62802COR628 PIR62901

PIR62902COR629

PIRelay0101

PIRelay0103

PIRelay0104

PIRelay0105

PIRelay0106

CORelay01

PIRelay0201

PIRelay0203

PIRelay0204

PIRelay0205

PIRelay0206

CORelay02

PIU50101

PIU50102

PIU50103

PIU50104

PIU50105

COU501

PIU6010G

PIU6010N

PIU6010P

COU601

PIU60201

PIU60202

PIU60203

COU602

PIU60501

PIU60502

COU605

PIU6100G

PIU6100N

PIU6100P

COU610

PIU6200G

PIU6200N

PIU6200P

COU620

PIJ61003

PIJ62003

PIR6401

PIU6010N

PIU60203

PIU6100N

PIU6200NNLAC0N

PIJ60501

PIR6201

PIRelay0103

PIRelay0203

NLAC0P0IN PIJ61001

PIRelay0104

PIU6100PNLAC0P0OUT1

PIJ62001

PIRelay0204

PIU6200PNLAC0P0OUT2

PIC6002

PIC6102

PIC6202 PIC6302PIC6402

PIC6502

PIJ61002

PIJ62002

PIP60105

PIP60107 PIP60108

PIP69902

PIP69904

PIP69906

PIP69908

PIP699010

PIP699012

PIP699014

PIP699016

PIP699018

PIQ61001 PIQ61004

PIQ62001 PIQ62004

PIR6502

PIR61202

PIR61302

PIR61802 PIR61902

PIR62802 PIR62902

PIU6010G

PIU60202

PIU6100G

PIU6200G

NLAC0G

PID6110A

PIR61002PIRelay0106

PID6120A

PIR61102PIRelay0105

PID6210A

PIR62002PIRelay0206

PID6220A

PIR62102PIRelay0205

PIJ60202PIU60502

PIJ60301PIU60501

PIJ60402 PIJ60502

PIJ60701

PIU50102

PIJ60702

PIU50104

PIQ61002PIR61702 PIQ61003PIR61101

PIQ61005PIR61602 PIQ61006PIR61001

PIQ62002PIR62702 PIQ62003PIR62101

PIQ62005PIR62602 PIQ62006PIR62001

PIR6202PIR6301

PIP60103

PIP699013

PIR61701

PIR61901

NLRel010OFF

PIP60101

PIP699011

PIR61601

PIR61801

NLRel010ON

PIP60104

PIP699017

PIR62701

PIR62901 NLRel020OFF

PIP60102

PIP699015

PIR62601

PIR62801 NLRel020ON

PIJ60201PIR6101PIR61301

PIU50103

PIU50105

NLV1N0IN

PIC6501

PIP69907

PIR6102

NLV1N0Sig

PIJ60302

PIR6001PIR61201PIU50101

NLV1P0IN

PIC6401

PIP69909

PIR6002

NLV1P0Sig

PIC6001

PIP69903

PIR6402

NLV2N0Sig

PIC6101

PIP69905

PIR6302

PIR6501

NLV2P0Sig

PIJ60401PIU6010P

PIU60201

NLV0AC0P

PIC6201 PIC6301

PID6110K

PID6120K

PID6210K

PID6220K

PIP60106

PIP69901

PIRelay0101

PIRelay0201

NLVCC0303V0Power

NLVCC0303V0Reg

Bibliography

[1] C. Marnay and G. Venkataramanan, “Microgrids in the evolving electricity gen-eration and delivery infrastructure,” in Power Engineering Society General Meeting,2006. IEEE, 2006, pp. 5 pp.–.

[2] B. Kuri and F. Li, “Valuing emissions from electricity towards a low carbon econ-omy,” in Power Engineering Society General Meeting, 2005. IEEE, June 2005, pp. 53–59 Vol. 1.

[3] R. H. Lasseter, “Microgrids,” in Power Engineering Society Winter Meeting, 2002.IEEE, vol. 1. IEEE, 2002, pp. 305–308.

[4] F. Katiraei, M. Iravani, and P. Lehn, “Micro-grid autonomous operation duringand subsequent to islanding process,” Power Delivery, IEEE Transactions on, vol. 20,no. 1, pp. 248–257, Jan 2005.

[5] S. V. Iyer, M. N. Belur, and M. C. Chandorkar, “A generalized computationalmethod to determine stability of a multi-inverter microgrid,” Power Electronics,IEEE Transactions on, vol. 25, no. 9, pp. 2420–2432, 2010.

[6] D. E. Olivares, A. Mehrizi-Sani, A. H. Etemadi, C. Canizares, R. Iravani, M. Kaz-erani, A. H. Hajimiragha, O. Gomis-Bellmunt, M. Saeedifard, R. Palma-Behnkeet al., “Trends in microgrid control,” Smart Grid, IEEE Transactions on, vol. 5, no. 4,pp. 1905–1919, 2014.

[7] X. Yu, A. M. Khambadkone, H. Wang, and S. T. S. Terence, “Control of parallel-connected power converters for low-voltage microgrid—part i: A hybrid controlarchitecture,” Power Electronics, IEEE Transactions on, vol. 25, no. 12, pp. 2962–2970,2010.

[8] J. Kim, J. Guerrero, P. Rodriguez, R. Teodorescu, and K. Nam, “Mode adaptivedroop control with virtual output impedances for an inverter-based flexible ac mi-crogrid,” Power Electronics, IEEE Transactions on, vol. 26, no. 3, pp. 689–701, March2011.

[9] M. B. Delghavi and A. Yazdani, “An adaptive feedforward compensation for sta-bility enhancement in droop-controlled inverter-based microgrids,” Power Deliv-ery, IEEE Transactions on, vol. 26, no. 3, pp. 1764–1773, 2011.

[10] A. Hajimiragha and M. Zadeh, “Research and development of a microgrid con-trol and monitoring system for the remote community of bella coola: Challenges,solutions, achievements and lessons learned,” in Smart Energy Grid Engineering(SEGE), 2013 IEEE International Conference on, Aug 2013, pp. 1–6.

[11] F. Ktiraei, R. Iravani, N. Hatziargyriou, and A. Dimeas, “Microgrids management-controls and operation aspects of microgrids,” IEEE Power Energy, vol. 6, no. 3, pp.54–65, 2008.

62

BIBLIOGRAPHY 63

[12] L. Siow, P. So, H. Gooi, F. Luo, C. Gajanayake, and Q. Vo, “Wi-fi based server inmicrogrid energy management system,” in TENCON 2009 - 2009 IEEE Region 10Conference, Jan 2009, pp. 1–5.

[13] R. Mao, H. Li, Y. Xu, and H. Li, “Wireless communication for controlling micro-grids: Co-simulation and performance evaluation,” in Power and Energy SocietyGeneral Meeting (PES), 2013 IEEE, July 2013, pp. 1–5.

[14] L. Li, H. Xiaoguang, C. Ke, and H. Ketai, “The applications of wifi-based wirelesssensor network in internet of things and smart grid,” in Industrial Electronics andApplications (ICIEA), 2011 6th IEEE Conference on, June 2011, pp. 789–793.

[15] V. Gungor, B. Lu, and G. Hancke, “Opportunities and challenges of wireless sensornetworks in smart grid,” Industrial Electronics, IEEE Transactions on, vol. 57, no. 10,pp. 3557–3564, Oct 2010.

[16] V. C. Gungor and G. P. Hancke, “Industrial wireless sensor networks: Challenges,design principles, and technical approaches,” Industrial Electronics, IEEE Transac-tions on, vol. 56, no. 10, pp. 4258–4265, 2009.

[17] D. Son, B. Krishnamachari, and J. Heidemann, “Experimental study ofconcurrent transmission in wireless sensor networks,” in Proceedings of the4th International Conference on Embedded Networked Sensor Systems, ser. SenSys’06. New York, NY, USA: ACM, 2006, pp. 237–250. [Online]. Available:http://doi.acm.org/10.1145/1182807.1182831

[18] J. Zhao and R. Govindan, “Understanding packet delivery performance in densewireless sensor networks,” in Proceedings of the 1st international conference on Em-bedded networked sensor systems. ACM, 2003, pp. 1–13.

[19] G. Zhou, T. He, J. Stankovic, T. Abdelzaher et al., “Rid: radio interference detectionin wireless sensor networks,” in INFOCOM 2005. 24th Annual Joint Conference of theIEEE Computer and Communications Societies. Proceedings IEEE, vol. 2. IEEE, 2005,pp. 891–901.

[20] M. Erol-Kantarci and H. T. Mouftah, “Wireless sensor networks for cost-efficientresidential energy management in the smart grid,” Smart Grid, IEEE Transactionson, vol. 2, no. 2, pp. 314–325, 2011.

[21] Y. Yang, F. Lambert, and D. Divan, “A survey on technologies for implementingsensor networks for power delivery systems,” in Power Engineering Society GeneralMeeting, 2007. IEEE, June 2007, pp. 1–8.

[22] R. Leon, V. Vittal, and G. Manimaran, “Application of sensor network for secureelectric energy infrastructure,” Power Delivery, IEEE Transactions on, vol. 22, no. 2,pp. 1021–1028, April 2007.

[23] M. Erol-Kantarci and H. T. Mouftah, “Wireless multimedia sensor and actornetworks for the next generation power grid,” Ad Hoc Netw., vol. 9, no. 4, pp. 542–551, Jun. 2011. [Online]. Available: http://dx.doi.org/10.1016/j.adhoc.2010.08.005

[24] J. Pan, R. Jain, and S. Paul, “A survey of energy efficiency in buildings and micro-grids using networking technologies,” Communications Surveys & Tutorials, IEEE,vol. 16, no. 3, pp. 1709–1731, 2014.

http://doi.acm.org/10.1145/1182807.1182831

http://dx.doi.org/10.1016/j.adhoc.2010.08.005

BIBLIOGRAPHY 64

[25] J. Pan, R. Jain, P. Biswas, W. Wang, and S. Addepalli, “A framework for smartlocation-based automated energy controls in a green building testbed,” in Ener-gytech, 2012 IEEE, May 2012, pp. 1–6.

[26] Y. Simmhan, S. Aman, A. Kumbhare, R. Liu, S. Stevens, Q. Zhou, andV. Prasanna, “Cloud-based software platform for data-driven smart grid manage-ment,” IEEE/AIP Computing in Science and Engineering, 2013.

[27] S. Bera, S. Misra, and J. J. Rodrigues, “Cloud computing applications for smartgrid: A survey,” Parallel and Distributed Systems, IEEE Transactions on, vol. 26, no. 5,pp. 1477–1494, 2015.

[28] H. Kim, Y.-J. Kim, K. Yang, and M. Thottan, “Cloud-based demand response forsmart grid: Architecture and distributed algorithms,” in Smart Grid Communica-tions (SmartGridComm), 2011 IEEE International Conference on. IEEE, 2011, pp.398–403.

[29] L. Ji, W. Lifang, and Y. Li, “Cloud service based intelligent power monitoring andearly-warning system,” in Innovative Smart Grid Technologies-Asia (ISGT Asia), 2012IEEE. IEEE, 2012, pp. 1–4.

[30] C.-T. Yang, W.-S. Chen, K.-L. Huang, J.-C. Liu, W.-H. Hsu, and C.-H. Hsu, “Imple-mentation of smart power management and service system on cloud computing,”in Ubiquitous Intelligence Computing and 9th International Conference on AutonomicTrusted Computing (UIC/ATC), 2012 9th International Conference on, Sept 2012, pp.924–929.

[31] V. C. Gungor and F. C. Lambert, “A survey on communication networks for elec-tric system automation,” Computer Networks, vol. 50, no. 7, pp. 877–897, 2006.

[32] IEEE Standard for Information Technology Part 15.4: Wireless Medium Access Control(MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal AreaNetworks (LR-WPANs), IEEE Std 802.15.4, 2006.

[33] AVR2130: Lightweight mesh developer guide, Atmel Corpora-tion, 2014. [Online]. Available: http://www.atmel.com/Images/Atmel-42028-Lightweight-Mesh-Developer-Guide_Application-Note_AVR2130.pdf,

[34] V. Cervenka, L. Mraz, and D. Komosny, “Comprehensive performance analysis oflightweight mesh and its comparison with zigbee pro technology,” Wireless Per-sonal Communications, vol. 78, no. 2, pp. 1527–1538, 2014.

[35] M. Armbrust, O. Fox, R. Griffith, A. D. Joseph, Y. Katz, A. Konwinski, G. Lee,D. Patterson, A. Rabkin, I. Stoica et al., “M.: Above the clouds: a berkeley view ofcloud computing,” 2009.

[36] https://nodejs.org/en/, [Online; accessed 30-November-2015].

[37] S. Sundaresan, W. De Donato, N. Feamster, R. Teixeira, S. Crawford, andA. Pescapè, “Broadband internet performance: a view from the gateway,” in ACMSIGCOMM computer communication review, vol. 41, no. 4. ACM, 2011, pp. 134–145.

http://www.atmel.com/Images/Atmel-42028-Lightweight-Mesh-Developer-Guide_Application-Note_AVR2130.pdf,



https://nodejs.org/en/

BIBLIOGRAPHY 65

[38] R. Shea, F. Wang, H. Wang, and J. Liu, “A deep investigation into network per-formance in virtual machine based cloud environments,” in INFOCOM, 2014 Pro-ceedings IEEE. IEEE, 2014, pp. 1285–1293.

[39] S. K. Barker and P. Shenoy, “Empirical evaluation of latency-sensitive applicationperformance in the cloud,” in Proceedings of the first annual ACM SIGMM conferenceon Multimedia systems. ACM, 2010, pp. 35–46.

[40] J. C. Mogul, R. R. Kompella, and X. HotOS, “Inferring the network latency re-quirements of cloud tenants,” in 15th Workshop on Hot Topics in Operating Systems(HotOS XV). USENIX Association, 2015.

[41] S. Narayanan and A. Sivakumar, “Monitoring latency sensitive enterprise appli-cations on the cloud.”

[42] M. Yarvis, K. Papagiannaki, and W. S. Conner, “Characterization of 802.11 wirelessnetworks in the home,” in 1st workshop on Wireless Network Measurements (Winmee).Citeseer, 2005.

[43] K. Lakshminarayanan, S. Seshan, and P. Steenkiste, “Understanding 802.11 perfor-mance in heterogeneous environments,” in Proceedings of the 2nd ACM SIGCOMMworkshop on Home networks. ACM, 2011, pp. 43–48.

[44] R. Gummadi, D. Wetherall, B. Greenstein, and S. Seshan, “Understanding andmitigating the impact of rf interference on 802.11 networks,” ACM SIGCOMMComputer Communication Review, vol. 37, no. 4, pp. 385–396, 2007.

[45] A. Kamerman and N. Erkocevic, “Microwave oven interference on wireless lansoperating in the 2.4 ghz ism band,” in Personal, Indoor and Mobile Radio Communica-tions, 1997. Waves of the Year 2000. PIMRC’97., The 8th IEEE International Symposiumon, vol. 3. IEEE, 1997, pp. 1221–1227.

Documents

Microgrid Energy Management System - CAE Usershomepages.cae.wisc.edu/~manur/MS_Research_AshrayManur.pdf · Microgrid Energy Management System by ... 1.1 Introduction ... 4 Microgrid