November 23rd

November 23rd Interactive Dashboard for a Greener built environment

2009

The goal of this “Interactive Energy consumption Dashboard” is to increase awareness of energy consumption and to suggest intelligent ways to make incremental improvements to conserve energy. The proposed Dashboard will help the masses visualize excessive consumption of electricity, water, gas and consumable resources on a regular frequency and help them make intelligent choices in usage.

Terry Fernandez

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

Table of Contents 1

Vision .......................................................................................................................... 5 1.1 Introduction .......................................................................................................... 5 1.2 Positioning............................................................................................................ 5 1.3 Problem Statement ............................................................................................... 7 1.4 Product Position Statement .................................................................................. 7 1.6 Stakeholder Descriptions...................................................................................... 8 1.6.1 Stakeholder Summary ................................................................................... 8 1.7 User Environment ................................................................................................ 8 1.8 Product Overview ................................................................................................. 9 1.8.1 Needs and Features ....................................................................................... 9 1.9 Scope Definition ................................................................................................... 9 1.9.1 Critical Feature Boundaries .......................................................................... 9 1.10 Other Product Requirements .......................................................................... 10 2 Use-Case Identification & Prioritization .................................................................. 11 2.1 Use-case name: UC1: Dashboard to visualize Electrical usage ......................... 11 2.1.1 Actor Brief Descriptions ............................................................................. 11 2.1.2 Event Flow .................................................................................................. 11 2.1.3 Priority Rationale ........................................................................................ 11 2.2 Use-case name: UC2: Dashboard to interact and modify Energy usage............ 11 2.2.1 Actor Brief Descriptions ............................................................................. 12 2.2.2 Event Flow .................................................................................................. 12 2.2.3 Priority Rationale ........................................................................................ 12 2.3 Use-case name: UC3: Dashboard to visualize Water usage .............................. 12 2.3.1 Actor Brief Descriptions ............................................................................. 12 2.3.2 Event Flow .................................................................................................. 13 2.3.3 Priority Rationale ........................................................................................ 13 2.4 Use-Case Diagram.............................................................................................. 13 2.5 Use-Case: UC1: Dashboard to visualize Electrical usage .................................. 15 2.5.1 Brief Description ......................................................................................... 15 2.5.2 Actor Brief Descriptions ............................................................................. 15 2.5.3 Event Flow .................................................................................................. 15 2.5.4 Alternate Event Flows................................................................................. 16 2.5.5 Alternate flow 1 .......................................................................................... 16 2.5.6 Results ......................................................................................................... 16 2.5.7 Post conditions ............................................................................................ 16 2.5.8 Post-condition 1 .......................................................................................... 16 2.6 Use-Case: UC2: Dashboard to interact and modify Energy usage .................... 16 2.6.1 Brief Description ......................................................................................... 16 2.6.2 Actor Brief Descriptions ............................................................................. 16 2.6.3 Event Flow .................................................................................................. 17 Page 2 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

2.6.4 Alternate Event Flows................................................................................. 17 2.6.5 Alternate flow 1 .......................................................................................... 17 2.6.6 Results ......................................................................................................... 17 2.6.7 Post conditions ............................................................................................ 17 2.6.8 Post-condition 1 .......................................................................................... 17 2.6.9 Post-condition 2 .......................................................................................... 17 2.7 Use-Case: UC3: Dashboard to visualize Water usage ....................................... 17 2.7.1 Brief Description ......................................................................................... 17 2.7.2 Actor Brief Descriptions ............................................................................. 17 2.7.3 Event Flow .................................................................................................. 18 2.7.4 Alternate Event Flows................................................................................. 18 2.7.5 Alternate flow 1 .......................................................................................... 18 2.7.6 Results ......................................................................................................... 18 2.7.7 Post conditions ............................................................................................ 18 2.7.8 Post-condition 1 .......................................................................................... 18 3 Domain Model .......................................................................................................... 20 3.1 Domain Model Diagram..................................................................................... 20 3.2 Domain Model Glossary .................................................................................... 21 4 System-Wide Functional Requirements ................................................................... 22 4.1 Introduction - System-Wide Functional Requirements ...................................... 22 4.2 System-Wide Functional Requirements ............................................................. 22 4.3 System Qualities (Quality Attributes) ................................................................ 23 4.3.1 Usability ...................................................................................................... 23 4.3.2 Reliability (Availability) ............................................................................. 23 4.3.3 Performance ................................................................................................ 23 4.3.4 Supportability (Modifiability) ..................................................................... 23 4.3.5 Security ....................................................................................................... 23 4.4 Interfaces to External Systems or Devices ......................................................... 23 4.4.1 Software Interfaces ..................................................................................... 24 4.4.2 Hardware Interfaces .................................................................................... 24 4.4.3 Communications Interfaces ........................................................................ 25 4.5 System Constraints ............................................................................................. 25 4.6 System Compliance ............................................................................................ 26 4.7 Licensing Requirements ..................................................................................... 27 4.8 Legal, Copyright, and Other Notices ................................................................. 27 4.9 Applicable Standards.......................................................................................... 27 5 Design Scenario ........................................................................................................ 28 5.1 Design Step ........................................................................................................ 28 5.2 Content Display multiple source use case .......................................................... 28 5.3 Design Scenario steps (Step 5 in event flow above detailed) ............................ 29 5.4 CRC Cards.......................................................................................................... 29 5.4.1 Refining the retrieval responsibilities ......................................................... 29 5.4.2 CRC cards for abstractions ......................................................................... 30 5.5 Sequence Diagram showing retrieval of usage/efficiency data by appliance and display of data ............................................................................................................... 31 Page 3 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

5.6 Sequence diagram Glossary ............................................................................... 31 Design Class Diagram............................................................................................... 33 6.1 Design Class Diagram Glossary......................................................................... 33 7 Conclusion ................................................................................................................ 35 7.1 Plan of action...................................................................................................... 35 6

Page 4 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

1 Vision 1.1

Introduction The goal of this “Interactive Energy consumption Dashboard” is to increase awareness of energy consumption and suggest intelligent ways to make incremental improvements to conserve energy. This has a cumulative ripple effect in conserving energy, when spread over many it should lead to a significant impact on energy conservation. The proposed Dashboard will help the masses visualize the excessive consumption of electricity, water, gas and consumable resources on a regular frequency and help them make intelligent choices in usage. In a blog post labeled “Power to the People” Google outlined why it is important to watch our usage of electricity. The “Interactive Dashboard for a Greener Built Environment” plans to take this a few steps further by using this awareness model and applying it to increase awareness of how much energy we consume in our built environment. The Dashboard being proposed will tell the user how much is being used, where cuts can be made to get the biggest bang for the buck and how much an individual is using relative to the larger whole. The differentiation between Google’s dashboard and the proposed interactive dashboard is substantial owing to the comprehensive approach to visualizing all energy usage. Google today focuses solely on electricity and requires the smart grid as a prerequisite to be effective.

1.2

Positioning Imagine how hard it would be to stick to a budget in a store with no prices. Well, that's pretty much how we buy electricity and other utilities we use today. Your utility company sends you a bill at the end of the month with very few details. Most people don't know how much electricity their appliances use, where in the house they are wasting electricity, or how much the bill might go up during different seasons. But in a world where everyone had a detailed understanding of their home energy use, we could find all sorts of ways to save energy and lower electricity bills. In fact, studies show that access to home energy information results in savings between 5-15% on monthly electricity bills. It may not sound like much, but if half of America's households cut their energy demand by 10 percent, it would be the equivalent of taking eight million cars off the road.

Page 5 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

FIGURE 1: ELECTRICITY USAGE

If we apply the same model of awareness to other energy sources, such as water, gas and any consumable product that we use everyday, a small incremental saving at an individual level can amount to an enormous saving when translated to the masses.

FIGURE 2: WATER USAGE

The Dashboard therefore has great potential in helping us to conserve energy by making us aware of usage and waste.

Page 6 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

1.3

Problem Statement Individuals, lacking tools to visualize how much energy they consume every day, The community as a whole, in turn the entire population on this earth. Results in wasted energy resources, particularly non renewable resources that have a significant impact on sustaining life. An interactive Dashboard to help us become aware, an interactive dashboard that is affordable and pervasive, An interactive dashboard that shows us how we can conserve energy. An interactive dashboard for the masses.

The problem of affects

the impact of which is

a successful solution would be

1.4

Product Position Statement Why

How

The (competing product name)

That

Unlike Our Product

Because We the masses need to become consciously green, but to do so we the masses need tools, measurements and dashboards that help us make intelligent choices Alerting, performance monitoring and prediction are concepts used heavily in IT to help with availability and proactive maintenance. These concepts can be applied to help make the built environment greener. Google is working on the smart grid technology - see http://arstechnica.com/science/news/2009/02/googlewants-in-on-the-smart-grid.ars. Companies are already working on ways to do this for Electricity - see http://www.tendrilinc.com/consumers/products/vantage/ Focuses only on electricity which is only one part of the equation. However pervasiveness of these technologies is a far more significant challenge. Google is concentrating on dashboards for visualizing electricity, currently it is very expensive and therefore cannot be pervasive. The proposed “Interactive Dashboard for a Greener Built Environment”, concentrates on attacking the problem from multiple facets of energy consumption while focusing on ubiquitous technology available to the masses

Page 7 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

1.6

Stakeholder Descriptions

1.6.1

Stakeholder Summary

Name The Community

Description A group of people who make up the neighborhood or community or tenants of a building.

The Family

A significant unit within the community comprising of Parents and children

Individual

The single unit within the community

Responsibilities This community has a commitment to ensure that they as a group consume energy in a sustainable fashion for which this Dashboard has to be designed to easily maintainable. The community is also committed to ensuring that the system will be marketable and will monitor the projects progress and funding allocation. Each family has a commitment to ensure that they consume energy in a sustainable fashion for which this Dashboard will be designed. It will be easily maintainable and be ubiquitous. Each family unit also has at the responsibility to monitor the progress of the project funding and progress at each iteration Each individual has a commitment to ensure that consume energy in a sustainable fashion for which this Dashboard will be designed, so it is easily maintainable and ubiquitous. Each individual also has the responsibility to monitor the progress of the project, funding and will approve the deliverable and provide feedback

1.7 User Environment The user environment is comprised of individuals, families and the community as whole. The house hold or building is considered the smallest unit for implementation. The task cycle is a daily recurring activity, with the cumulative effect tabulated over days, months and years. It spans across the neighborhood, town, city, state, nation and the world. While consuming energy is a 24 hour task, the effort expended to monitor and tweak usage will become ubiquitous over time. Just like the speedometer in a car, this Dashboard aims to provide much needed feedback on energy use and waste. There is no comprehensive product that is in existence today. Google is working on a dashboard that is tied into the smart electrical grid, but the pre-requisite is the grid which the masses cannot afford. This Page 8 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

product will model itself on the dashboard features that Google has proposed which it is manufacturing in partnership with TED on a limited basis. Other products available are as follows:

1.8

Product Overview

1.8.1

Needs and Features Need

Priority

Features

Planned Release

Dashboard to monitor electrical usage

1

Visualize every day usage of electricity and suggest ways to conserve using artificial intelligence

11/24/2009

Dashboard to monitor water usage

2

Visualize every day usage of water and suggest ways to conserve using artificial intelligence

2/24/2010

Dashboard to monitor any consumable energy source

3

Visualize every day usage of consumable energy sources and suggest ways to conserve using artificial intelligence

5/24/2010

1.9

Scope Definition

1.9.1

Critical Feature Boundaries

Feature

Includes

Excludes

Dashboard to monitor daily household or building electrical energy usage

Simple easy to use web browser based Dashboard showing current usage, daily totals and suggested ways of conserving electricity. It should permit the user to interact and participate in the process. Aggregates data over households and buildings in a zone • Simple easy to use web browser based Dashboard showing current usage, daily totals and suggested

Expensive hardware implementation that will impede adoption by the masses.

Dashboard to monitor daily household or

Expensive hardware implementation that will impede adoption by the Page 9 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

building water usage

Dashboard to monitor daily household or building consumable energy usage

1.10

•

ways of conserving water. It should permit the user to interact and participate in the process. Aggregates data over households and buildings in a zone Simple easy to use web browser based Dashboard showing current usage, daily totals and suggested ways of conserving consumable energy sources. It should permit the user to interact and participate in the process. Aggregates data over households and buildings in a zone

masses.

Expensive hardware implementation that will impede adoption by the masses.

Other Product Requirements Requirement

Priority

Planned Release

Smart sensors to detect granular electrical usage.

1

2/24/2010

Smart sensors to detect granular Water usage

2

5/24/2010

Smart sensors to detect granular usage of consumable energy

3

8/24/2010

Page 10 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

2

Use-Case Identification & Prioritization

2.1

Use-case name: UC1: Dashboard to visualize Electrical usage

2.1.1

Actor Brief Descriptions

Actor 1: Joe Smith. Active member of a household could be a parent or an adult Actor 2: Program 1. Data mining computer algorithm that gathers data from external research Repositories and compares it to the usage in the household and makes intelligent suggestions. Actor 3: Program 2 - “State” storing computer algorithm takes input from Actor 1 and Actor 2 and develops a baseline based on automated discovery of appliances, input from Actor 1 and data gathered through Actor 2. 2.1.2

2.1.3

Event Flow 1. Use case begins when Actor 1, decides to monitor electrical usage with the intent making incremental improvements in energy use. The first step in the process is establishing a baseline. 2.

Actor 1 requests Actor 3 to start storing state of current usage based on discovery, input from the other Actors.

3.

Actor 1 requests a baseline of usage from Actor 3

4.

Actor 3 invokes data collection algorithm - an automated discovery process for a predetermined amount of time.

5.

Actor 3 invokes Actor 2 to collect usage and efficiency data from external repositories.

6.

Actor 3 requests Actor 1 to validate data on discovered devices and add/modify appliances and functional groupings.

7.

Actor 3 generates a preliminary validated baseline and displays it

8.

Actor 1 accepts the initial baseline

9.

Use case ends when Actor 3 displays the accepted baseline with the current usage overlay.

Priority Rationale

A baseline is the starting point. It is the first step in the process of incremental improvement. The primary goal for Use-case 1 is to establish a baseline of electrical usage from an automated discovery of appliances, data collection from various external sources on appropriate and efficient usage and human input/override.

2.2

Use-case name: UC2: Dashboard to interact and modify Energy Page 11 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

usage 2.2.1

Actor Brief Descriptions

Actor 1: Joe Smith. Active member of a household could be a parent or an adult . Actor 2: Program 1. Data mining computer algorithm that gathers data from external research Repositories and compares it to the usage in the household and makes intelligent suggestions. Actor 3: Program 2 - “State” storing computer algorithm takes input from Actor 1 and Actor 2 and interacts with appliances individually or on the functional groups created with the intent to improve efficiency of usage. Actor 4: Appliances – These are end devices and includes any electrical appliance that consumes power in the domain of interaction 2.2.2

2.2.3

Event Flow 1. Use case begins when Actor 1, decides to interact with current electrical usage with the intent making incremental improvements in energy use. The interaction is based on suggested improvements from Actor 3 who in turn interacts with Actor 2 and Actor 4. The first step in the process is modifying usage of individual or grouping of appliances. 2.

Actor 3 provides suggestions of interaction to Actor 1, to modify current usage of appliances or groupings of appliances

3.

Actor 1 validates the actions are acceptable

4.

Actor 3 interacts with Actor 4 consisting of appliances or groupings of appliances to modify pattern of usage based on the validation provided by Actor 1.

5.

Use case ends when Actor 3 displays the new baseline with the revised usage overlay.

Priority Rationale

To achieve incremental improvements, it is necessary to invoke a iterative process, where the feedback loop is engaged, based on which changes are implemented to achieve a desired level of efficiency. 2.3

Use-case name: UC3: Dashboard to visualize Water usage

2.3.1

Actor Brief Descriptions

Actor 1: Joe Smith. Active member of a household could be a parent or an adult Actor 2: Program 1. Data mining computer algorithm that gathers data from external research Repositories and compares it to the usage in the household and makes intelligent suggestions.

Page 12 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

Actor 3: Program 2 - “State” storing computer algorithm takes input from Actor 1 and Actor 2 and develops a baseline based on automated discovery of appliances, input from Actor 1 and data gathered through Actor 2. 2.3.2

2.3.3

Event Flow 1. Use case begins when Actor 1, decides to monitor water usage with the intent making incremental improvements in energy use. The first step in the process is establishing a baseline. 2.

Actor 1 requests Actor 3 to start storing state of current usage based on discovery, input from the other Actors.

3.

Actor 1 requests a baseline of usage from Actor 3

4.

Actor 3 invokes data collection algorithm - an automated discovery process for a predetermined amount of time.

5.

Actor 3 invokes Actor 2 to collect usage and efficiency data from external repositories.

6.

Actor 3 requests Actor 1 to validate data on discovered devices and add/modify appliances and functional groupings.

7.

Actor 3 generates a preliminary validated baseline and displays it

8.

Actor 1 accepts the initial baseline

9.

Use case ends when Actor 3 displays the accepted baseline with the current usage overlay.

Priority Rationale

A baseline is the starting point. It is the first step in the process of incremental improvement. The primary goal for Use-case 1 is to establish a baseline of electrical usage from an automated discovery of appliances, data collection from various external sources on appropriate and efficient usage and human input/override. 2.4

Use-Case Diagram 1. UC1, UC2 and UC3: Dashboard to visualize and interact with Energy usage. Note: This use case diagram illustrates usage of Electricity and Water. It can be further elaborated to display consumable energy dashboards discussed in the Vision document.

Page 13 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

Page 14 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

2.5

Use-Case: UC1: Dashboard to visualize Electrical usage

2.5.1

Brief Description

The Dashboard to visualize electrical usage is a software appliance that has a visual display providing Actor 1 statistics of current and historical usage of electricity. Usage is categorized by appliances and grouped by functions. Functional groupings of activities are related to Kitchen, Bathrooms, Living areas, utility areas, storage and external to the house are over laid to facilitate an organized approach to visualization and cognition. 2.5.2

Actor Brief Descriptions

Actor 1: Joe Smith Actor 2: Program 1 - Data mining algorithm Actor 3: Program 2 – Sensor Trigger The need to establish a baseline of current usage by appliance using taxonomy based on functional usage. Preconditions The household must use electricity to for lighting, power appliances and predominant functions in the household. Incoming Information (optional) See Event flow for inputs and outputs. Inputs are a combination of automated discovery of appliances within the domain, data mined from repositories available externally to the program and grouping information provided by Actor 1 defining the current environment. 2.5.3

Event Flow 1. Use case begins when Actor 1, decides to monitor electrical usage with the intent making incremental improvements in energy use. The first step in the process is establishing a baseline. 2.

Actor 1 activates Actor 3 to start storing state of current usage based on discovery, input from Actor 2

3.

Actor 1 requests a baseline of usage from Actor 3.

4.

Actor 3 invokes data collection algorithm - an automated discovery process for a predetermined amount of time.

5.

Actor 3 invokes Actor 2 to collect usage and efficiency data from external repositories.

6.

Actor 3 requests Actor 1 to validate data on discovered devices. The process includes a manual override - adding/modifying appliances and functional groupings.

7.

Actor 3 requests Actor 1, to validate suggested optimization parameters for appliances and or functional grouping of appliances.

8.

Actor 3 generates a preliminary baseline and displays it

9.

Actor 1 reviews and accepts the initial baseline

10. Use case ends when Actor 3 displays the accepted baseline with the current usage overlay.

Page 15 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

2.5.4 2.5.5

2.5.6

Alternate Event Flows Alternate flow 1 If in step 3.9.7 of the basic flow, Actor 1 does not accept the initial baseline, then 1.

Actor 1 modifies/overrides discovery information of appliances and functional grouping of appliances.

2.

The use case resumes at Flow step 3.9.6

Results

The result of UC1: Dashboard to visualize electrical usage, is a validated baseline, customized for the environment, based on data mined from external repositories and current usage patterns. 2.5.7 2.5.8

Post conditions Post-condition 1

UC2: Dashboard to interact and modify Electrical usage is a crucial post condition. This goal of achieving incremental improvements is rooted in iteration and the feedback loop. The ultimate goal is to use data mining to provide automatic usage optimization similar to what we see in routing algorithms prevalent today.

2.6

Use-Case: UC2: Dashboard to interact and modify Energy usage

2.6.1

Brief Description

The Dashboard to interact and modify energy usage is a module of the overall software appliance that has a visual display providing Actor 1 a user interface to provide feedback to the system. To achieve incremental improvements, it is necessary to invoke an iterative process, where the feedback loop is engaged, based on which changes are implemented to achieve a desired level of efficiency. 2.6.2

Actor Brief Descriptions

Actor 1: Joe Smith Actor 2: Program 1 - Data mining algorithm Actor 3: Program 2 – Sensor Actor 4: Appliances Trigger Once the base line in UC1 is established Actor 1 interacts with Actor 3 to revise usage of appliances or grouping of appliances.

Preconditions A baseline must be established and validated as specified in use-case UC1: Dashboard to visualize Electrical usage. A validated baseline, customized for the environment, based on data mined from external repositories and current usage patterns is critical to interact and modify electrical usage Incoming Information (optional) See Event flow for inputs and outputs. Inputs are a combination of automated discovery of appliances within the domain, data mined from repositories available externally to the program and grouping information provided by Actor 1 defining the current environment. Page 16 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

2.6.3

2.6.4 2.6.5

2.6.6

Event Flow 1. Use case begins when Actor 1 decides to interact with current energy usage with the intent making incremental improvements in energy use. The interaction is based on suggested improvements from Actor 3. The first step in the process is modifying usage of individual or grouping of appliances. 2.

Actor 3 provides suggestions of interaction to modify current usage of appliances or groupings of appliances based on the baseline established in UC1: Dashboard for visualizing electrical usage and UC3: Dashboard for visualizing Water usage.

3.

Actor 1 validates the actions are acceptable

4.

Actor 3 interacts with Actor 4. Consisting of appliances or groupings of appliances to modify pattern of usage based on the validation provided by Actor 1.

5.

Use case ends when Actor 3 displays the baseline with the revised usage overlay.

Alternate Event Flows Alternate flow 1 If in step 4.10.1 of the basic flow, Actor 1 does not accept the suggestions, then 1.

Actor 1 modifies/overrides the suggestions of interactions to modify current usage of appliances or functional grouping of appliances.

2.

The use case resumes at UC1: Dashboard to visualize electrical usage - Flow step 3.9.6

Results

The result of UC2: Dashboard to interact and modify electrical usage, is an incremental improvement process that uses iteration and a feedback loop, customized for the environment, based on data mined from external repositories and current usage patterns and validate by Actor 1. 2.6.7 2.6.8

Post conditions Post-condition 1

Periodic review and validation of overlay data of current usage over the baseline is a necessary post condition, since the goal of incremental improvement in electrical energy usage is rooted in iteration. 2.6.9

Post-condition 2

Periodic review and validation of overlay data of current usage as compared to that of other households in the neighborhood and communities is a necessary post condition. 2.7

Use-Case: UC3: Dashboard to visualize Water usage

2.7.1

Brief Description

The Dashboard to visualize Water usage is a software appliance that has a visual display providing Actor 1 statistics of current and historical usage of electricity. Usage is categorized by appliances and grouped by functions. Functional groupings of activities are related to Kitchen, Bathrooms, Living areas, utility areas, storage and external to the house are over laid to facilitate an organized approach to visualization and cognition. 2.7.2

Actor Brief Descriptions

Actor 1: Joe Smith Actor 2: Program 1 - Data mining algorithm Page 17 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

Actor 3: Program 2 – Sensor Trigger The need to establish a baseline of current usage by appliance using taxonomy based on functional usage. Preconditions The household must have running Water. Incoming Information (optional) See Event flow for inputs and outputs. Inputs are a combination of automated discovery of appliances within the domain, data mined from repositories available externally to the program and grouping information provided by Actor 1 defining the current environment. 2.7.3

Event Flow 1. Use case begins when Actor 1, decides to monitor Water usage with the intent making incremental improvements in energy use. The first step in the process is establishing a baseline. 2.

Actor 1 activates Actor 3 to start storing state of current usage based on discovery, input from Actor 2

3.

Actor 1 requests a baseline of usage from Actor 3.

4.

Actor 3 invokes data collection algorithm - an automated discovery process for a predetermined amount of time.

5.

Actor 3 invokes Actor 2 to collect usage and efficiency data from external repositories.

6.

Actor 3 requests Actor 1 to validate data on discovered devices. The process includes a manual override - adding/modifying appliances and functional groupings.

7.

Actor 3 requests Actor 1, to validate suggested optimization parameters for appliances and or functional grouping of appliances.

8.

Actor 3 generates a preliminary baseline and displays it

9.

Actor 1 reviews and accepts the initial baseline

10. Use case ends when Actor 3 displays the accepted baseline with the current usage overlay.

2.7.4 2.7.5

2.7.6

Alternate Event Flows Alternate flow 1 If in step 5.9.7 of the basic flow, Actor 1 does not accept the initial baseline, then 1.

Actor 1 modifies/overrides discovery information of appliances and functional grouping of appliances.

2.

The use case resumes at Flow step 5.9.6

Results

The result of UC3: Dashboard to visualize Water usage, is a validated baseline, customized for the environment, based on data mined from external repositories and current usage patterns. 2.7.7 2.7.8

Post conditions Post-condition 1

Page 18 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

UC2: Dashboard to interact and modify usage is a crucial post condition. This goal of achieving incremental improvements is rooted in iteration and the feedback loop. The ultimate goal is to use data mining to provide automatic usage optimization similar to what we see in routing algorithms prevalent today.

Page 19 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez Date: 11/23/2009

3 Domain Model 3.1

Domain Model Diagram

Page 20 of 35

3.2

Domain Model Glossary Appliances Appliances that trigger event data based on thresholds specified. Dashboard Catalog - Displays Events pertaining to energy usage in a visual display like a dashboard Data mining Engine External data repositories contains usage and efficiency data Events Events triggered by thresholds specified, based on data from “other computer systems external to the system”. People Roles of people: Heads of household that interact with the system by specifying thresholds and modifying usage Sensors Collect events and compare them to the mined data and suggest appropriate action.

Thresholds Rules and Policies: Thresholds suggested by external systems and validated by people interacting with the Catalog of events.

Interactive Dashboard for a Greener Built Environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

4 System-Wide Functional Requirements 4.1 Introduction - System-Wide Functional Requirements The Dashboard is an energy usage monitoring application that provides the user with information on how much energy the built environment consumes and or wastes in a frequency cycle. The Dashboard leverages information received from Commercial Off The Shelf “in-home energy management devices” and visualizes this information on interface similar to that of a smart phone. The system wide functional requirements described here emphasize the integration of the Dashboard with these COTS products by using a supply chain model of interaction to expose the interfaces and application programming interfaces (API’s) available on these COTS products. Measuring Waste as a way to improve consumption, security and Reporting are also considered in keeping with the FURPS+ model. 4.2

System-Wide Functional Requirements Requirements not explicitly outlined in the Use Cases will be augmented with the following requirements. True energy efficiency cannot be achieved if the system cannot assess waste in the usage of various energy sources. System security, reporting and auditing are other system wide requirements that will be considered in detail along with the interaction/integration with the COTS home energy monitoring and visualization devices. 1. Integration with Commercial off the shelf energy management devices by exposing the application interfaces. a. Google, Microsoft and other corporations are starting to develop products that measure and monitor energy consumption. The dashboard will integrate with these products by exposing the application interfaces and exchanging data using open XML standards and SOAP protocols. 2. Measuring and assessing waste of energy a. Measuring waste can be an effective way of controlling usage. The system wide functional requirements therefore will include measurement of wasted Electrical, Water, gas and other consumable energy sources 3. Security a. The dashboard will include functionality to control devices and the energy output. Since the relationship is one dashboard to many devices, security features will be included as part of the system-wide functional requirements. 4. Reporting and Auditing a. Reporting and Auditing are the essence of the Dashboard approach. It Page 22 of 35

Interactive Dashboard for a Greener Built Environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

is through a combination of reporting and auditing using artificial intelligence, that the user is presented with choices to manage usage and waste. Current usage is will be displayed by energy type using charts using variables of time and usage. The auditing features are arrived at using an overlay that comprises of historical data and data mined from repositories that provide efficient usage models. 4.3

System Qualities (Quality Attributes)

4.3.1

Usability

1. The user interface should be portable and available as an application on smart phones such as the iPhone, blackberry and the android platform. a. Usability considerations will include how to interact with the dashboard, which is largely through the keypad, how the dashboard interacts with the user, which is largely through the screen, the types of applications the device needs to support, which is largely a function of the device’s operating system and modules built specifically to serve the dashboard. 2. The user should be able to connect to and display the dashboard application remotely. 3. A user must access a usage display summary for a functional group or an individual device in less than 5 seconds while accessing at most two display pages 4.3.2

Reliability (Availability)

1. The application should be available 24x7, locally and remotely. It should include a feature to alert the user, if it becomes unavailable. 4.3.3

Performance

1. A request for usage summary must be full filled within 5 seconds during nonpeak periods and 10 seconds during peak periods 4.3.4

Supportability (Modifiability)

1. A new dashboard widget must be implemented in the system within 20 staffdays after a request has been received. The new widget must be deployed to users via an automatic update process and the update must require only an application restart, not a system reboot. 4.3.5

Security

1. When a third attempt to enter an invalid password has been detected for a particular userID, the userID must be blocked. System sends an alert to the address on record for that userID, requesting the user to contact User Accounts by phone 2. Authentication mechanisms should also include trusted device based authentication in lieu of the user ID/Password methods. 4.4 Interfaces to External Systems or Devices The “sensor” application component within the dashboard will tie into the COTS software/Hardware products that are currently available on the market to monitor energy usage. The “tie” method will use a combination of push and pull approaches to collect Page 23 of 35

Interactive Dashboard for a Greener Built Environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

data. The software and Hardware interfaces described below, illustrate these hardware/software based COTS products and their requirements. The “sensor” component is truly an application that connects to external databases to collect usage related efficiency data of various appliances in a built environment. These data repositories are located at vendor sites, universities and various government agencies. This data is then compared to the current usage. The interfaces to these external repositories are a critical design component. The format of data will be xml and the protocol used will be SOAP. 4.4.1

Software Interfaces

1. Commercial off the shelf energy monitor products that provide input into this dashboard will be included as part of the software interface design. The dashboard software interface will be designed to receive, analyze and display its input from the various Hardware interfaces described in section 4.2.

4.4.2

Hardware Interfaces

1. For each of the energy categories, simple “easy to use and integrate” off the shelf, hardware interfaces will be considered where possible. a. Electrical Energy sources. i. TED (The Energy Detective) is a simple, yet extremely accurate, home energy monitor that allow you to see electricity usage in real-time. This is an off the shelf module that is currently on the market that ties into the Smart Grid project initiated by Google. The TED 5000 from Energy Inc. is an energy monitor that measures electricity usage in real-time (TED stands for "The Energy Detective"). As of today, anyone in North America can purchase and install the TED 5000 and see personal home energy data using their free software tool, Google PowerMeter, from anywhere you can access the web including through iGoogle for mobile phones. This device will provide input into the proposed “Dashboard” and provide usage data. This data will then be combined with the inputs from the data mining engine.

Page 24 of 35

Interactive Dashboard for a Greener Built Environment Final Project Document

b.

c.

d.

4.4.3

Author: Terry Fernandez Date: 11/23/2009

Water as an energy source i. Similar to TED used in Electrical energy, a device is envisioned that will accurately monitor water usage for various appliances in the built environment. Natural gas as an energy source i. Similar to TED used in Electrical energy, a device is envisioned that will accurately monitor natural gas usage for various appliances in the built environment Other consumable energy sources i. By measuring the carbon foot print effectively, can provide better approaches to facilitate energy usage more efficient. Other consumable energy sources would contain, fuel used in transportation, and other intangible areas such as: food products that are shipped from other countries, goods manufactured with no energy constraints and similar intangible areas that increase the carbon footprint.

Communications Interfaces

1. The communication interfaces predominantly tie into the local area network either through wired Ethernet or wireless 802.11x protocols. The off the shelf electrical sensor, TED ties into the electrical system using specially designed clamps, which need to be installed. The TED device also includes a usb output port to facilitate a manual override. 4.5

System Constraints Constraints cover, software implementation language, prescribed use of development tools, third party components or class libraries, platform support, limitations and impacting size or hardware impacting the system. The predominant model to overcome system constraints uses a “Supply Chain” model that will tie into application program interfaces (API’s) that are exposed by the COTS products that will be integrated as part of the solution. 1.

Software implementation language and prescribed used of development tools.

a. Software implementation language and development tools will be open Object oriented languages and tools such as Java and Eclipse IDE. 2.

Platform support

a. Plat form support will be demarcated across the COTS components, Page 25 of 35

Interactive Dashboard for a Greener Built Environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

the Dashboard application components, the remote devices (smart phone type) the Dashboard will run on and Appliances. The dashboard application support will include the interfaces built, that interact with the COTS products, the external repositories and the Appliance interfaces. 3.

Limitations and impacting size or hardware impacting the system.

a. The Dashboard application must have the capability to run on a smart phone as an application. Similar to the applications that are available at application stores for the iPhone. This is in addition to the browser based application interface that can be displayed on desktops and laptops. b. The COTS hardware components must be small and unobtrusive, easy and simple to install without requiring skilled resources for installation. 4.6

System Compliance The Dashboard application will have indirect relationships with components that are “Public Utilities” in nature. Hence system compliance will be a critical component of system wide requirements. Where possible, this interaction will be limited to interfaces that the third party products will expose. However owing the nature of the domain: “Energy conservation” that has far reaching implications, there will be requirements that fall into the enforcement categories that will be considered. 1.

National institute of Standards and Technology

a. Home Energy Use and Conservation: NIST has been working on a variety of home energy use and conservation projects for many years. See summaries of past efforts to improve energy conservation in buildings and establish standards and tests for the energy efficiency of home appliances. b. Electricity: NIST helps the electric power and electric equipment industries use new cost-saving measurement technologies related to the transmission, distribution, and use of electric power. NIST products and services help firms cope with market trends, such as deregulation, which creates a demand for new diagnostic technologies to ensure the reliability of the complex infrastructure; and economic and environmental pressures that encourage greater efficiency in electrical devices. NIST also helps individual companies reduce their own electricity use and develop new technologies to improve the efficiency of electrical devices. c. Oil, Gas and Coal:NIST's measurement expertise helps to ensure that the many different elements of fossil fuel production systems fit together well, while national standards help to promote product quality. NIST also helps industry develop and apply technologies for oil and gas production and provides valuable data for research purposes. Page 26 of 35

Interactive Dashboard for a Greener Built Environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

4.7

Licensing Requirements The Dashboard is envisioned as a free energy usage monitoring tool that provides the user with information on how much energy the built environment is consuming. The dashboard receives information from COTS products such as Google Power meter, Microsoft’s Holm, and similar in-home energy management devices and visualizes this information for the user in an application interface that will run on your smart phone or a web browser on your desktop. The application will be licensed in the open source and public domains to encourage improvements from the world community at large. 1. Licensing. System must conform to the GNU General Public License and display the licensing notice at startup.

4.8

Legal, Copyright, and Other Notices The Dashboard is an opt-in service and users must sign up to participate. No personally identifying information will be shared between Dashboard and the user's utility and other external agencies. All energy data received by The Dashboard will be stored securely, and users will be able to delete their energy data or ask their utility agencies to stop sending data to The Dashboard at any time.

4.9

Applicable Standards The Dashboard product falls into a pervasive category where the goal is to encourage every human being to monitor energy usage with the intent of conservation. Owing to the “mass market” type impact of the application, the ISO standards in the areas of International standards for HCI and usability are being considered as applicable standards. These standards are related to usability and can be categorized as primarily concerned with the following areas. * the use of the product (effectiveness, efficiency and satisfaction in a particular context of use) * the user interface and interaction * the process used to develop the product * the capability of an organization to apply user centered design 1. Standards for usability: ISO 9241-11: Guidance on Usability (1998) ISO/IEC 9126: Software product evaluation - Quality characteristics and guidelines for their use (1991) ISO/IEC FDIS 9126-1 - 4: Software Engineering - Product quality ISO WD 20282: Usability of everyday products (2001) Other Standards: 2. Device communication protocol must conform to current IEEE Ethernet 802. 3 and Wireless standards 802.11xx and protocol standard in effect at the time of system deployment Page 27 of 35

Interactive Dashboard for a Greener Built Environment

Author: Terry Fernandez

Final Project Document

5

Date: 11/23/2009

Design Scenario

From an Architectural pattern perspective, this use case realization combines two patterns, Interactive systems and distributed systems. From a design pattern perspective the design scenario includes the components of the GRASP patterns such as the Creator, the Façade and Pure Fabrication. In this design scenario, a simplified version of Model View controller and Broker will be used to narrow our focus on a critical element of functionality taken from our Use case document. The process walks through a design scenario, CRC cards and the associated Sequence diagram. 5.1

Design Step Use Case 1 will be elaborated as a design scenario in this section. UC1: Dashboard to visualize Electrical usage. The Critical element in this use case is a Data Retrieval/Display scenario in event flow step 5 highlighted in the event flow below. Name: Display usage and efficiency data from multiple external repositories. The repositories include external data repositories that store efficiency data for various appliances that use electrical energy Description: Actor 1 (the user) engages Actor 3 to retrieve efficiency data by appliance. This is done by making a request to Actor 2 to collect usage and efficiency data from external repositories and display it Actors: Actor 1: Joe Smith. Active member of a household could be a parent or an adult Actor 2: Program 1. Data mining computer algorithm that gathers data from external research Repositories and compares it to the usage in the household and makes intelligent suggestions. Actor 3: Program 2 - “State” storing computer algorithm takes input from Actor 1 and Actor 2 and develops a baseline based on automated discovery of appliances, input from Actor 1 and data gathered through Actor 2 Preconditions: The system must be fully operational. The system must have network access to the supporting actors.

5.2

Content Display multiple source use case 1.

Use case begins when Actor 1, decides to monitor electrical usage with the intent making incremental improvements in energy use. The first step in the process is establishing a baseline.

2.

Actor 1 requests Actor 3 to start storing state of current usage based on discovery, input from the other Actors.

3.

Actor 1 requests a baseline of usage from Actor 3

4.

Actor 3 invokes data collection algorithm - an automated discovery process for a predetermined amount of time. Page 28 of 35

Interactive Dashboard for a Greener Built Environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

5. Actor 3 invokes Actor 2 to collect usage and efficiency data from external repositories.

5.3

6.

Actor 3 requests Actor 1 to validate data on discovered devices and add/modify appliances and functional groupings.

7.

Actor 3 generates a preliminary validated baseline and displays it

8.

Actor 1 accepts the initial baseline

9.

Use case ends when Actor 3 displays the accepted baseline with the current usage overlay.

Design Scenario steps (Step 5 in event flow above detailed) 1. The system retrieves usage/efficiency data items from various external repositories and displayed as narrated from the event flow step 5. 5.1 Responsibilities involved in retrieving Data • Contact/connect to the usage/efficiency repository source on the internet • Retrieve mined data from the repository 5.2 Responsibilities involved in displaying Data • Display the data on the page • Update data on the page • Handle additional user input requests from the page

5.4 CRC Cards 3 abstractions will be chosen in this design scenario and refined. The retrieval responsibilities will be the focus in this section and abstractions are further illustrated using CRC cards. 5.4.1 Refining the retrieval responsibilities The system retrieves the data items to be displayed from various information sources as narrated from the event flow step 5 of the event flow 5.1 Responsibilities involved in retrieving Usage/Efficiency data • Locate repository Source (New responsibility) • Contact/connect to the repository source • Retrieve mined data from source • The system displays the usage/efficiency retrieved. • 5.1.1 ABSTRACTIONS: The responsibilities will be assigned as follows: o Create a class, UDDIServer, to provide repository location information o Create a class, RetrievalAgent, that handles only repository connection and retrieval o Create a class, Server, that provides mined Data o Create a class, Document that will display retrieved Data o Create a class, Pane that will contain individual appliance data

Page 29 of 35

Interactive Dashboard for a Greener Built Environment Final Project Document 5.4.2

Author: Terry Fernandez Date: 11/23/2009

CRC cards for abstractions

Actor2 Responsibility Collaborators Initiates request to Retrieval Agent retrieve usage/Efficiency data Views results Document UDDIServer Responsibility Collaborators Provide Repository Retrieval Agent Location information Retrieval Agent Responsibility Collaborators Establish Repository Server Connection Retrieve mined Data Server Receives requests Actor2 Server Responsibility Collaborators Provide Retrieval Agent Usage/Efficiency Data by appliance Document Responsibility Collaborators Present retrieved Client usage/efficiency Data for all appliances

Responsibility Present retrieved usage/efficiency Data by appliance

Pane Collaborators Document

Page 30 of 35

Dashboards for a Greener built environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

5.5

Sequence Diagram showing retrieval of usage/efficiency data by appliance and display of data

5.6

Sequence diagram Glossary Actor 2 Program1. “Data mining computer algorithm” gathers data from external research repositories. Actor2 is a component of the Architectural pattern – Interactive Systems – Model View Controller

Actor 3 Program 2 - “State” storing computer algorithm takes input from Actor 1 and Actor 2 and develops a baseline based on automated discovery of appliances, input from Actor 1 and data gathered through Actor 2. Class Define invariant behavior independent of any instance. Behaves as a stand-alone procedure, e.g. static methods in Java CRC Cards Page 31 of 35

Dashboards for a Greener built environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

This is a Low-tech approach to documenting important elements of abstractions. Identify abstractions (class), Identify responsibilitiessuccinct, specific descriptions of the services provided by the abstraction, Identify collaborators-other abstractions needed to fulfill responsibilities Dashboard Catalog - Displays Events pertaining to energy usage in a visual display like a dashboard Data mining Engine External data repositories contains usage and efficiency data Document Content displayed on a page of display. MCD Mixed Content display – that follows the Model View Controller pattern Mined Data Content that is retrieved from external sources Pane Individual appliance data items retrieved into individual panes. Retrieval agent This is a “Pure fabrication” approach for creating loose coupling. This is the module that requests data from external sources. Within Architectural patterns this module is represented as a Broker, within the distributed systems category Repository location This is the location of repository of data sources. Location of servers on the internet Sensors Collect events and compare them to the mined data and suggest appropriate action. Server(s) External systems that are repositories of efficiency data, mostly mined from multiple sources. UDDIServer Catalog – stores information of various external repositories.

Page 32 of 35

Dashboards for a Greener built environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

6 Design Class Diagram

6.1

Design Class Diagram Glossary

Actor 2 Streotype – Component – Class that initiates requests. Represents Program1. “Data mining computer algorithm” gathers data from external research repositories. Actor2 is a component of the Architectural pattern – Interactive Systems – Model View Controller

ContentItemSpecification Item type that is being retrieved

Page 33 of 35

Dashboards for a Greener built environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

Document Container for Panes. Content displayed on a page of display. Pane Individual appliance data items retrieved into individual panes. Retrieval agent Class created and destroyed by the Pane. It runs in its own thread. This is a “Pure fabrication” approach for creating loose coupling. This is the module that requests data from external sources. Within Architectural patterns this module is represented as a Broker, within the distributed systems category Runnable This runs in its own thread. Has the sterotype of interface. Server(s) This class has a stereotype of component. External systems that are repositories of efficiency data, mostly mined from multiple sources. UDDIServer This class has a stereotype of component, it represents a Catalog of locations – stores information of various external repositories.

Page 34 of 35

Dashboards for a Greener built environment Final Project Document

Author: Terry Fernandez Date: 11/23/2009

7 Conclusion 7.1

Plan of action There are 5 major domains that require to be loosely coupled to make the dream of pervasive “Dashboards for a Greener built environment” a reality. They are summed up in the illustration below. In the end we need standards that drive appliance manufactures to provide instrumentation data that is available to the consumers. We need standards that drive creating of Data repositories that store efficiency data that will be freely available to consumers. We need standards for our built environment that makes adoption of energy conservation a reality.

Page 35 of 35