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
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
Who we are at Hoare Lea
…Residential | Workplaces | Education | Arts | Health Care | Science …
UK’s Largest MEP (Mechanical, Electrical, and Public Health) Consultancy + Specialists
…Lighting | Acoustics | Sustainability | Infrastructure | Building Physics…
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?
@d2liYmxl
https://github.com/willhl/BuildingGraph-Server
Thank you.hoarelea.com
L D I C 2 0 2 0