Reference Design for Residential Information...

September 15, 2009 PI: Professor David AuslanderGSR: Daniel Arnold

Slide 1 of 26

Reference Design for Residential Information Gateways

Present State of Reference Design and Alternatives


Slide 2 of 26

Presentation Outline

● Introduction● Gateway Overview● Current State of Gateway Reference Design● Works in Progress● Timeline


Slide 3 of 26

● Implement Residential Load Management● Function as the hub for the Home Energy

Management System (HEMS)● Educate/Involve Consumer in Home Energy

Management Process

Introduction

Why do we need a Residential Energy Gateway?


Slide 4 of 26

Introduction

● Phase 1: Develop a reference design which demonstrates technological, economical and social feasibility.

● Phase 2: Develop a working prototype and simulate/test Gateway functionality.

Gateway Project Overview:


Slide 5 of 26

Gateway Overview

● Communicate with an outside entity to determine the current and/or future cost of electricity and system status (normal, emergency, partial curtailment, etc.)

● Know from previous communication with the resident(s) how to prioritize various load usages against price, time-of-day, day-of-the-week, weather, etc.

● Communicate with an electric meter (either the revenue meter or a separate meter) to determine current whole-house electricity usage.

● Communicate with electrical loads (appliances) to control or suggest current and/or future operation.

● Communicate with loads to determine power usage.

● Display relevant information to residents.

● Accept input from residents to change (override) current operating conditions.

Essential Gateway Functions Include:


Slide 6 of 26

Gateway Overview

● Have all of the major components that a commercial gateway would need,

● Show that it operates and performs the energy management functions needed for "smart grid" concepts currently being developed,

● Run on a computationally modest enough platform to prove economic viability for a commercial product,

● Have strong modularity so various organizations can work independently,

● Demonstrate connectivity using several networking media,

● Provide for secure operation,

● Be field upgradeable for core software upgrades as well as addition of new modules,

● Provide flexibility for various user interface options.

Essential Gateway Requirements Include:


Slide 7 of 26

Gateway Functionality Overview

In order for this project to be a success, we must reconcile the desired Gateway functionality and requirements.


Slide 8 of 26

Gateway Functionality Overview

Gateway Command Heirarchy:

● Information (blue) can be exchanged between components on the same level or 1 level up or down.

● Commands (red), or requests for action can only be issued to components on a lower level.


Slide 9 of 26

Current State of Gateway Reference Design

Centralized vs. Distributed System

● Should the Gateway physically reside within a single device (such as a computer, or router-like device)?

● Should the Gateway reside within individual components of the Home Energy Management System (such as appliances and the advanced meter)?

● A distributed system could realize most, if not all, of the desired Gateway functionality.


Slide 10 of 26


The Advantages of a Centralized System:

● Optimization within the residence is a possibility.

● It is not necessary to require appliances to communicate with the outside world, individually. Doing so would be difficult as there is no guarantee that a single communication standard will emerge nationwide, this will increase the complexity for all appliances rather than just for the gateway.

● There is a central user (resident) interface, rather than having separate interfaces on each appliance. In this configuration, setting user preferences (how to respond to price changes, for example) does not require running around to all of the appliances and using a different user interface in each for that purpose.

● A single user interface would greatly increase user education possibilities, generally regarded as an important part of modern energy management.


Slide 11 of 26


As such, we feel that the incorporation of the Gateway into a fully or partially centralized device is of critical importance to the

success of this project.

The Advantages of a Centralized System:


Slide 12 of 26


Given the scope of this project and the 1 year timeline, constructing a fully functional Gateway prototype from scratch is not feasible, so we intend to select and modify consumer off the

shelf (COTS) products.


Slide 13 of 26


Gateway Hardware – Should the Gateway hardware be modeled after an internet router-like device, or developed on a PC?


Slide 14 of 26


Gateway Hardware – Which Model to Follow?

Advantages of Modeling the Gateway after an Internet Router

● Relatively inexpensive: $50 - $150 (so a Gateway with the same parts could eventually cost a similar amount)

● Commercially successful

● Could support different operating systems depending on embedded processor

● Physical characteristics suitable for mass production


Slide 15 of 26


Gateway Hardware – Which Model to Follow?

Disadvantages of Modeling the Gateway after an Internet Router

● Considerable internal complexity

● Very limited memory storage capacity

● Considerable effort required to construct prototype in this fashion (create PC board with processor, programming drivers, etc.)

● Access and support for modification of COTS internet router unavailable

● User interface is not clearly defined


Slide 16 of 26


Proposed Gateway Hardware – Netbook

Advantages

● Can support standard OS (windows, Linux, etc.)

● Price: $250 - $500, this price is suitable for development as a prototype

● User interface is clearly defined

● Can easily interface with external devices (WiFi, USB, Bluetooth, etc.)


Slide 17 of 26


Proposed Gateway Hardware – Netbook

Disadvantages

● Much less capable than a standard PC

● Price: $250 - $500, not suitable for mass production

● Limited memory storage (although has more than a router-like device)

Given the above factors, we recommend the adoption of a Netbook as the development platform for this project


Slide 18 of 26


Operating System:

● If mass quantities are produced, a royalty free OS would be a logical choice, such as Linux or freeBSD

● Cisco routers utilize VxWorks as an OS, widely available

● Netbooks can utilize Microsoft Windows or Linux

● Some communications protocols, such as ZigBee, may not be compatible with Linux

● Given this constraint, the application software should be written in a way that it is easily portable from one OS to another


Slide 19 of 26


Software Application Language:

● Compiler type languages: C, C++, C# and Java

● Scripting Language: PHP, Javascript, Python

● Scripting languages are easier to use, but lack the organization and execution efficiency of compiler-type languages

● Of the compiler languages, C++, C# and Java are object oriented (OO)

● C++ probably has the most efficient execution and smallest footprint, although Java is the most portable

Recommendation: Java, for the factors listed above and the presence of a large developer's community and widely available packages for mathematics, GUIs and networking.


Slide 20 of 26


Software Framework: OSGi

● Writing the application software completely from scratch is not feasible given the time constraints on this project.

● OSGi is a software framework which supports a dynamic module system for Java

● Software originally intended for home automation market

● Software framework is incorporated into reliable IDEs, which includes support for creating OSGi bundles

● OSGi supports a run-time environment in which bundles can be installed, uninstalled, etc. independently of one another

● OSGi bundles are created using a relatively simple Java interface

● OSGi software framework is widely (but not fully) supported in various industries (a full list is available here: http://www.osgi.org/About/Members)


Slide 21 of 26


Our work with OSGi:

● OSGi framework currently implemented by Eclipse Equinox, Apache Felix, and Knopflerfish

● We began investigating the Eclipse Equinox OSGi implementation as Equinox comes built-in to the Eclipse IDE (widely available and used)

● Successfully created OSGi bundles utilizing Eclipse Equinox IDE

● Successfully installed, launched, linked OSGi bundles in the OSGi run-time environment (contained in Eclipse IDE)

● Successfully launched OSGi run-time server independently of Eclipse and installed, launched OSGi bundles in this environment


Slide 22 of 26


Upcoming Plans for OSGi:

● Continue to experiment with Eclipse Equinox OSGi implementation:

● Install, link, and execute several dependent bundles within OSGi run-time server (outside of Eclipse)

● Investigate portability of OSGi framework into other IDEs (NetBeans)

● Evaluate other implementations of OSGi (Apache Felix and Knopflerfish)

● Make final determination as to whether or not OSGi framework should be incorporated into Gateway reference design


Slide 23 of 26


Communication Protocols

● Perhaps the most sensitive part of the project, as all interested parties will need to adopt uniform communication protocols to communicate with the Gateway

● Possible communications protocols include: Ethernet, WiFi, IEEE 802.15.4 (ZigBee), Pager, Cellular networks, radio frequency communications.

● ZigBee is possibly the best-known standard built on IEEE 802.15.4

● PG&E,SDG&E and SCE have claimed that their AMI meters will support communications based on ZigBee

● Although ZigBee adoption could be difficult considering membership and licensing fees

● Currently PG&E AMI meters support 2 way RF comms

● Given the need to gather internet based information, the Gateway must include standard internet (and probably wireless) communications


Slide 24 of 26

Works in Progress

Near Term:● Wrap up evaluation of OSGi, make final determination as to whether to incorporate

this framework into the Gateway

● If OSGi framework is chosen, determine if/how a user interface can be implemented. Perhaps a web-server could be run through OSGi?

● Look into data security issues with OSGi

● Develop test bed to interact with Gateway and test behaviors

● Gather/Create scenarios (use cases) to test the Gateway

Longer Term:


Slide 25 of 26

Works in Progress

Reference Design Test Bed

● In addition to the Gateway prototype, a reference design test bed will be constructed

● The test bed is the demonstration facility to show the Gateway is functioning properly

● It will be capable of exercising the gateway in many different scenarios with the capability to document behavior and test for correct behavior, automatically, where possible

● The initial test bed will be fully simulated

● Following this, hardware in the loop tests will take place


Slide 26 of 26

Timeline

Phase 1 Deliverables:

● PPT Slides of Present State of Reference Design and Alternatives: Sept. 15, 2009, COMPLETE

● PPT Slides of Conceptual Framework for Reference Design: Dec. 30, 2009

● Final Report of Conceptual Framework for Reference Design: Dec. 30, 2009

● Plan and Budget for Phase II: Dec. 30, 2009

Reference Design for Residential Information...

Documents

Transcript of Reference Design for Residential Information...