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!