Scalable Building Efficiency Applications Using
Normalizedof
Metadata
Automatic collection
Building Metadata
Arka Bhattacharya, David Culler (UC Berkeley) Dezhi Hong, Kamin Whitehouse (University of Virginia), Jorge Ortiz (IBM Research)
Synthesis of Transformation Programs
Motivation
Problem :
Approach:
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
model, i.e
the
input-output
example
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.
Metadata Keys
Primi ve Sensor Metadata
BLDA1R435_ _ART
Example
from
expert
MaxRemaining: % Keys Correctly Identified
Sensor network
in Building 1:
100
80
• Built in 1994
• ~1600 sensors
vendor: Barrington
60
40
% Sensors Fully qualified
SameRemaining: % Keys Correctly Identified
MaxRemaining:% Sensors fully qualified
20
Building expert
e.g Building Manager
Primi ve Sensor Metadata
Sensor network
in Building 3:
80
60
• ~2500 sensors
• 5 different
schema
• Technique used :
Random
40
20
0
15
20
25
30
35
40
45
Overall System Architecture
5
10
15
20
Number of examples
50
# Examples
25
BMS
Value/Indicator
SameRemaining: % Sensors fully qualified
SameRemaining: % Keys Correctly Identified
MaxRemaining: % Sensors fully qualified
MaxRemaining: % Keys Correctly Identified
Sensor network
in Building 2:
site
ahu
ahuRef
zone
zoneRef
Metadata
Format 1
BLD
A
5
R
577A
BMS
100
• Built in 2009
• ~2600 sensors
vendor: Siemens
Percent
80
60
40
80
60
40
Can correctly Iden fy and extract learned (keyvalue) pairs in other buildings
20
20
0
0
0
0
5
10
15
20
25
# Examples
30
35
40
45
50
Most frequent
20
40
60
80
100
120
Least frequent
Metadata Keys Learned in Building 1
(Keys ranked by frequency of Occurrence in Building 1 )
Driver
Boost
Metadata
Format 2
If b1 then e1
b1 := Occurs(input, ‘ART’, 1)
e1 := SubString(input, Constant(11), Constant(14) )
Common
Namespace
Metadata
Sensor Network 2
BMS
Portable
Analy cs
Apps
Driver
Boost
Metadata
Format 3
Common
Namespace
Metadata
Sensor Network 1
Results on 10 buildings:
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
Detailed Results for 1 building sensor network
30
Fig. showing
how many
buildings
learnedmetadata-keys
were
applicable to,
out of 60
buildings
Common
Namespace
Metadata
Sensor Network 3
Ongoing Research Agenda:
100
% True Positive Buildings
Random: % Keys Correctly Identified
Boost
(in common namespace)
•
Random : %Sensors fully qualified
Driver
Example Scalable Applications with Transformed Metadata
& Future Work
•
0
10
Metadata Keys
Example applications :
100
0
BLD ( c)
A ( c)
1 ( v)
R ( c)
435 ( v)
ART ( c)
For key zoneRef:
If b1 then e1
b1 := OccursAtPos(input, ‘R’, 5)
e1 := SubString( input, Constant(6), PrecedeSucceed(ε, _, 1) )
•
SameRemaining: %Sensors fully qualified
site
ahu
ahuRef
zone
zoneRef
zone air temp sensor
For key zone air temp sensor:
Ask for
another
example
to expert
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.
Random: % Keys Correctly Identified
Value/Indicator
(in common namespace)
Op mized Time Series Database
SYNTHESIS OF
TRANSFORMATION RULES
Results on commercial building sensor networks
Percent
Expert-provided Transforma on Example
(using transforma on programs learnt from example above)
Normalizing Existing
Sensor Metadata
To Common Format
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.
5
Example Rules formed:
Automated Transforma on :
Goal:
0
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).
BLDA5R577A _ARS
Random: %Sensors fully qualified
Transformation Language
Challenges:
•
•
Sample Web Report Generated
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