View
63
Download
0
Category
Preview:
DESCRIPTION
Towards Live, continuous Building Energy Audits. Recording and Managing Building Plug-load Information Jorge Ortiz and Jason Trager LoCal Retreat June 1, 2011. Many miscellaneous loads. Plugs loads can account for almost the other 50% of energy spend in the building - PowerPoint PPT Presentation
Citation preview
TOWARDS LIVE, CONTINUOUS BUILDING ENERGY AUDITSRecording and Managing Building Plug-load Information
Jorge Ortiz and Jason Trager LoCal RetreatJune 1, 2011
Many miscellaneous loads Plugs loads can account for almost the other 50% of
energy spend in the building Opportunity for savings:
Plug loads may be controlled locally either by user of by demand-response signal
Metering and collecting this data takes long Many sources distributed throughout the building
Energy audits today Can range from simple building walk-through
to analysis of energy use (electric bill) Comparison made to similar buildings
Most sophisticated audits may use install metering and offline building modeling
Rapid Auditing Protocol (RAP)
4
Tag everything with a QR code Scan Device QR code (unique for each
device) Bind QR code with device/item Bind meters and devices
Record Device information Performed audit in Sutardja Dai Hall
Recording spatial context
Global Origin (3,0,0)
Building coordinate system (foot by foot) Origin: Southwest corner of SDH
6
RAP Interface Android App Easily used Shallow learning
curve
(356MN,8,2)
(356MN,8,8)
Environment and Activity
/SodaHall
/hvac/CT /Chiller
/loadtree/panel /xform
/spaces/floor3/floor4
Electrical Load TreeClimate plant
StreamFS: Metadata organization
7
Structured, Traversablenamespace
Multiple building views
StreamFS: Query system architecture
8
/inventory/mote123
DB
PID1
PID1
PID2
PID2
PID3
PID3
PID4
PID4
Tim
e
GET?query=true&ts_timestamp=gt:now-100,ls=now
GET/SDH/spaces/*?query=true&props_metertype=powermeter
{“metertype”:”powermeter”,“desc”:”Electric power meter”,“timestamp”: 1290500046}
/power /temp/hum/par
Audit metadata organization/is4
/buildings /taxonomies
/SDH
/qrc
/mels
/Electronics
.
.
.
/Miscellaneous/other/inventory /spaces
http://is4server.com:8080/is4/buildings/SDH/inventory
LBNL Taxonomy
Recorded Information Basic info
Power Usage, placement, device power draw or amperage rating, device make and model number
Device Type (taxonomy) Provided by LBNL
Extra informationhttp://is4server.com:8080/is4/buildings/SDH/inventory/LCD906
Initial Rapid Auditing Results
0
50
100
150
200
250
Device Count
Compu
ters
Electro
nic D
esks
Lamps
/Plug
Ligh
ts
Lase
r Prin
ters
LCD m
onito
rs
Notebo
ok C
ompu
ters
Phone
sIm
ac
Resist
ive Lo
ads
Microw
aves
Other
0
5000
10000
15000
20000
25000
30000
Device Power Draw In Watts: Total 65806.39 Watts
Type Computer
Electronic Desks
Lamp
Laser Printer
LCD Monitor
Notebook Computers
Phones
Imac Resistive Loads
Microwaves
Other
Count 90 94 29 49 214 54 51 22 16 7 104Power Use
12089 216 1600 558 11066 2565 76 2700 24149 5352 5434
RAP / StreamFS•Data pulled from StreamFS•Building Rooms Plotted• Static Power use
•Easily understood•Tap into people’s perceptions•Give estimations of energy use
Upcoming work Map to other building views (electrical, HVAC) Track deployment evolution Integrate live metering Tap into the “Weak Actuator” – People
Live alerts and visualizations Address Coverage
How many sensors are needed to capture energy picture?
Use audit to investigate DR Variations How is our scenario unique?
Tracking deployment evolution Metadata organization
Typically static, now live. Streaming data from meters
Items attached to those meters changes Meters move as well
Moved to new locations Attached to different items
How do we keep accurate view of where energy is going and how it is being consumed? Context-related queries:
One-off queries on current state Live queries that account for state transitions
Metadata graph Acyclic graph of namespaces for building
views
/SDH
/inventory
{“desc”:”inventory inside SDH”“timestamp”: …}
{“desc”:”Lamp”“timestamp”: …}
{“desc”:”Phone”“timestamp”: …}
{“desc”:”Outlet”“timestamp”: …}
{“desc”:”Acme”“timestamp”: …}
r-nodes-node
/hvac/CT /Chiller
/vent
/loadtree/panel /xform
/outlet
/spaces/floor3/floor4
/power/mote123
Typical subscription /buildings/SDH/floor3/364/LCD/power |
http://is4server.com/target.php String match on source data
Data POSTed to ‘/buildings/SDH/floor3/364/LCD/power’ tagged on entry
Tag used to match against subscriptions and pushed to matches
Dynamic subscription /buildings/SDH/floor3/364/* |
http://is4server.com/target.php Still a simple match of the wildcard
source string What about relevant data that whose
ingress tag does not match? i.e. If a mobile power meter is measuring
LCD in room 364 and it is placed in another folder (i.e. /inventory) Incoming data tag will not match wildcard
expression POST /inventory/meter
Dynamic subscription (2) Using the metadata graph Check match and path existence /buildings/SDH/floor3/364/LCD/power
(symlink)
/SDH
/inventory
{“desc”:”inventory inside SDH”“timestamp”: …}{“desc”:
”Lamp”“timestamp”: …}
{“desc”:”Phone”“timestamp”: …}
{“desc”:”Outlet”“timestamp”: …}
{“desc”:”Acme”“timestamp”: …}
r-nodes-node
/hvac/CT /Chiller
/vent
/loadtree/panel /xform
/outlet
/spaces/floor3/floor4
/power/mote123
/LCD
Traditional RDBMS vs StreamFS Dealing with static data
…but stuff moves around Must re-run query as changes happen
Distillation scope change over time The components accounted for changes with context Aggregate data changes in accounting w/evolution of
deployment Not just on/off, but there or not there
Push vs Pull Data pushed to external targets User may install static or dynamic subscriptions to
incoming data
Related work Traditional energy audits Auditing MELs
Recent LBNL study Items recorded by hand Live metering with ACme power meters
integrated with the deployoment sMAP + typical RDBMS (MySQL) and non
RDBMS (MongoDB) Data collection framework Taxonomy integration
Related work (2) Streaming queries and subscriptions
Pub-sub information bus Data items self describing and include topic for
consumers to subscribe to StreamFS uses pathname and item properties
as topics, but also account for inter-relationship through metadata graph
Unix FS + pipes Typical hierarchical namespace with symbolic
linking Pipe abstraction for subscription installation
Thanks Questions?
Extra
Recommended