data communication between disparate design applications ... · apps fm ai autodesk forge iot...

LDAC 2020

W I L L R E Y N O L D S – H O A R E L E A

Data communication between disparate design applications using Neo4J and GraphQL

L D I C 2 0 2 0

A bit -[ about ]-> me

Will ReynoldsPrincipal Digital Applications Developer

• 14 Years at Hoare Lea• C# developer + Javascript• Background in electronics and digital systems

February 2002

L D I C 2 0 2 0

• Each group have their tools and

own data requirements

• Most of it is transferred via

individual desperate files.

• Different data standards

• Frequent data duplication

• Re-work and double handling

Current state of data flow at

Hoare Lea (stages 2-4)

L D I C 2 0 2 0

Classification should help?Well no, it’s just made things harder

Effort = Huge

Maintenance = Pain

Value added = Very little

It’s largely a box ticking exercise to meet the BIM execution plan.

We’ve classified all our objects (Revit families) with classification codes:

We have created standards which are actually a burden on the design process.

L D I C 2 0 2 0

What if we could communicate building data without boundaries?

Forget everything you know about model file formats…

L D I C 2 0 2 0

So let’s turn those files over…

• Spaces/Rooms

• Levels/Stories

• Project, Building, Site

• Equipment, Furniture, Fittings

• Walls, Floors, Ceilings, Doors, Windows

• Ducts, Pipes, Containment

..and let objects coalesce into the simplest form we call them:

L D I C 2 0 2 0

Design = objects + relationships

But, if the design is not IN a model/file/container, where is it?…

(Relationships are also, data)

Don’t forget the relationships

L D I C 2 0 2 0

Looking at the paths for data exchange

File exchange between

applications. Currently, the primary

way to exchange building

geometry.

App-to-app data exchange. Realtime

data exchange for local iterative design.

No single source of truth =

synchronisation head ache.

I N T E R O P R I N G

D I S P AR T E R I N G

Here is the design: Cloud

distributed single source of truth all

building data

B U I L D I N G G R A P H

Mobile

Apps

FM

AI

Autodesk

Forge

AnalyticsIOT

BIM360

Web

Portal

SERVICES RINGDirect access to building

data for other services and

APIs

A I R , W A T E R , A N D P O W E R : O U R V I S I O N O N R E V O L U T I O N I S I N G B U I L D I N G S E R V I C E S D E S I G N W I T H N E O 4 J

Solution:

The Building Graph

• Graph Database = Data + Relationships• Perfect fit for building data• Schema free (dynamic + flexible + scalable)• Captures semantic building data at any level of detail• Single Source of truth for all of project data

• Object level access to data, no model or file!• Currently uses Neo4j and GraphQL

L D I C 2 0 2 0

• Runs on Node.js

• 0 to Full Stack in seconds!

• No code to get started

• Automated CRUD

generation from schema

• Control of permissions at field and object level

https://grandstack.io

Apollo

React

Neo4j

GraphQL

Building Graph is based on:

L D I C 2 0 2 0

Building Graph Implementation(although no React, yet… so maybe GANDstack)

/iot/API

API Management

Authentication

API

/lp1/API

GraphDB

Live Project 1

S

tora

ge

/lp2/API

GraphDB

Live Project 2

S

tora

ge

/ach/API

GraphDB

Archived

Projects

S

tora

ge

/ovl/API

Fabric

Overlord

S

tora

ge

/flm1/API

Fabric

FM Project 1

S

tora

ge

IoT Data

/mng/API

GraphDB

Management

S

tora

ge

Authorisation

Progress so far

L D I C 2 0 2 0

Why GraphQL?

• REST replacement; the future of APIs?

• A single HTTP endpoint, no complex URIs

• Solves over/under fetching

• Intuitive JSONlike schema definition

• Introspection API out of the box – no additional spec required

https://www.youtube.com/watch?v=4wyAcorzbO0

L D I C 2 0 2 0

The GraphQL Schema

• Defined in .graphql files

• Object types – the entities or classes,

such as Ducts, Spaces, or Models

• Fields – the property names and data

types available on each type

• Scalar Types – The primitive (int,

string, etc.) or custom data type

• Arguments – Additional data which

can be passed to a field

• Queries – Predefined queries

• Mutations - Functions which change

the data, such as create a Duct, Space

or model entity

L D I C 2 0 2 0

GRANDstack Leveraging Neo4j – Full automated CRUD + relate operations from schema

• @Relation – Specifies which child elements, or parent elements

• @Cypher – Custom mutations and field queries

L D I C 2 0 2 0

Defining building dataBaseElement

AbstractElement

Model

ElementType

ModelElement

Space

Level

Project

Building

System

Duct

...

ElectricalLoad

Type hierarchy

• Uses interfaces for base types

• Each file can augment types in other files

• Maintains separation of concerns

• Allows incremental detail levels

• Organic evolution of schema

Space

IS_IN

Building

Level

IS_ON

IS_IN

ProjectINCLUDES<Abstract>

IS_ON

IS_IN_SPACE

Schema : Project, Buildings, Levels and Spaces

https://github.com/willhl/BuildingGraph-Server/tree/master/schema/types

L D I C 2 0 2 0

Schema : Project, Buildings, Levels and Spaces

Space

IS_IN

Building

Level

IS_ON

IS_IN

ProjectINCLUDES<Abstract>

IS_ON

IS_IN_SPACE

L D I C 2 0 2 0

AIR_FLOW

MechanicalMechanicalElectricalElectrical DistributionDistributionSchema : MEP Types

L D I C 2 0 2 0

SpaceWall Door

Space

Space

Surface

ExternalWall

BOUNDED_BY

Surface

Surface

Surface

Geometric FeaturesGeometric Features Space

SENSING

Door

Angle

Space

SurfaceIS_OF

BOUNDED_BY

BOUNDED_BY

AHU

AIR_FLOW

AIR_FLOW

Sensor

Sensor

Sensor

Sensor

Sensor

SENSING

SENSING

SENSING

SENSING

Supply

Air

SYSTEM

Name

Metric

Units

ID

API URI

Etc.

IS_IN

Building

Level

IS_ON

Socket230V

SingleIS_OF

IS_IN

Sensor

SENSING

Extract

Air

SYSTEM

AIR_FLOW

AIR_FLOW

O2 IS_OF

Sensor SENSINGCO2 IS_OF

Current IS_OF

SensorLum IS_OF SENSING

SensorFine

DustIS_OF

SENSING

IS_IN

Door

IS_OF

IoTIoTGeometry and IOT

L D I C 2 0 2 0

• Abstract Elements can exist before a 3D

model is developed

• Elements can exist in multiple models

• Changes can be tracked across model versions

• In this case, the existence of a space is related

to many other models

• Applicable to any other abstract element,

such as Levels, Zones, Ducts, Outlets, etc.

• Updates on the abstract node can be brought

straight into other models

• Models affected by changes can be easily

identified

Model

ElementModel V1IS_IN

Model

ElementIS_IN Model V2

Space

REALIZED_BY

REALIZED_BY

SUPERSEDED_BYSchema : Abstract Vs. Model Elements

L D I C 2 0 2 0

Automatically adding Fan Coil Units to spaces

Worked example – Specific Use Case at Hoare Lea

L D I C 2 0 2 0

Worked example – Demohttps://youtu.be/Qu0K9rvvXYc

L D I C 2 0 2 0

Dynamo > Rhino > C# Function > Dynamo

Worked examples

https://www.youtube.com/playlist?list=PLLyieC3PfMaVLbkcIY5vHH3YTrCKYIf2M

L D I C 2 0 2 0

Abstract Vs. Model Elements

• In this case, the existence of a

space is related to many other

models

• Applicable to any other abstract

element, such as Levels, Zones,

Ducts, Outlets, etc.

• Updates on the abstract node can

be brought straight into other

models

• Models affected by changes can

be easily identified

Model

ElementRevit Mech

Revit Elec

REALIZED_BY

IS_IN

Rhino

IES

Model

Element

Model

Element

Model

Element

Space

REALIZED_BY

REALIZED_BY

REALIZED_BY

IS_IN

IS_IN

IS_IN

L D I C 2 0 2 0

<Abstract>Model

Element

Parameter

Change

Change

Request

Model

• Allows changes to be detected

Design <> Model

• Supports for approvable framework to accept

or reject changes

• Additional collaboration data can be captured

in the graph (e.g. BCF data)

Abstract Vs. Model Elements

L D I C 2 0 2 0

From single to multi-tenant collaboration of data?

Central Distributed

Common problem across all building project life cycles

Transfer data across domains as deliverables only? The IC way?

L D I C 2 0 2 0

Example of cross tenant workflow

• No files! Boundaryless?

• Supports change control

• Supports change history

• Communication of issues, RFIs, Design reviews, and comments in the same interface as the data

• No other communication channel required for data

Architect MEPArchitect exchanges room data with MEP consultant

L D I C 2 0 2 0

O&M Example: Graph, 3D Model + IoT Sensor datahttps://youtu.be/hsbBHZTMWtM

L D I C 2 0 2 0

More reasons why it’s great

• Not dependent on any one application

• Encapsulates logic and design knowledge for all to understand and contribute (not locked on Excel files)

• Design logic can be tested, validated, reused, and improved across any number of projects

• Automate all the things!

• Data is open to AI/ML

• Many more…

L D I C 2 0 2 0

If you can describe the logic, you can automate it.

The interface to the design is not through 3D modelling,

spreadsheet and schedules, it's through your skill to craft

functions which embed your knowledge and experience.

Such that single piece of logic can be tested, reused, and

improved across any number of future projects.

L D I C 2 0 2 0

• Develop more integrations with applications

• Third party vendor support for AECOaas

• Further development as an open source platform

• Explore other DBs

• Industry adoption

• Agreement on GraphQL Schema

• Is organic growth possible?

• Building Graph is not a finished product

• Integrations are still proof of concept

• Significant shift from file based workflows (a bit like waterfall to agile)

CHALLENGES WAYS FORWARD

How can we develop the concept further?

So, that’s the Building Graph…

L D I C 2 0 2 0

Questions?

[email protected]

@d2liYmxl

https://github.com/willhl/BuildingGraph-Server

Thank you.hoarelea.com

L D I C 2 0 2 0

data communication between disparate design applications ... · apps fm ai autodesk forge iot...

Documents