1. 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 Using Normalized 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 expert i.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 network in Building 1: Built in 1994 ~1600 sensors vendor: Barrington Sensor network in Building 2: Built in 2009 ~2600 sensors vendor: Siemens Transformation Language Challenges: Overall System Architecture Example Rules formed: For key zone air temp sensor: If b 1 then e 1 b 1 := Occurs(input, ‘ART’, 1) e 1 := SubString(input, Constant(11), Constant(14) ) For key zoneRef: If b 1 then e 1 b 1 := OccursAtPos(input, ‘R’, 5) e 1 := 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 another Not a regular language No 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 Work 1. Project Haystack 2. Automated String Processing in Spreadsheets using Input-Output Examples, Sumit Gulwani, POPL 2011 Sample Web Report Generated Sensor network in Building 3: ~2500 sensors 5 different schema Technique used : Random