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