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
© 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,
Chapter 1. Introduction 3
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).
Chapter 1. Introduction 4
FIGURE 1.2: Microgrid Energy Manager Architecture
Chapter 1. Introduction 5
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.
Chapter 2. Microgrid Energy Management: State of the Art 8
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.
Chapter 2. Microgrid Energy Management: State of the Art 9
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
Chapter 2. Microgrid Energy Management: State of the Art 10
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
Chapter 2. Microgrid Energy Management: State of the Art 11
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
Chapter 2. Microgrid Energy Management: State of the Art 12
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
Chapter 3. Microgrid Network (MN) 15
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.
Chapter 3. Microgrid Network (MN) 16
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
Chapter 3. Microgrid Network (MN) 17
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.
Chapter 3. Microgrid Network (MN) 18
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
Chapter 3. Microgrid Network (MN) 19
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
Chapter 3. Microgrid Network (MN) 20
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
Chapter 3. Microgrid Network (MN) 21
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
Chapter 3. Microgrid Network (MN) 22
FIGURE 3.14: MSN ACK handler
FIGURE 3.15: MSN response handler
Chapter 3. Microgrid Network (MN) 23
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.
Chapter 4. Microgrid Cloud 26
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
Chapter 4. Microgrid Cloud 27
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
Chapter 4. Microgrid Cloud 28
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.
Chapter 4. Microgrid Cloud 29
FIGURE 4.5: Setting up MEM grid
FIGURE 4.6: MEM heartbeat
Chapter 4. Microgrid Cloud 30
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
Chapter 5. Experiments and Results 33
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
Chapter 5. Experiments and Results 34
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
Chapter 5. Experiments and Results 35
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
Chapter 5. Experiments and Results 36
(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.
Chapter 5. Experiments and Results 37
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
Chapter 5. Experiments and Results 38
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
Chapter 5. Experiments and Results 39
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
Chapter 5. Experiments and Results 40
(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
Chapter 5. Experiments and Results 41
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
Chapter 5. Experiments and Results 42
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
Chapter 5. Experiments and Results 43
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
Chapter 5. Experiments and Results 44
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
Chapter 5. Experiments and Results 45
(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
Chapter 5. Experiments and Results 46
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.
Chapter 5. Experiments and Results 47
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.
Chapter 5. Experiments and Results 48
(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
Chapter 5. Experiments and Results 49
(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
Chapter 5. Experiments and Results 50
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
Chapter 5. Experiments and Results 51
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
SW801PTS645SL50SMTR92 LFS
GND
WiFi_RESET
13
24
SW802PTS645SL50SMTR92 LFS
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
1/8 inch mounting hole
M2
Mount_Hole_0_125
1/8 inch mounting hole
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
PISPI0HEADER03 PISPI0HEADER04
PISPI0HEADER05 PISPI0HEADER06
PISPI0HEADER07 PISPI0HEADER08
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
PIR3501 PIR3502COR35
PIR3601 PIR3602COR36
PIR3701 PIR3702COR37
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
1/8 inch mounting hole
M1
Mount_Hole_0_1251/8 inch mounting hole
M2
Mount_Hole_0_125
1/8 inch mounting hole
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.
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.
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.