example applications : find rogue zones: thermal zones which are constantly heating / cooling....
TRANSCRIPT
Example applications :
• Find rogue zones: thermal zones which are constantly heating / cooling.
• Requires: Finding temp sensors and temp setpoints which are semantically related
• Inefficient Air Handling units : Air handling units which serve hot zones, and in the process over-cool other zones.
• Requires: Finding air handling unit, temp setpoints and temp sensors that are semantically related
Automatic collection of Building Metadata
Motivation Synthesis of Transformation Programs
1. Analytics and Control Applications written for buildings depends on quality of metadata.i. Semantic Relationships between sensors typically
not available for buildings.2. Metadata is
i. imprecise and hard-to-understand (e.g SODA1R465__ART).
ii. varies across vendors, and across deployments.3. Hard to write analytics and control applications that
scale across millions of sensor network deployments, without constant input and intervention of facilities manager.
4. Facilities managers often only people who understand the metadata.
Learn through the input-output example model, i.e
1. Ask an expert (e.g the facilities manager) to provide transformed metadata (Project Haystack) for a sensor.
2. Learn the metadata transformation rules, and then apply these rules to other sensors wherever applicable.
3. Ask for another example, and continue this process until most sensor metadata has been transformed / augmented.
Arka Bhattacharya, David Culler (UC Berkeley) Dezhi Hong, Kamin Whitehouse (University of Virginia), Jorge Ortiz (IBM Research)
Scalable Building Efficiency Applications UsingNormalized Metadata
Example Scalable Applications with Transformed Metadata & Future Work
Results on commercial building sensor networks
1. Transform/Augment existing sensor metadata to a common namespace through examples provided by an experti. Transformation also helps identifying semantic
relationships between sensors.2. Write applications against the common namespace
that can scale across these sensor deployments.
Fig. showing how many buildings learned-
metadata-keys were
applicable to, out of 60 buildings
Sensor networkin Building 1:
• Built in 1994• ~1600 sensorsvendor: Barrington
Sensor networkin Building 2:
• Built in 2009• ~2600 sensorsvendor: Siemens
Transformation LanguageChallenges:
Overall System Architecture
Example Rules formed:
For key zone air temp sensor:
If b1 then e1
b1 := Occurs(input, ‘ART’, 1)e1 := SubString(input, Constant(11), Constant(14) )
For key zoneRef:If b1 then e1
b1 := OccursAtPos(input, ‘R’, 5)e1 := SubString( input, Constant(6), PrecedeSucceed(ε, _, 1) )
Alternatives to automatically choose next sensor to present to the expert for manual parsing:1. Random: Choose random sensor.2. MaxRemaining:Choose sensor with maximum amount of metadata not yet transformed.3. SameRemaining: Choose sensor whose un-transformed metadata string occurs in most other sensors.
No delimiters to differentiate one key from anotherNot a regular languageNo a-priori knowledge of tokens.Inconsistent naming, different tokens mean same thing.Programs should not become erroneous as more and noisy examples are provided (convergence).
Problem : Approach:
Goal:
Results on 10 buildings:
Detailed Results for 1 building sensor network Ongoing Research Agenda:
• Making language more robust, and applying technique to
• geographically diverse buildings,• sensor networks commissioned by different
vendors, and • sensor networks in other contexts.
• Efficient data scraping from these (often) challenged primitive sensor networks and databases.
• Implementing active and passive data-driven approaches to complement the synthesis technique.
Related Work1. Project Haystack
2. Automated String Processing in Spreadsheets using Input-Output Examples, Sumit Gulwani, POPL 2011
Sample Web Report Generated
Sensor networkin Building 3:
• ~2500 sensors• 5 different schema• Technique used :
Random