230 likes | 373 Views
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
E N D
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 • 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) • 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 SutardjaDai Hall
Recording spatial context • Building coordinate system (foot by foot) • Origin: Southwest corner of SDH Global Origin (3,0,0)
RAP Interface (356MN,8,8) • Android App • Easily used • Shallow learning curve (356MN,8,2)
StreamFS: Metadata organization Environment and Activity Structured, Traversable namespace Multiple building views /SodaHall /hvac /loadtree /spaces /xform /Chiller /CT /panel /floor4 /floor3 Electrical Load Tree Climate plant
StreamFS: Query system architecture GET /SDH/spaces/*?query=true&props_metertype=powermeter /inventory/mote123 { “metertype”:”powermeter”, “desc”:”Electric power meter”, “timestamp”: 1290500046 } /par /hum /temp /power PID2 PID1 PID3 PID4 GET ?query=true&ts_timestamp=gt:now-100,ls=now PID4 PID1 PID3 PID2 DB Time
Audit metadata organization /is4 /buildings /taxonomies LBNL Taxonomy /mels /SDH /other /Miscellaneous /qrc /inventory /spaces /Electronics . . . http://is4server.com:8080/is4/buildings/SDH/inventory
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 information http://is4server.com:8080/is4/buildings/SDH/inventory/LCD906
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 r-node {“desc”:”Acme” “timestamp”: …} s-node • Acyclic graph of namespaces for building views {“desc”:”Outlet” “timestamp”: …} { “desc”:”inventory inside SDH” “timestamp”: … } {“desc”:”Phone” “timestamp”: …} /inventory {“desc”:”Lamp” “timestamp”: …} /mote123 /SDH /power /hvac /loadtree /spaces /xform /Chiller /CT /panel /floor4 /floor3 /outlet /vent
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) r-node {“desc”:”Acme” “timestamp”: …} s-node • Using the metadata graph • Check match and path existence • /buildings/SDH/floor3/364/LCD/power (symlink) {“desc”:”Outlet” “timestamp”: …} { “desc”:”inventory inside SDH” “timestamp”: … } {“desc”:”Phone” “timestamp”: …} /inventory {“desc”:”Lamp” “timestamp”: …} /LCD /mote123 /SDH /power /hvac /loadtree /spaces /xform /Chiller /CT /panel /floor4 /floor3 /outlet /vent
Traditional RDBMS vsStreamFS • 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?