manage google's own buildings digital buildings platform to · manage google's own...
TRANSCRIPT
Digital buildings Platform to manage Google's own buildings
LDAC 2020 8th Linked Data in Architecture and Construction Workshop (17-19 June 2020)
Charbel Kaed, Keith Berkoben
On behalf of the Digital Buildings team
Our story so far…
● Google is growing
● Several Buildings across the globe
● Due to different geographies
○ Different BMS vendors/Commissioning process
○ Different solutions providers across facilities
Facility Ops Manager OccupantLandlord
There are 3 main personas today in office buildings
Wasted energy Want to use less energy and spend less on it
Operational challenges
Ignored device alerts hide possible efficiencies
Occupant comfort & productivity
Hot/cold tickets and hours spent navigating buildings impede productivity
Cybersecurity Want a complete accounting and understandingof all connected devices
The Challenges
Today’s Building Systems
Today’s BMS’ and BAS’ are largely rule-based and have limited external data access
AV Energy Lighting Security BMS
AV Network
ENERGY Network
LightingControl
Network
CCTV Network
BMS Network
AV Data EnergyData
LightingControl
Data
CCTV Data
BMS Data
AV UI Energy UILightingControl
UICCTV UI BMS UI CAD /
CAFM
Real Estate data
Real Estate
High levelArchitecture
A data platform that aggregates and augments building IoT data for real operations usage.
Combines telemetry data with building ontology and spatial mapping to power positive change.
Devices
Network
Digital Buildings Platform
First & Third Parties ApplicationsSmart alerting, analytics dashboards, mapping
Data Lake
Building Ontology, Metadata
Spatial Mapping & Wayfinding
APIs
Connectivity & Ingestion
How do we make sense of data?When there is:
● Heterogeneity of devices & systems● Disparity of data in various silos● Need for data correlation across silos● Serve data to various applications and
personas
Ontology
● As a common vocabulary to refer to concepts in the building
● As a way to capture knowledge inside the Building domain (relations)
Ontology at a glance
● An Ontology: is a representation of domain concepts and relations that connect such concepts
● Ontologies are represented in triplets:(object, relation, object)
● Classes and Instances
● W3C Standards : RDF, OWL, JSON-LDParis France
isLocatedIn
City CountryisLocatedIn
isA isA
Ontology Example
Floor 1 Building 123isLocatedIn
Floor BuildingisLocatedIn
isA isA
isLocatedInMeetingRoom
Room 101
isA
isLocatedIn
Locationmeasures
SensorQuantity hasPhysicalLocation
Temperature SensorTemperature
Sensor 123
measures
Tempmeasures hasPhysicalLocation
Instance Class
isAisAisA
isAisA
What’s out there?
Existing consortia and standardization bodies tackling● IoT interoperability● Smart Buildings
HaystackVocabulary
Siemens Tagging Ontology
Brick Schema
1
2
3
● project-haystack.org
● Formed 2014
● Industry members: Siemens, Intel, LeGrand, KNX
● It is a Tag-based model, Not ontology
● Has its own non-standard syntax: Zinc instead of W3C
HayStack Vocabulary
● In 2015, Siemens points out the limitations of HayStack:
○ Lack of expressivity○ Ambiguity in assigning tags○ Need for abstraction in queries
● Proposes HTO proposes to mix:○ HayStack tags○ Semantic Sensor Network Ontology ○ Buildings Models: BIM, IFC
HayStack Tagging Ontology (HTO)
From Tags To Triples
● brickschema.org
● Proposed in 2016
● Takes into consideration: Haystack, HTO, and Saref
● Pragmatic approach refines the ontology based on a case study
● ASHRAE collaborative effort: BACnet, Haystack, and Brick Schema
● Brick schema guided our choice for ourDigital Buildings Platform
Brick Schema
The Digital Buildings Ontology Quick Overview
(HVAC focused)
The Digital Buildings Ontology● Designed with an HVAC subject matters expert● Exists in OWL/RDF and Yaml● Open sourced at: https://google.github.io/digitalbuildings/
● Main components:○ Subfields○ Fields○ [Equipment] types○ States○ Links○ Connections
Subfields
● Analogous to tags in BRICK or Haystack● Have very specific, well-defined definitions● Are grouped into subfield types, where each subfield belongs to only one type
○ Aggregation○ Descriptor○ Component○ Measurement Descriptor○ Measurement Type○ Point Type
● The set of subfields associated with a point make up its name.
Example subfields:
master: "Highest priority (or primary control) device, sensor, etc."makeup: "Process of adding (\"making-up\") water that has been lost due to blowdown or evaporation."medium: "Level of control or measurement; between high and low."
mixing: "Process of mixing substance."
Fields
max_heating_discharge_fan_differential_temperature_sensor
Aggregation (?) Descriptor (*) Component (?) Measurement Descriptor (?)
Measurement (?) Point Type ({1})
● Must contain a minimum of point type and one additional subfield
● Requires measurement type unless it can be unambiguously implied
● Have meaning derived from the combined meaning of included subfields
● Should be sufficiently detailed to explain the context of the measurement or control
○ zone_air_temperature_sensor > temperature_sensor● The majority of fields needed to describe building equipment
have already been defined <link to list>● MULTI-STATE values are defined for fields as well.
[Equipment] Types
● Represent clearly defined concepts (device or otherwise) or sets of functionality
● Define specific sets of 0 or more points associated with the concepts● Can be composed from individual fields as well as other types
SD: description: "Single duct attributes for VAV with basic airflow control." is_abstract: true uses: - supply_air_flowrate_sensor - supply_air_flowrate_setpoint ...
VAV_SD_DSP: description: "Simple, cooling-only VAV." is_canonical: true implements: - SD - VAV - DSP
VAV: description: "Tag for terminal units with variable volume control." is_abstract: true
DSP: description: "Dual setpoint control (heating/cooling thresholds with deadband in between)." is_abstract: true implements: ...
Connections (Object Properties)
AHU-001 FEEDS VAV-029
● Define important relationships between entities in the model○ Connectivity within an HVAC system○ Device locations○ Control between a switch and a light
● Current Relationships:○ CONTROLS: think "switch and light"○ HAS_PART: For grouping entities together into a more complex entity○ FEEDS: For media flow within a MEP system (air, water, current)○ HAS_RANGE: think "VAV to zone mapping"
Links
● Map a field from one entity to a different field in another entity. ● Use when the logical entity you need to represent doesn't strictly exist in the real system
○ You'll need this to make sure the Device Roles called out in the CAD drawing have all the correct points associated with them
_CTRL-1234: uses: - fan_run_status_1 - fan_run_status_2 - pump_run_status_1 - pump_run_status_2
CTRL-001: type: _CTRL-1234 has_link: FAN-001: fan_run_status_1:run_status
Demo
Devices
Network
Digital Buildings Platform
Data Lake
Building Ontology Metadata
Spatial Mapping & Wayfinding
APIs
Cloud IoT
Facilities Bot
Conclusion & Future Work
● A Digital Buildings Platform: Scalable and secured● Human readable and hand-editable yaml format is user friendly● Semantic Structured data with Brick-like tags● Ontology published on github: https://google.github.io/digitalbuildings/● A proven ontology validated on 130 of Google’s buildings● Continue to refine the ontology with additional buildings
We are looking forward to further discussion on:
● Device data and data representation● Integration with 3rd parties apps and platforms,● Work with Brick Schema to enrich the ontology model
Thank you!