A BIM-integrated graph database for the construction execution phase

Abstract

p>The execution of construction has to deal with a huge amount of operational data. By now, construction companies, as well as the other stakeholders, have no digital solution available, to deal with this data. The paper will demonstrate a building information Model (BIM)-based data model for the execution phase of construction projects. This data model is implemented into a graph database, which stores the process data and links it to the BIM. The graph database makes it possible to visualize relations between the process data and the BIM. Instead of spreadsheets an easier visual navigation and flexible customization can be reached.

The aim of this paper is to evaluate the feasibility of the developed graph database to describe the interdependencies between processes and information management. For the evaluation, an infrastructure project as case study is chosen. This kind of project covers a huge scope of different building construction technics, which makes it suitable for evaluation. Furthermore, the design, cost estimation and scheduling of the project are done by BIM-based software. This provides a digital data basis, which will be visualized in a graph and used to add process data. The exploration focussed on user-friendliness by visualization, querying and the possibility of flexible data organisation.</p

Full text

IABSE Congress – Resilient technologies for sustainable infrastructure
September 2-4, Christchurch, New Zealand
1
A BIM-integrated graph database for the construction execution phase
Sebastian Seiß M.Sc.
Bauhaus-Universität Weimar, Weimar, Thuringia, Germany
Contact: sebastian.seiss@uni-weimar.de
Prof. Dr-Ing. Hans-Joachim Bargstädt M.Sc.
Bauhaus-Universität Weimar, Weimar, Thuringia, Germany
Contact: hans-joachim.bargstaedt@uni-weimar.de
Abstract
The execution of construction has to deal with a huge amount of operational data. By now
construction companies, as well as the other stakeholders, have no digital solution available, to deal
with this data. The paper will demonstrate a building information Model (BIM)-based data model
for the execution phase of construction projects. This data model is implemented into a graph
database, which stores the process data and links it to the BIM. The graph database makes it possible
to visualize relations between the process data and the BIM. Instead of spreadsheets an easier visual
navigation and flexible customization can be reached.
The aim of this paper is to evaluate the feasibility of the developed graph database to describe the
interdependencies between processes and information management. For the evaluation, an
infrastructure project as case study is chosen. This kind of project covers a huge scope of different
building construction technics, which makes it suitable for evaluation. Furthermore, the design, cost
estimation and scheduling of the project are done by BIM-based software. This provides a digital
data basis, which will be visualized in a graph and used to add process data. The exploration focussed
on user-friendliness by visualization, querying and the possibility of flexible data organisation.
Keywords: BIM, Graph database, Construction execution, Digital technology and fabrication

IABSE Congress – Resilient technologies for sustainable infrastructure
September 2-4, Christchurch, New Zealand
2
1 Introduction
Every construction project is like a diamond, a
unicum [1]. To shape the rough diamond the
construction company has to deliver individual
services and carve information out layer by layer.
During the construction process, various
information from different parties accumulates
(Fig. 1): delivery notes by the suppliers, building
information models by the planner and contracts
by the client etc. Also, construction companies
generate a huge amount of different data during
work preparation and execution. Additionally, the
heterogeneous data is generated in various
software solutions. Therefore, construction
companies try to solve data exchange problems by
working in a closed environment. By now, no open
standardized exchange formats for the total
domain of construction information exchange for
Germany are defined. One large step in the
standardization in Germany is the BIM-LV-
Container, which links the BIM to the Bill of
Quantity [2][3].
Out of this missing standardization, it is a huge task
for construction companies to import and to link
the diversity of data into one data model. In
addition,, several construction management
applications start to integrate BIM. This increasing
usage of BIM boosts the information overload and
challenge construction companies to implement
this new method in the construction phase.
Otherwise, it helps to improve the reliability and
usability by linking the construction data, like the
bill of quantities, schedules and claims to the BIM.
In particular, small and medium businesses have
not the knowledge and financial background to
manage the data generated by the construction
activity. Therefore, it is difficult for them to derive
knowledge and understand relations.
To improve the transfer of information, it is
necessary to develop and offer user-friendly
solutions, which can be used intuitively and
without high knowledge in computer science. The
first step is to collect the information that occurs
during the process and to analyse the relationships
between them. The information is then transferred
into a conceptual data model. In a final step, the
information is transferred to a database and then
visualized. The choice of visualization is based on
simple comprehensibility of the object
relationships.
Figure 1: Information input to the site manager
2 Motivation
Since the early 80s to now data is mainly organized
in relational tables [4]. Also, construction
information is organized in tables since the
beginning of the digitalization in construction
companies. In a further development, the tables
were linked to the building information model,
which increases the usability by interaction with
the building objects in the digital environment. But
this development didn´t fix the main problem of
large tables: the complexity and perceptibility by
human beings. The larger the table is, the more
confusing it becomes. Getting an overview and
exploring data becomes more demanding [5].
By now software solutions relate the information
over different tables together and try to summarize
the information in diagrams. As an example,
Figure 2 visualizes the current presentation of
process data in the construction management
software itwo2018. But finally, the direct link
between the different entities of the table
information can not be recognized. So, tables are
limited suitable to visualize or to understand
relationships between objects, especially of
different domains.

IABSE Congress – Resilient technologies for sustainable infrastructure
September 2-4, Christchurch, New Zealand
3
Figure 2: Illustration of construction information
as tables and their relations in itwo2018
However, the huge impact of data has to get in
relation to understand it. Transforming the
information into a visual form allows the user to
discover hidden aspects in the data that are
essential for exploration and analysis. Graphs are
able to visualize a network of objects and the
relations to each other. For this reason, graph
platforms are a complement to the application of
BIM in construction execution. Abstract
construction process information and their
relations can be brought into a visually
understandable context with BIM. Due to this, it is
necessary to develop a graph platform to support
the application of BIM in the construction
execution.
3 A brief overview of graph
databases
Graph models are commonly used to illustrate
network or hierarchical structures for example to
demonstrate transport systems, social networks or
business questions. A graph consists of objects,
represented as nodes, and relations, represented
as edges. The strength of a graph model is based on
the visualization of the relations [6].
The modelling of graphs can be divided into two
main principles. These are the Resource
Description Framework (RDF) and the Labeled
Property Graph (LPG). Figure 3 shows the different
structure of LPG (top) and RDF (bottom) graphs on
an example window-wall relation. An LPG consists
of nodes and relationships. It becomes clear that an
LPG contains properties in nodes and relationships.
So, the ID and key-value pairs are stored in the
nodes and edges. In the RDF knowledge is stored in
a triple of elements: the subject, the predicate and
the object. The RDF model is standardized and
forms the basis of the semantic web. In addition,
the subjects and objects are identified using an
Internationalized Resource Identifier (IRI). An IRI
does not have to be assigned to a web page and is
only used for unique identification. The nodes and
edges of an RDF graph have no set of key-value
pairs. Out of this, each attribute of an element has
to get represented by a new predicate and object.
Only the object is able to carry a literal, like string
or number [7], [8], [9].
An advantage of the RDF representation is that it is
standardized and supported by various databases.
Furthermore, the IFC is already represented as an
RDF graph by the IFCOWL. However, it is clear that
LPG graphs are much more compressed and allow
easier queries by using labels. For these reasons,
the LPG Graph was used in the present work [10],
[11].
Figure 3: Differences between RDF (left) and LPG
(right)
4 Data model Concept
The development of a database is divided into
three steps: data analysis, design of a conceptual
model and finally the implementation in a database
schema. The conceptual data model is derived
from a literature review. In this review, current
analyses of the business process of construction
companies are summarized in a BPMN (Business
Windo w01 Wall01
Opens
Supplier:“Example Ltd. “
Material:“Wood“
Material:“concrete“
Lengt h: 3
IRI/Window01 IRI/Wall01
IRI/fills
IRI/MaterialIRI/Supplier
“Exampl e Ltd.“ “Wood “
Hight : 1
Lenght: 1.2
IRI/MaterialIRI/Length
3 “Concr ete“
Openi ng01
IRI/HightIRI/Length
1.2 1
IRI/O pens
LPG
RDF

IABSE Congress – Resilient technologies for sustainable infrastructure
September 2-4, Christchurch, New Zealand
4
Process Modeling Notation) diagram. The review
requests to integrate the different process
description notations, like event-driven process
chain or custom process definition to the BPMN
diagram. Based on the BPMN diagram all output
and input data objects are summarized in a
spreadsheet. In the final step, the required data
objects and relationships for the information
system are structured into an Entity-Relationship
(ER)-diagram [12].
4.1 Process data analyses
The first step of the data analyses was to divide the
main structure of the process in the three parts:
1. offering and contracting
2. project execution
3. project completion
Based on this classification, all involved tasks were
literary recorded and verbally described.
Afterwards, the theoretical foundations for the
formation of systematic process models and the
business processes have been worked out. For the
analyses of the execution phase, an additional view
on the pre and past phases must be given.
Therefore, the whole value chain of a construction
company is considered.
Since a detailed BPMN diagram of the workflow in
construction companies is too large and complex,
an abstracted version including the basic processes
is displayed in figure 4. The process model shows
the initialization of the execution phase as well as
data input of the information by the offering and
contracting phase. The project execution is
illustrated as a cybernetic control circuit in the
centre of the model. Klaus G. defined cybernetic as:
„Cybernetics is the theory of the interrelation of
possible dynamic self-regulating systems with their
subsystems” [13]. It can react to changes or
disturbances through control and regulation
activities to achieve a state of equilibrium [14].
Figure 4: The simplified process model

IABSE Congress – Resilient technologies for sustainable infrastructure
September 2-4, Christchurch, New Zealand
5
In terms of construction, this means that the work
preparation does not always correspond to real
construction site process conditions. Therefore,
the controlling process recognizes actual-target
deviation. To achieve the projects aims, a
permanent loop of controlling, work-preparation,
execution management and controlling must be
executed. The site engineers are in a constant
decision loop. Perennially they have to take actions
to adjust the actual value to the defined set value.
The loop contains the three main activities of site
engineer: work preparation, controlling and site
management (Fig. 4). The site management activity
executes the requirements of the work preparation
on the construction site and the controlling activity
controls the actual-target deviation [15].
This cybernetic system of the construction
execution is in interaction with other activities,
which are depending on other project members. In
addition, the activities of the execution have to be
documented by the company. After the
construction is finished the final phase of project
completion starts.
The process definition enables the collection of the
data objects included in the construction process.
All in all, 53 data objects like daily reports or risk
assessment sheets are detected in 112 activities of
the detailed process model.
4.2 Conceptual model development
The design of the conceptual model is done by the
conceptual ER modelling technique. The model
describes the required entity and related
relationships. The ER model is a neutral description
and does not determine the database management
system [12]. Based on the process analysis the
information entities are organized in an ER-model.
The ER-diagram is divided into 10 domains, which
are subdivided into 166 entities and relations. The
core part of the ER-diagram is engineered as a link
element. This element relates the different
domains to each other. An excerpt of a data model
can be seen in figure 5.
Figure 5: Relation “link” between the different domains represented as entities based on an ER-diagram
Building element
link
Bill of quantity
Tender
documents
Documentation
accaptance and
warrenty
actual-target
divergation
work preparation
work safety
Quot ati on,
bidding and work
calculation
procument
(material,
maschines,
subcontractor
company master
data
0..1
n
0..1
n
nn
nn
nm
m
m
m
m
m
accounting
n
m

IABSE Congress – Resilient technologies for sustainable infrastructure
September 2-4, Christchurch, New Zealand
6
This data model assumed that all entities are
related by the relation “link” in the centre of the
data model. This relation enables us to relate n
entities to m entities of each domain. For example,
one building element can be related to one process
or n processes out of the schedule domain. Also,
one of the processes and the building element can
be linked to an execution report.
5 Implementation on an example
model into a prototype
5.1 Example Model
A building pit made of a bored pile wall is chosen
for the implementation and can be seen in figure 6.
The bored pile wall consists of the bored pile, the
reinforcement cage, the anchor and a soldier pile
wall on top. In the construction pit, a concrete
tunnel segment is created, which is not
investigated further.
The example was chosen because of the relations
between the bored pile and the other objects can
be demonstrated very well. In this case, the bored
pile has a relation to the reinforcement cage, the
anchor and has at least one neighbour as well as
one girder on top.
Figure 6: Example model in authoring software
5.2 Transformation process of building
data
After the example model was created, the
construction must be moved from Revit to the
graph database Neo4j. The investigation on
translations for IFC-files to Neo4j results in
unusable programs or it simplify didn´t run. The
translation by IFC2NEO4J integrates all details
supported by the IFC. For example, one wall is
exported into several nodes. These nodes are
several geometrical descriptions of the object wall,
like IfcDirection or IfcAsix2Placement3D. For a
construction company only the combination of
construction objects and properties in one node is
relevant. Therefore, a new transformation
program must be written to translate the IFC into a
reduced version for the construction execution.
The transformation is divided into four main steps
and is shown in figure 7.
The transformation program is based on the IFC-
Framework Apstex for Java. The tool enables the
user to read the IFC by predefined IFC-classes in
Java. The IFC was read and then translated into
Neo4j-cypher statements and executed in Neo4j.
Figure 8 shows the result of the transformation
process as a statement (left) and graph (right). The
graph represents now the BIM with all physical
objects and relations described in the IFC. In
addition, structural elements like levels, grouping
or zones can be integrated. For this example, no
zones or levels are defined.
5.3 Linking data of the construction
execution
Following the transformation, linking the data of
the work preparation and execution phase with the
BIM is examined. Therefore, the bill of quantities,
as well as the schedule, were imported by CSV-files.
Also, the data of the construction execution were
inserted by CSV and related by hand to the
different domains.
The relations in the graph are done in addition to
the described data model in chapter 4.2. But in a
graph database, the link between the nodes is not
done by a relational table. This is an essential
difference to the implementation of a relational
database. Because the graph database enables the
user to link all objects individually to each other
without any restrictions.

IABSE Congress – Resilient technologies for sustainable infrastructure
September 2-4, Christchurch, New Zealand
7
Figure 7: Importing the IFC-based BIM into Neo4j
Create (node_1:Beam {Name: "Verbau622:Verbau:2465604",
ID: "1RRJyqMhrFS8At9c5zg27s", Brett_Breite: 0.25,
Brett_Staerke: 0.04, Brett_Laenge: 1.95, material: "Holz -
Sperrholz"}),
(node_2:SecundaryPile {Name: "Bohrpfahl
Sekundär3:Bohrpfahl Sekundär:2442800", ID:
"0dRQ5HOUfFCffDdxWXL121", Höhe: 22.3, Angeschnitten:
true, Volume: 23.24, material: "Ortbeton - bewehrt"}),
(node_6:Anchor {Name:
"Bohrpfahlankerpaar:Bohrpfahlankerpaar:2453471", ID:
"067KCJN9L8dAIhgwmPUvoI", Laenge_Betonplombe: 7.0,
Laenge_Stahlanker: 19.0, Laenge_Betonplombe: 7.0,
Laenge_Stahlanker: 19.0, material_1: "Stahl AISI 1015",
material_2: "Beton, Ortbeton"}),
Figure 8: Visualization of the example model in Neo4j; left: Neo4j sypher statement (excerpt); right:
resulting graph
Figure 9 illustrates the finished graph of an
example secondary bore pile with the relation
between the nodes of the different domains. The
visualization of all elements of the graph has been
omitted for better legibility.
Figure 9: Graph visualization of a secondary bore
pile and related domains (yellow: building
elements; blue: documentation, reports; red: work
preparation; light green: safety instruction; dark
green: partial accounting; rose: work calculation;
brown: claim; orange: procurement)
6 Exploration of the graph database
for the construction process
The LPG graph enables the user to visualize data
objects in similarity to the BIM. The entities or rows
became an illustrated object as a node. Relations
and network structures can be easily visualized and
analysed. The visualization is based on the queries
by the user. Possible Queries can be a) visualize all
building elements, item in bill of quantity and
responsibilities for one claim b) visualize all
workers, machines, process related to one building
element. Queries like this enable the construction
engineer to keep an easy overview of the project
and the effects of changes in the project.
Also, the database system enables the construction
companies and project managers to cooperate in
one system. The main system components are
illustrated in figure 10. The system architecture
allows a unidirectional import of the data by
formats like IFC, CSV, JSON or XML. The
bidirectional exchange to Desite MD or other
applications are supported via HTTP-Request.

IABSE Congress – Resilient technologies for sustainable infrastructure
September 2-4, Christchurch, New Zealand
8
Figure 10: System architecture of the prototype
To illustrate an example of the HTTP-Request
application a prototype is developed in DesiteMD.
As it can be seen in figure 11 the prototype
supports the full access to the visualization of the
database in the program. Moreover, the program
enables us to visualize the geometries of the BIM
objects. At the current stage, the prototype offers
the visualization and query-functions on the graph.
For this, the program NeoVis is used.
The data model required a detailed and
standardized information recording on the
construction site. The construction company and
subcontractors have to know which information
they have to gather and how these have to get
exchanged to the main constructor. This inevitably
results in exchange information requirements (EIR)
for the execution of the construction in similarly to
the BIM-Method. As a result, the project
management, the construction company by-self, as
well as the subcontractors, have to define EIR.
Figure 11: Combination of the graph visualization with the BIM in DesiteMD
7 Conclusion
This research presents a graph-based and BIM-
integrated approach to improve the storage and
the visualisation of construction company data
during the construction execution. The addressed
problems of the complexity of tables and the
missing network visualization could be solved.
Based on the example project the functionality of
the data model and the prototype could be
demonstrated and explored. The project database
enables all construction companies of a project to
share and store construction data in one place.
Especially for the interaction between main and
subcontractors this could be a major improvement.
Small- and middle-sized companies are able to
participate in the digitalisation of construction by
storing and exchanging data on a predefined and
open data model. The database will also enable
construction companies to analyse project data
and to improve decision making. The next step will
be to use the data model over several projects and
to aggregate the project data into a data
warehouse. This will allow business intelligence to
derive new action-oriented knowledge to support
management decisions for work preparation or
construction site management.
Finally, the data model has to be validated by case
studies. Further development steps will be an
empirical requirement study based on expert
interviews to improve and to increase the reliability
of the conceptual data model. Requirements for
the level of detail must also be derived from the
expert interviews. A closer look must be taken at
the relations and the contained information
objects of the construction documents and
activities. Therefore, investigation of possible EIRs
for the construction execution has to be done.

IABSE Congress – Resilient technologies for sustainable infrastructure
September 2-4, Christchurch, New Zealand
9
The further development of the prototype shall
enable the user to create nodes and relation
directly in the software. Also, the automatized
generation of relations must be improved, because
the linking is still very time-consuming.
Similarly, the initial application of the IFC for
information exchange in the execution phase
should be further analysed. By now the open data
standard IFC does not cover all data objects
recognized in the execution process. The IFC is able
to cover processes by the core model IfcProcess.
Also, documents can be referenced as metadata of
an external document by IfcDocumentInformation
[17]. Therefore, a detailed comparison of the IFC
and the conceptual data model should be done in a
further work.
8 References
[1] Girmscheid, G.: Projektabwicklung in der
Bauwirtschaft. Wege zur Win-Win-Situation
für Auftraggeber und Auftragnehmer.
Springer, Berlin (2004)
[2] DIN SPEC 91350:2016-11, Linked BIM data
exchange comprising building information
model and specified bill of quantities
[3] Krüger, R. Digitalisierungsstrategie für
fertigende KMU des Baugewerbes. 29. BBB-
Assistententreffen 2018
[4] Saake, G. Sattler, K. Heuer, A. Datenbanken:
Konzepte und Sprachen, MITP-Verlags
GmbH & Co. KG, 2018
[5] Preim B., Dachselt R. Interaktive Systeme.
Springer-Verlag Berlin Heidelberg; 2010
[6] Meier A. Werkzeuge der digitalen
Wirtschaft: Big Data, NoSQL & Co. Springer
Fachmedien Wiesbaden GmbH; 2018
[7] W3Schhol https://www.w3.org/RDF/;
21.02.2020
[8] Kemper A. Eickler A. Datenbanksysteme:
Eine Einführung. De Gruyter Oldenbourg;
2015
[9] Hartig O. Reconciliation of RDF* and
Property Graphs.
https://arxiv.org/abs/1409.3288; 2014
[10] Barrasa J. RDF Triple Stores vs. Labeled
Property Graphs: What’s the Difference?.
https://neo4j.com/blog/rdf-triple-store-vs-
labeled-property-graph-difference ; 2016
[11] Building Smart ltd. https://technical.
buildingsmart.org/standards/ifc/ifc-
formats/ifcowl/; 17.02.2020
[12] Meier A., Kaufmann M. SQL & NoSQL
Databases. Models, Languages, Consistency
Options and Architectures for Big Data
Management. Springer Vieweg; 2019
[13] Klaus G., Kybernetik in philosophischer Sicht.
Dietz, Berlin S.26; 1961
[14] Feess E.https://wirtschafts
lexikon.gabler.de/definition/kybernetik-
41182/version-264552. Gabler Wirtschats-
lexikon; 2020
[15] Vocke, Benno M. Organisation von Planung
und Bauausführung – Integrale Leistungs-
bilder für Organisationsplanung, Projekt-
steuerung und Projektleitung; 2016
[16] Building Smart
https://standards.buildingsmart.org/IFC/RE
LEASE/IFC4/ADD2/HTML/; 21.02.2020