Advanced Engineering Informatics 27 (2013) 173–188

Contents lists available at SciVerse ScienceDirect

Advanced Engineering Informatics

journal homepage: www.elsevier.com/locate/aei

A cloud approach to unified lifecycle data management in architecture,

engineering, construction and facilities management: Integrating BIMs
and SNS
Yi Jiao a,b,c,⇑, Yinghui Wang b,c, Shaohua Zhang b,c, Yin Li c, Baoming Yang d, Lei Yuan c
a
School of Computer Science, Fudan University, 220 Handan Road, Shanghai, PR China
b
Development Center of Computer Software Technology, Shanghai, PR China
c
Shanghai Ruanzhong Information Technology Co., Ltd., Shanghai, PR China
d
Shanghai Lubansoft Co., Ltd., Shanghai, PR China

a r t i c l e i n f o a b s t r a c t

Article history: The problem of data integration throughout the lifecycle of a construction project among multiple collab-
Available online 21 December 2012 orative enterprises remains unsolved due to the dynamics and fragmented nature of the construction
industry. This study presents a novel cloud approach that, focusing on China’s special construction
Keywords: requirements, proposes a series of as-built BIM (building information modeling) tools and a self-organ-
Cloud computing ised application model that correlates project engineering data and project management data through
Business social networking services a seamless BIM and BSNS (business social networking services) federation. To achieve a logically centra-
Building information modeling
lised single-source data structure, a unified data model is constructed that integrates two categories of
Life cycle data management
Version control
heterogeneous databases through the adoption of handlers. Based on these models, key technical mech-
Self-organisation anisms that are critical to the successful management of large amounts of data are proposed and imple-
mented, including permission, data manipulation and file version control. Specifically, a dynamic
Generalised List series is proposed to address the sophisticated construction file versioning issue. The
proposed cloud has been successfully used in real applications in China. This research work can enable
data sharing not only by individuals and project teams but also by enterprises in a consistent and sustain-
able way throughout the life of a construction project. This system will reduce costs for construction
firms by providing effective and efficient means and guides to complex project management, and by facil-
itating the conversion of project data into enterprise-owned properties.
Ó 2012 Elsevier Ltd. All rights reserved.

1. Introduction teams that are geographically distributed (e.g., owners, architects,

Data management problems in the architecture, engineering,
construction and facilities management (AEC/FM) industry are
complex. The main goal of data management is to enable data inter-
operability so that data generated by one party can be smoothly
shared among all participants. While this research has long been
conducted in this area and billions are spent each year on interop-
erability issues, these efforts achieve little added value [1,2].
The complexity of data management in the AEC/FM domain is a
function of the industry, with special characteristics including the
project-centric nature of the work, the fragmented nature of the
industry, and the adversarial behaviour among companies [3].
Generally, a construction project employs multiple heterogeneous
IT systems and a project consists of multiple phases (e.g., tender, de-
sign, construction, and maintenance) and involves multidisciplinary
⇑ Corresponding author at: School of Computer Science, Fudan University, 220
Handan Road, Shanghai, PR China. Tel.: +86 13636376410; fax: +86 21 54976880x10.
E-mail address: Jiaoyi@fudan.edu.cn (Y. Jiao).
consultants, contractors, sub-contractors, suppliers, and engineers)
[1]. During each phase, users generate and regenerate rich project
data that usually cover tens of thousands of one-of-a-kind building
components and are produced by incompatible IT systems (often
with evolving releases) delivered by various vendors.
Data in the AEC/FM industry are typical of the category of ‘‘big
data’’. The term ‘‘big data’’ refers to the ‘‘ever-increasing amount of
information that organisations are storing, processing and analys-
ing, owing to the growing number of information sources in use’’
[4]. Challenges in the management of ‘‘big data’’ mainly result from
three issues: volume (the increasing amount of data), variety (the
wide range of data types and sources), and velocity (the high speed
of data input/output) [5]. Construction data are required to be per-
manently stored as business assets, with the result that the volume
of data continually increases as the project proceeds. In project
activities, incompatible software programs produce a rich variety
of file formats, such as Autodesk’s DWG (abbreviation of
‘‘drawing’’), DXF (abbreviation of ‘‘Drawing Exchange Format’’),
and Bentley’s DGN (abbreviation of ‘‘design’’) for engineering

1474-0346/$ - see front matter Ó 2012 Elsevier Ltd. All rights reserved.
http://dx.doi.org/10.1016/j.aei.2012.11.006
174 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188
activities; and DOC/XLS/PPT (Microsoft office format), RM/MPEG
(video format), and JPEG (image format) for management activi-
ties. These files can be in structured, semi-structured, or non-struc-
tured form. Empirical data show that individual file sizes currently
range from Megabytes to Gigabytes, however there is an apparent
trend of increasing file size. Therefore, the total volume of data in a
construction project tends to be huge, with tens of thousands of
files. These files are generally required to be rendered on demand
for all participants, whether are they located at construction sites
or corporate offices.
In addition to these challenges, some other requirements also
exist such as layered distribution in storage. Project data evolve
from an active state to a non-active state as time elapses. Data
are frequently revised before a construction process is completed,
and then they are delivered, archived, and occasionally accessed
thereafter, mostly for facility management purposes. Another
requirement is that construction data are treated as assets that
are owned not only by temporary project teams but also by enter-
prises, organisations, and government agencies. While it would be
a great benefit for enterprises/organisations to take all of their pro-
ject data under their own control, it is unfortunately difficult to
achieve in current practice [6,7].
In short, data management and communication issues in the
AEC/FM sector are complex, challenging, and are not currently well
addressed by current technologies and applications [8–10]. ‘‘The
key issue in this area has historically been, and remains, how to
achieve inter-operability between multiple models and multiple
tools that are used in the whole product lifecycle’’ [2].
1.1. Construction data category and level of data integration
Data categories are often defined in different ways. This paper
uses the terms ‘‘PED (project engineering data)’’ and ‘‘PMD (project
management data)’’, defined as follows:
 Project engineering data are geometric presentations, paramet-
ric descriptions and legal regulations associated with the con-
struction of a building, such as component position/layer/
level, bill, and quota.
 Project management data refer to control and communication
information that are generated in and closely related to man-
agement activities throughout the construction lifecycle, such
as scheduling, monitoring, and work assignment.
Based on these terms, data integration and sharing can be per-
formed in a layered hierarchy, for example at the engineering level,
the management level, and a more integrated level combining both
engineering and management. Higher levels of data integration can
enable the construction process to be accomplished more
smoothly. In this sense, two essential questions for construction
data management are: ‘‘Is it possible to create one comprehensive
data model?’’ and ‘‘Is there a single solution that could collect and
store the data throughout the lifecycle of a building and further
distill those data into domain knowledge?’’ BIM (building informa-
tion modeling) has recently received significant interest in both
academic and industry circles as one potential answer to these
questions. Several studies [9,11,12] have indicated that developing
a single BIM model for all construction phases is something of a
‘‘holy grail’’, e.g., from a lifecycle standpoint, there are seven cate-
gories of BIMs: as-required, as-designed, as-planned, as-built, as-
used, as-altered and as-demolished. Some researchers have tried to
address the ‘‘one solution’’ issue, e.g., using a single data structure
BIM to collect, organise and integrate as-built data [13]; adopting
concurrent access to shared BIM repositories among multiple
organisations [14]; and implementing on-line enterprise planning,
scheduling and management tools (P3/e) by Primavera software
[6]. However, these studies have concentrated on either the engi-
neering level or the management level, leaving the issue of data
integration on both levels unaddressed [15]. In addition, few stud-
ies have addressed data exchange among BIMs as well as critical
technique issues such as data manipulation and version control.
This study endeavours to establish a unified organisation-level
cloud environment that supports all-phase data collection, auto-
matic data correlation, intra/inter-organisation data sharing and
diachronic data tracing. With the aim of producing an innovative,
organisation-level lifecycle solution, an industry-oriented research
project called LubanWay has been underway since January 2008,
following a ten year software development endeavour in the AEC
domain in China. An exhaustive introduction of the project is out-
side the scope of this paper, and only a portion of the project out-
comes are presented here. The contribution of this study is the
development of a novel cloud application model oriented towards
‘‘big construction data’’, which includes a series of as-built BIM
tools, introduces a special-purpose project collaboration platform
(called cBSNS, construction business social networking services),
and integrates as-built BIMs and cBSNS with as-planned BIMs.
Purposeful development of as-built BIMs is desirable due to the
particularities and sophistication of the construction industry in
China. Both central and local governments establish thousands of
standards or regulations regarding craftwork and flow [16]. Exist-
ing commercial BIM tools such as Autodesk Revit™ and Bentley
products cannot be used in this phase under such conditions. On
the other hand, China is the world’s second largest construction
market, accounting for half of projects under construction world-
wide. It is estimated that by the year 2018 China will surpass the
U.S. and become the largest market [16]. Therefore, designing
highly usable as-built BIMs is not only academically significant
but also economically valuable.
The remainder of this paper is organised as follows. Section 2
introduces the research methodology. Section 3 presents an over-
view of the proposed approach. Section 4 presents the cloud appli-
cation model of PDAS (project data as a service), along with detailed
illustrations of self-organised cBSNS, integration with BIM, the
logically centralised data model, and mechanisms of both access/
version control and data manipulation. Section 5 discusses the sta-
tus quo and the potential for deployment of PDAS in cloud storage.
Section 6 presents discussions and a case study. Concluding
remarks and ongoing research work are presented in Section 7.
2. Research methodology
This research consists of two steps. First, a list of system
requirements is established based on a literature review and our
ten years of practical experience and domain knowledge. Second,
based on a careful examination of state-of-the-art technologies
and software reviews/analyses, the design rationale and technical
roadmap are established.
A data management solution is generally acknowledged to con-
sist of four basic components: (1) a data collection model; (2) a log-
ical data model; (3) a mechanism for data manipulation; and (4) a
physical data storage model. Thus, the design goals of this research
can be distilled as follows: (1) simultaneously collect both engi-
neering and management data throughout the project lifecycle in
one cloud application; (2) support mutual data exchange among
multidisciplinary teams from different organisations in one cloud
application; (3) design a unified big-data manipulation mechanism
that supports high level data integration and enables data consis-
tency; and (4) design a scalable, high performance storage mecha-
nism that is appropriate for dynamically increasing massive
amounts of data. The main objective of this work is to bridge gaps
between the disciplines of project engineering and project man-
agement and to promote the capacity for big-data management
 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188 175

from the individual project team level to the enterprise level with can effectively interact with as-planned models such as Autodesk
reasonable requirements for user investment in IT infrastructure. Revit™. This study integrates as-planned BIM and as-built BIM,
There are two basic approaches to the design of logical data and achieves data integration between the engineering and man-
models: a distributed heterogeneous architecture versus a centra- agement levels.
lised direct data accession architecture [17,18]. The former ap-
proach stores data in different systems and leverages some
3. Overview of the developed approach
standard formats (such as IFC, Industry Foundation Classes) as data
exchange mediators. This approach suffers from at least three
Previous studies on BIM and web-based collaboration systems
flaws: (1) constant (sometimes grave) information loss when con-
provide a solid foundation for this research. However, project data
verting data from one application (model) to another; (2) poor sup-
sharing/integration at both the engineering and management lev-
port for data modification and historical version tracing, which is
els and in organisational granules remains an unsolved problem
especially problematic when frequent modifications are made by
in those studies.
multiple users; and (3) failure to achieve a complete data reposi-
This research presents an innovative SNS variant called cBSNS,
tory for project teams, not to mention for an enterprise-wide scope
which integrates custom-developed as-built BIM tools and acts as
[6,19,20]. Given this, this study chooses to design a logical centra-
a lifecycle project management system. The study contributes a
lised yet hybrid data model. Hybrid means that a relational data-
unified cloud platform and a single data source for the multidisci-
base for structured data is combined with a non-relational
plinary participants involved in the construction process (individ-
database for documents; logically centralised means that no local
uals, project teams, and organisations). At the back end of the
copies are saved at the users’ end (for cloud computing, distribu-
system, a novel, hybrid architecture is designed by integrating
tion among different sever nodes or virtual machines is another is-
the relational database and the NoSQL database through handlers
sue). To the best of the authors’ knowledge, mainstream
(‘‘foreign keys’’ in database terminology). To dynamically store a
commercial solutions such as Autodesk and Bentley do not adopt
growing body of data in a high performance way with load balance,
a distributed heterogeneous architecture either. Autodesk’s Buzz-
a two-tier cloud storage mechanism is proposed, along with a no-
saw™ solution adopts a single relational database as a central ren-
vel data distribution strategy based on data inquiry patterns. The
dezvous; meanwhile, it provides a client site for individual users to
upper tier stores active construction data concerning data creation,
keep copies at the local end. These solutions accomplish synchro-
modification, and version control. The lower tier stores archived
nisation between central and local data [21]. Bentley’s solution uti-
data, mainly for inquiry. Data transfer between the two layers fol-
lises a federated relational database architecture [9,22], which is
lows pre-defined policies.
conceptually similar to the approach taken in this study but differ-
The BSNS and BIM tools designed and developed in this study
ent in critical aspects including database type, access permission,
are referred to as MyLuban and LBIM, respectively. The former is
and version control.
a B/S (browser–server) application; the latter is a C/S (client–ser-
This research studies technologies including cloud computing,
ver) application that can be further encapsulated as a plug-in to
social network services (SNSs), BIM, RDBMS (relational database
the former. These tools share a custom-developed single sign on
management system), NoSQL (not only SQL) database, HOOPS™,
(SSO) mechanism for integration of the two applications into a sin-
web based collaboration systems, and mobile computing. As a full
gle portal. At the back end of the system, the logically centralised
discussion of all these technologies is beyond the scope of this pa-
databases are deployed in cloud storage systems. The whole appli-
per, the following text focuses on cloud, BIM, and SNS technology.
cation is made available to users as SaaS (PDAS in our context) and
Cloud computing provides new opportunities for data manage-
charges users according to consumption rather than license fees.
ment in the AEC sector. Cloud computing refers to ‘‘a model for en-
To a great extent, this system has great potential to serve as a uni-
abling convenient, on-demand network access to a shared pool of
fied platform that successfully gathers, stores, and shares construc-
configurable computing resources (e.g., storage, applications) that
tion data from all participants. The establishment of different user
can be rapidly provisioned and released with minimal manage-
account categories enables these data to be easily shared and
ment effort’’ [23]. AEC/FM related work in cloud computing mainly
manipulated by individual users, project teams, and enterprises
focuses on: (1) Software as a Service (SaaS), special-purpose soft-
with value-added mechanisms of data manipulation including ac-
ware available through the Internet that ‘‘does not require each
cess permission and version control.
end-user to manually download, install, configure, run the soft-
Fig. 1 illustrates the architecture of the proposed approach.
ware applications on their own computing environments’’; (2)
Please note that the three layers in red dashed lines indicate the
Community cloud, or a cloud that is shared by ‘‘several organisa-
contents of this paper. The rationale of the proposed approach is
tions and supports a specific community that has shared con-
to collect construction data from all geographically distributed par-
cerns’’; and (3) Infrastructure as a Service (IaaS), ‘‘provision
ticipants during each phase and store them into logically centra-
resources such as storage, and related tools necessary to build an
lised but physically heterogeneous databases that can easily be
application environment from scratch’’ [23].
accessed by each participating organisation and can generate rich
There have been several recent reports on solutions using cloud
reports and analyses for project management guidance/reference,
technology, such as Autodesk Buzzsaw™ and Bentley products
including for later facilities management.
[21,22]. Compared with this study, these solutions focus more on
efficient file management. They provide excellent synchronisation
functions that enable users to share and exchange files between lo- 4. Cloud solution: project data as a service
cal computers and cloud storage. The solution proposed in this re-
search is far beyond a system of documentation/file management. 4.1. LBIM: PED integration model
The solution automatically embeds BIM models into the project
management system; establishes correlations between BIM mod- BIM is currently an active subject of research and one of state-
els and work breakdown structures; and provides further function- of-the-art AEC technologies used to inter-organisationally collect,
alities such as cost analyses, scheduling control, and completed organise, and integrates project data, mainly engineering data. As
task comparison. As stated above, existing commercial BIMs are mentioned above, ‘‘one comprehensive’’ BIM model is an ideal
of little use during the construction stage in China. These new state that does not exist in practice; rather, different categories
BIM tools were specially developed for that purpose, and they of the BIM model manipulate geometry, spatial relationships, geo-
176 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188
Fig. 1. Proposed system architecture.
graphic information, and building component quantities and prop-
erties from different standpoints and disciplines [13,14,24–26].
4.1.1. As-built BIM tool design
In accordance with construction stage standards and regula-
tions on craftwork and flow in China, this research designs and
implements three as-built BIM tools: civil engineering BIM, steel
bar BIM, and installation BIM. These tools share the same C/S archi-
tecture and a unified storage mechanism. Other categories of as-
built BIM tools can be easily developed using the proposed design
architecture and implementation technologies.
Design of these as-built BIMs is performed by following these
three steps: (1) generating parametric 3D (three dimension) digital
objects that represent real-world (physical) components; (2)
depicting non-geometric metadata and relationships among com-
ponents; and (3) integrating and synchronising different model
views through a single data source, enabling a change in one model
view to be instantly reflected in the other views [2]. In this re-
search, the commercial HOOPS 3dGS™ (Graphics System) toolkit
is adopted to create and present 3D models bounded by basic geo-
metric attributes. Extensions to these 3D models can be made
through the HOOPS interface by defining auxiliary classes/objects
containing those components. Thus, attributes related to construc-
tion activity other than geometric models that cannot be initially
generated by HOOPS 3dGS™ are captured and bound on construc-
tion components. As this system emphasises the effective and
accurate integration of as-built data and craftwork/flow stan-
dards/regulations in BIM, this can be observed as a fundamental
differentiation between the proposed BIMs and other commercial
tools. According to the definitions of classes/objects, project engi-
neering data can be further classified into two categories: geomet-
ric data (geometric models binding with extended attributes, such
as project fingerprint, level, position, and layer) and non-geometric
data (engineering data related to standards/regulations, such as
bills, quotas, component categories, pricing modes, and flooring).
Objects denoting extended attributes in the category of geometric
data are then classified, grouped and saved into relative HOOPS
files in line with floor identifiers, i.e., all construction components
in the same floor are stored in a single file. On the other hand, non-
geometric data are designed to be stored in a relational database
(e.g., SQL Server™, Oracle™) because it is more robust in depicting
and storing large amounts of correlated information and could im-
prove the system performance.
Effective storage and organisation of HOOPS files is a complex
task that requires specialised expertise and robust tools. In Luban-
Way, instead of using the file management systems adopted in
most applications, the open source NoSQL database MongoDB™
is used. MongoDB was chosen because it is a novel distributed file
 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188
Fig. 2. Snapshot of direct API transformation from Autodesk Revit™ to LBIM.
system; its technical characteristics are most similar to those of
relational databases; and more importantly, its new features sup-
port cloud computing [27].
4.1.2. Integration of BIMs
An important contribution of this research is the achievement
of BIM integration. Technically, BIM integration refers to the estab-
lishment of two mappings (geometric data mapping and non-geo-
metric mapping) between and among different BIM tools. The
integration process in this study is conducted in two phases:
among as-built BIM tools and between as-planned as-built BIMs.
As the basis of integration, RDBMS and MongoDB™ within an as-
built BIM are first federated through a GUID (Globally Unique Iden-
tifier) handler [28], which is generated by a custom-developed
script engine when a HOOPS file is created and is automatically
written as a HOOPS file attribute and registered into a relational
database tuple. In the first phase, the unified file format LBIM is de-
fined to allow the three as-built BIMs to interact seamlessly. LBIM
is defined as a three tuple (G, O, P), where G is the set of geometric
components, O is the set of extended objects, and P denotes the
S
storage position of G and O in the database. OLBIM ¼ ni¼1 Oi , where
Oi denotes extended objects of each as-built BIM. In the second
phase, a transform process is performed between the as-planned
BIM file format and LBIM. This conversion can be achieved either
by a direct API mapping method or an indirect third-party en-
code-decode method. Fig. 2 presents a snapshot of direct API trans-
formation from Autodesk Revit™ to LBIM. As IFC is supported by an
increasing number of commercial as-planned BIMs, indirect trans-
formation via IFC will be studied further in future work.
177
In addition, with ‘‘username’’ as a connector, users could auto-
matically query related BIM models in project management activ-
ities, and vice versa.
4.1.3. Deployment in the cloud
The designed as-built BIMs are encapsulated into MyLuban (pro-
ject management system) as web plug-ins and are deployed as
SaaS cloud applications. These BIMS are available to all potential
project participants through the Internet. Fig. 3 presents a screen-
shot of this study’s civil engineering BIM tool, which was used in
the construction of the China Pavilion, Expo 2010.
Throughout the project phase, a variety of users may revise BIM
images iteratively, leading to different versions. Handling of the
version control issue is discussed in Section 4.3.2. The Basic
thought is to design a version identifier that is uniquely produced
in the form of (U, TS), where U denotes username and TS indicates
timestamp. Using identifier elements (i.e., U, or TS) and other file
attributes (e.g., GUID) as input parameters, related BIM versions
could be simultaneously invoked and presented for further busi-
ness intelligence (BI) functions such as comparison, statistics, and
analysis.
4.2. BSNS: cloud model for PED and PMD integration
Accurate data collection is the first step and the most crucial
activity in effective data management. As stated above, construc-
tion data are divided into two categories in this study: project
management data and project engineering data. This section pre-
sents the novel project management system MyLuban, a BSNS-
178 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188

Fig. 2. (continued)

based collaboration platform for project PMD collection and PED
integration among different organisations.
4.2.1. Self organised cloud
The fundamental technical requirement for effective data collec-
tion is to allow all stakeholders to login to an information system
and submit data in an appropriate way. While this may sound
straightforward, it is not easy to achieve in the construction
industry. Conventionally, there are three roles in a business MIS
(management information system): individual users, sectors, and
enterprises. The AEC/FM domain include the fourth role of the pro-
ject team, which is a critical role in this project-centric industry.
These four roles usually nest and interweave with one another.
For example, Shanghai Construction Group, a large construction
enterprise in China, has tens of thousands of individual users, tens
of sub-companies and sectors, hundreds of collaborative enter-
prises (e.g., suppliers) and project teams. One of this company’s
overseas projects consists of tens of subsidiary sectors, where bulk
participants come from collaborative enterprises and team mem-
bers continually change. A business MIS must accurately capture
and reflect organisational relationships and designate proper access
control/permission rights to each user to ensure its functionality. In
fact, this is a prerequisite for any information system to operate
successfully in practice. Unfortunately, most current systems
(MIS) are unable to handle the complicated multi-organisational
relationship of the AEC/FM sector due to their top-down, predefined
(hetero-organisation) approach in which the organisational struc-
ture is maintained by very few super users (often system adminis-
trators) in a centralised manner. This hetero-organisational
mechanism is naturally not appropriate for complex systems.
Recently, SNS has emerged as an excellent means for interper-
sonal communication, information sharing, and establishing rela-
tionships. In SNS websites, individual users can join each other
adhoc to form interest groups [29]. While this provides a good
 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188 179

Fig. 3. Screenshot of a civil engineering BIM tool for the construction of the China Pavilion, Expo 2010.

demonstration of the property of self-organisation, the intrinsically cess rights through bilateral negotiation. Further, the two rules of
individually oriented nature of this system and its lack of an organ- ‘‘active joining’’ (applying) and ‘‘passive joining’’ (invited) are de-
isational structure severely limits its wide acceptance for business fined, and both are implemented through a mechanism of mes-
applications. To solve this problem, the concept of ‘‘business organ- sage-acknowledgement.
isational structure’’ should be imported and implemented appro- Table 1 illustrates the possible relationships in this self-organ-
priately. In this research, SNS augmented in this way is referred ising process, some of which are subtle. For instance, the relation-
to as BSNS, and a pilot construction BSNS is created with four cat- ship between two enterprises is either a belong-to or a partner
egories of user accounts: individual accounts, project accounts, relationship depending on whether the real world relationship is
sector accounts, and enterprise accounts. Each account category
is a relatively independent unit mapping a real world relationship; Table 1
Rules for establishing relationships between two accounts.
these accounts can be registered freely and independently.
In this cBSNS, the organisational structure is no longer estab- Organization Organization Parent- Partner Active Passive
lished in a traditional, predefined and top-down manner, instead unit l unit 2 child join join
becoming a dynamic, bottom-up and self-organised process Individual Individual No Yes No Yes
through the execution of two atom operations: ‘‘(join)’’ and Project Yes No Yes Yes
‘‘(removal). This process is illustrated as follows. Assume that Sector Yes No Yes Yes
Enterprise Yes No Yes Yes
an individual is an employee of a small enterprise with no sectors
and is simultaneously a member of a project team managed by an- Project Individual No No No No
Project Yes No Yes Yes
other large enterprise. Further, assume all four roles (individual, Sector Yes No Yes Yes
small enterprise, project team, and large enterprise) have user ac- Enterprise Yes No Yes Yes
counts (I1, E1, P1, E2) in this cBSNS. Then, the operations of I1  E1, Sector Individual No No No No
I1  P1, and P1  E2 are all legal and should be performed. Iterative Project Yes No Yes Yes
performance of such operations results in the dynamic establish- Sector No No No No
ment of an organisational structure. Enterprise Yes No Yes Yes
As for the operation , two categories of relationships are de- Enterprise Individual No No No No
fined: belong-to/parent-child and partner/sibling relationships. In Project No Yes Yes Yes
Sector No Yes Yes Yes
the former category, a parent account owns all rights of operation
Enterprise Yes No Yes Yes
(except for deletion) of the child; the latter only grants certain ac-
180 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188
Fig. 4. Illustration of the self-establishment of the organisational structure.
an affiliation or a collaboration. This study prescribed that only in
the former case could an enterprise join another enterprise to form
a parent-child pair. Otherwise, the enterprise must join some spe-
cific sector (e.g., the administration office) of another enterprise to
form a sibling. In MyLuban, Table 1 is implemented as a rule engine
that receives ‘‘join’’ requests and parses the message and the table
to judge whether the request is legitimate. Legal requests are sent
to target accounts for rectification; otherwise, source accounts
would receive an alert of information refusal from the system. This
process is illustrated in the following Algorithm 1.
Algorithm 1
Input: Os, Ot, R, IM//sourceorganisation, targetorganization,
applied relationship, invitation mode
Output: Legitimate Judgement
1: for i = 1 to 4
2: {match Os
3: for j = 1 to 4
4: {match Ot
5: check R, IM
6: if valid {send application message to Ot, return}
7: return alert message to Os
8: } as in the scheduling module. In this case, when a construction
9: } schedule is set, information such as building area plus time span
The action  can only be performed by an immediate upper-
layer account. Removal prescribes the two statuses of ‘‘no-entrance
permission’’ and ‘‘read-only permission’’. At the back end, a data
structure called an ‘‘account status word’’ is responsible for dis-
criminating between these two actions by setting a flag bit to
either ‘‘0’’ or ‘‘1’’ during implementation.
The organisational process is illustrated in Fig. 4, where e, P, S,
and E represent individual accounts, project accounts, sector ac-
counts, and enterprise accounts, respectively. The direction of the
arrow represents which party takes the initiative to ‘‘join’’. Red
lines and red dashed lines jointly constitute a partner relationship.
The self-organising mechanism leads to a high flexibility for multi-
ple organisations working in a single application. This mechanism
creates and maintains the organisational structure in a decentra-
lised manner. Each account is independently in charge of its own
scope. This is believed to be the foundation for a successful indus-
try-level cloud application. However, due to recursion operations,
the implementation of this dynamic self-organising process is
somewhat challenging. We create a Generalised List data structure
to address both the hierarchical and one-to-many-mapping issue.
For the sake of brevity, this paper does not provide design details.
Readers should refer to Section 4.3.2 for a discussion of subjects re-
lated to Generalised Lists.
4.2.2. PMD gathering and sharing
Fig. 5 presents some screenshots of MyLuban. The goal of MyLu-
ban is to depict the complex real world relationships in the AEC/FM
sector and to act as a cloud platform collecting and sharing con-
struction data among multi-disciplinary project teams and con-
struction firms. This system has three characteristics: (1) it
retains SNS functions such as content distribution, establishing
groups, and discussing topics, enabling users to interact with
strangers from other organisations with shared interests; (2) it de-
vises a series of construction-specific functions such as project
monitoring, schedule control, and WBS (work breakdown struc-
ture), which jointly enable daily collaborative interaction regarding
construction projects; and (3) the dynamic, self-organised enter-
prise-sector-project-employee tree structure and the strict pri-
vacy/access control mechanism makes it more suitable for
business applications rather than normal social activities.
The  operation is realised by an apply-rectify protocol be-
tween an individual account and a project account; in relationships
between enterprise accounts and project accounts, the protocol is
an invite-rectify protocol. When the organisational structure is
established correctly, project information is shared by different ac-
counts according to their designated permissions. On-site informa-
tion such as the schedule, quality, and security could be filled in
using web-based forms or uploaded to the system in the form of
pictures, videos, or MS files and compared with design information
stored in the BIM database.
4.2.3. Integration and collaboration
Technically, integration of applications is performed on multi-
ple levels. In this research, the first level of integration is to ensure
that users login one at a time and then simultaneously access the
two applications seamlessly. This is realised by an SSO mechanism.
A three tuple of (User name, Password, Timestamp) records login
status in one application and is sent to other applications for
validation. If verification is passed then the other application is
activated. On the second level, business logic integration is
achieved by adding links between BIM and BSNS functions, such
is automatically transferred to BIM at the back end of the system.
At the third level, data integration between BIMs and BSNS is
achieved by the logically centralised hybrid architecture elabo-
rated in Section 4.3.
Based on these integrations, MyLuban is designed as a multi-level
collaboration platform and provides a series of rich functionalities
on different layers. Table 2 illustrates the main collaboration func-
tions of the system.
For individual accounts, the designed system functions mainly
consist of three logical categories: personal assistant (calendar,
diary, task management), project workspace (displayed after join-
ing a project team, including project organisation structure, sup-
plier, collaboration partner, project task, schedule/plan, project
monitor, etc.), and social networks (friends, ring/group).
For project and sector accounts, system functions mainly in-
clude the management of basic project information, the importa-
tion of member accounts and organisational structures, work
package assignment, permission assignment, and project docu-
mentation management.
For enterprise accounts, system functions mainly include pro-
ject/sector permission assignment; project/sector joining, removal,
and ‘‘freezing’’; and statistical and analytical data reports.
With these functions, architects, construction engineers, super-
visory engineers, and other participants could all share integrated
 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188 181

Fig. 5. Screenshots of the business social network services: MyLuban.

BIM tools. With the version control mechanism provided by the
system, collaborative works such as architectural revisions,
collision detection, construction guidance, cost estimation, and
schedule revision could be carried out in this unified platform.
Despite that, users can search cBSNS and interact with interested
individuals to make friends, publish files (grant access control
rights) to friends, join in a specific ring/group, publish topics/
questions in a ring/group for help and discussion, and search
resources through tags to accomplish inter-project/organisation
communication.

Table 2
Collaboration functions designed in MyLuban.

Role Activity Activity code description Collision Structure On-built construction Cost Schedule
code detection modification guide accounting amendment
Individual AC1 My agenda Yes Yes Yes Yes Yes
Account AC2 My diary No No No No No
AC3 Personal task management Yes Yes Yes Yes Yes
AC4 Organizational structure No No No No No
AC5 Project calendar Yes Yes Yes Yes Yes
AC6 Collaboration unit No No No No No
AC7 Project task Yes Yes Yes Yes Yes
AC8 Schedule planning Yes Yes Yes Yes Yes
AC9 Project monitoring Yes Yes No Yes Yes
AC10 Fnends No No No No No
AC11 Group Yes Yes No No No
Project/sector AC12 Project profile No No No No No
Account AC13 Add/delete/freeze individual No No No No No
account
AC14 Organizational structure No No No No No
AC15 Work breakdown structure Yes Yes Yes Yes Yes
AC16 Access permission grant Yes Yes Yes Yes Yes
AC17 B1M data import Yes Yes Yes Yes Yes
AC18 Project document management Yes Yes Yes Yes Yes
Enterprise AC19 Project/sector access permission Yes Yes Yes Yes Yes
grant
Account AC20 Add/delete/freeze project/ No No No No No
sectoraccount
AC21 Data statistical and analysis Yes Yes Yes Yes Yes
report

Note: AC4-AC9 are functions after joining project teams.

182 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188

Fig. 6. Illustration of the construction data model in PDAS.

4.3. Single data source model and data manipulation mechanism
Data interoperability refers to the ability for data created by one
participant to be properly interpreted by other stakeholders. Some
researchers believe that a common neutral (open) BIM model (such
as IFC) may be a feasible solution for the AEC/FM industry [1]. How-
ever, such an ideal common neutral data model will not be realised
in the near future. Moreover, the requirements of lifecycle project
information management are far beyond mere neutral file exchange.
Multiple models are necessary and should be made available for

Fig. 7. Illustration of a simplified version of the control model in PDAS.

 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188
both technical and non-technical users [2]. ‘‘As it is widely acknowl-
edged, the development of standard building data models, especially
when these aim to cover multiple application areas, is a very chal-
lenging task’’ [3]. Next generation systems in the AEC domain should
adopt a total lifecycle view, i.e., integration should consider all
phases and disciplines (both engineering and management) [30].
This research presents a practical PDAS data model for con-
struction, as illustrated in Fig. 6. This model is a hybrid but unified
one, in which multiple models are designed and integrated into a
logical entity. The models consist of a relational database (storing
PMD and non-geometric data, i.e., part of PED) and a NoSQL docu-
ment database (storing geometric data, i.e., the other part of PED);
connections between data elements are established by means of a
username and GUID. This unified model covers multidisciplinary
and lifecycle construction data and works well in practice.
This data model imposes special requirements around issues
such as data operation, access control, and version management.
A corresponding mechanism adapted to both BIMs and BSNS appli-
cations is designed as described below.
4.3.1. Data manipulation operations
In the context of LubanWay, four data manipulation operations
are defined as follows.
 Inquiry: the contents that a user can inquire are in line with the
access control strategy depicted in Section 4.3.3.
 Delete: operation of physical deletion is not allowed because
real business environments require every operation to be traced
for audit purposes. For each user, the system provides a visibil-
ity table containing all the items he may read; users can config-
ure items to filter the unnecessary items and execute logical
deletion to clear and organise the individual view. At the back
end, a data structure of visibility status is refreshed by setting
‘‘1’’ to a flag for logically deleted items.
 Insert: this operation mainly covers the addition of files and
records into the database. Insertion leads to the creation of a
new version. The system automatically names the new item
according to file/version naming rules, and refreshes the visibil-
ity table at the back end.
 Update: because no physical deletion operation is allowed, any
updated items should be stored as new versions. The concrete
actions required to perform this operation are the same as those
required for ‘‘Insert’’.
4.3.2. Version management
Bakis et al. [3] provided a detailed description of the necessity,
usage scenarios, and complexity of version control in the construc-
tion industry. This research focuses on four key factors in version
control: multiple participants, lifecycle phases, iterative modifica-
tion, and different version granularities (i.e., floor version, project
intermediate version, and release version). Related data need to
be organised into three categories (management, geometrical,
and non-geometrical) and into floor versions as basic units for
management. Floor versions often need to be further organised
as a larger unit for collaborative discussion or modification. Specif-
ically, some floor versions (usually covering the entire project) are
required to be packaged as milestones (e.g., construction release
version or delivery release version) that do not allow for further
modification.
Moreover, a majorit y of construction files are geometric files
that cannot be merged. While it is often the case that a designer
browses several geometric files but finally chooses only one as a
blueprint to start his modification, these reference relations must
be recorded to ensure other operations, such as for later tracing
back or modification notification.
183
Fig. 7 illustrates a simplified version control model in PDAS,
which mainly considers version organisation and version notifica-
tion. To address the intermediate version and project release ver-
sion issues, the concepts of ‘‘tag’’ and ‘‘branch’’ are defined and
introduced. Data structures and algorithms stemming from Gener-
alised List theory are further conceived for version organisation
and management.
4.3.2.1. Mechanism description. The mechanism of version control
used in this research is summarised as follows:
1. Because 3D geometric models cannot be merged, every modifi-
cation by each user is regarded as a new version and stored as a
new file. A GUID code is automatically generated by a script
engine and then stored as an attribute for this new file. The sys-
tem automatically records the modification timing and the
GUID code of the parent file as the new file’s attributes. The
GUIDs of the referenced files are manually stored as the new
file’s extended attributes by the user.
2. File naming rule: both project management files and HOOPS
files are named in the form of (user name, time stamp, business
logic name). user name and timestamp are mandatory and are
automatically generated by the system; business logic name is
manually entered by the user. The project name must be
entered in business logic name in some agreed upon form.
3. Floor version naming rule: the floor version is named in the
form of (user name, timestamp). These two elements are auto-
matically generated by the system and constitute a unique ver-
sion identifier. Moreover, for flexible inquiry and other
consideration, users can designate alias as the identifier.
4. Interrelations: GUID code is used as a connector between the
geometric data file (HOOPS file, stored in MongoDB™) and the
non-geometric data record (tuples stored in RDBMS). Username
is used as a connector between project engineering data and
project management data (see Fig. 6).
5. Notification rule: when a new version is constructed, a flag is
set and the version link is published under the creator’s name
in the BSNS organisational structure. Multiple new version links
would be organised in descending time order as an unread ver-
sion link list on the web page.
6. Concurrent updating: when multiple users are modifying the
same file, according to 1, each modification result will be stored
into a new version file, with the parent GUID code as the master
file attribute. As this would not cause an error such as a loss of
the modification or a conflict, concurrent mechanisms such as
locks are not further studied here. Although the desired result
of saving all modifications in a single file is not achieved, users
can perform their modifications with more flexibility. It is easy
for users to trace all related versions (using parent GUID) for
further modification.
7. Manipulation object and process: all manipulations are per-
formed on a version identifier directory, i.e., the object of
manipulation is not a redundant physical file copy but merely
a version name. This directory is established and maintained
by the system; an extended Generalised List Series is created
to perform the entire version control task.
4.3.2.2. Generalised List. Preliminary knowledge:
 A Generalised List is a two-tuple Lists = (D, R), in which
D = {di|i = 1, 2, . . .n; n P 0; di e D0 or di e another lists, D0 is a
predefined data set} R = {LR} = {hdi1, dii|di e D, 1 6 i 6 n}
 A general expression reads Ls = (a1, a2, . . ., an), where ai is called
an element or node, which could be either an object of a given
dataset or a list satisfying the definition (called a sub-list).
184 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188

8
 Recursive list: a recursive list reads A(a, A), where a list is an < ðÞ
>
element of itself. CDV UTS ð6Þ
 Generalised List series: lists that can be traced back to a com- >
:
ðUTS;CDV1 ; CDV2 ; . . . CDVn Þ
mon Generalised List are called a Generalised List Series.
Class declarations of CDV are partially shown as follows:
A Generalised List is a special data structure that features char-
acteristics not only of linear lists but also of trees and graphs and is 1. List Node declaration.
most suitable for describing recursive and layered structures. Class TGListNode
Although some dynamic properties could be achieved by opera- {
tions such as inserting or deleting a node, Generalised Lists mainly char flag; // 0: Element, others: sub-list
describe cut-and-dried (static) object structures. The capacity to char name [CNST_Size ListNodeName];
describe dynamic process is weak, with the version control issue TGListNode next;// pointer to next element
in PDAS as one example. union
To express dynamic transforms (after the insertion of new ver- {
sions) in a unified form, this research proposes a Dynamic Gener- char  pElem;
alised List Series data structure, described as follows. TGListNode  pSub; // head pointer of sublist
}//. . .
Definition 1. Dynamic Generalised List Series. A Dynamic Gener- };
alised List Series is defined as 2. Node Interface declaration.
8
Enum TraverseMode{PreOrder, LevelOrder};
< ðÞ
>
Class CDGListNode
A ðaÞ ; ð1Þ
>
: {
ða; A1 ; A2 ; . . . An Þ ...
which is a changing recursive list set denoting different forms at dif- public:
ferent time slices. char IsList();// 0: element, others: sublist
Formal model for version control: CDGListNode  GetNext(){return next;};
// address of next element
Definition 2 (Tag). A tag is defined as an identifier of several SetNext(CDGListNode p){next = p;};
intermediate floor versions chosen by a specific user at one time ...
point. All tags defined in one specific floor version form a CDGListNode  GetParent(){return parent;};
Generalised List SetParent (CDGListNode  p) {parent = p; flag = 1;};
//adress of sublist that the current element belongs to
Tðt; TÞ: ð2Þ ...
};
Definition 3 (Branch). A branch is defined as an identifier of sev- 3. List Interface declaration.
eral non-modifying floor versions chosen by a specific user at Class CDGList
one time point. All branches defined in one specific floor version {
form a Generalised List ...
public:
Bðb; BÞ: ð3Þ CDGListNodeGetHead(CDGListNodepNode) = 0 ;
// address of a list’s first element
CDGListNode  GetTail (CDGListNodepNode) = 0;
Definition 4 (Notification). A notification is defined as an acknowl- ...
edgement signal sent back from a specific user after reading a new CDGListGetSub(CDGList  T, charpE, int n,
version. Notifications from all users to a specific version form a TraverseMode = PreOrder);
Generalised List //in list T, search sublist, whose nth node value equals to
pE, return sublist address
Nðn1 ; n2 ;   nk Þ ð4Þ CDGList SetChild(CDGList  T, CDGList  p, int n);
// in list T, insert sublist p before nth node, return p’s
Definition 5 (Floor version). A floor version is an identifier of address after insertion
related project management files/records, geometrical files, and if n = 0, insert at the end of the list; if n < 0, insert from the
non-graphical records. The version is defined as end
InsertNode (CDGList T,  p, int n);
UTSðg c ; g p ; g pr1 ; . . . ; g prn ; T; B; NÞ ð5Þ // in list T, insert node (whose value equals to p) before
nth node
where U denotes username, TS indicates timestamp, gc is the GUID if n = 0, insert at the end; if n < 0, insert from the end
of the current version, gp is the GUID of the parent version, gprl and ...
gprn are reference versions, T represent tags related to the current };
version, B represent branches related to the current version, and
N are the notifications from each user related to the current version.
Operations and algorithms:
The operations in this mechanism mainly include the insertion
Definition 6. Construction data version container CDV. A CDV is
of a new version, finding the parent (child) version, the creation of
defined as a Dynamic Generalised List Series:
a tag, finding tagged version series, the creation of a branch, finding
branched version series, and the registration of a notification.
These operations are depicted as follows:
 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188 185

1. When a new version is created, insert it into CDV. This is imple- Algorithm 5 (continued)
mented in Algorithm 2. See below.
10: } //q: corresponding sublist UTS’s address
11: return array VersionList
Algorithm 2
Input: UTS, CDV
4. Given a series of floor versions, group them into a branch; given
Output: CDV after insertion of UTS
a branch identifier, find all the floor versions under that branch.
1: q = Initialize (UTS) // transfer to an element
This algorithm is similar to the tag algorithm. In addition,
2: p = Getsub (CDV, q.gp, 2, TraveseMode = PreOrder)
because branched versions cannot be modified, they must be
3: SetChild (p, q, 0)
restored as a new CDV.
5. Given an acknowledgement signal from a user, register that sig-
2. Given a version, find its parent version(s) and children ver- nal into the corresponding CDV node. The registration algo-
sion(s). This is implemented in Algorithm 3. See below. rithm is also similar to Algorithm 4.
In PDAS, these designed data structures and algorithms are
Algorithm 3 implemented into a version control server, which works together
Input: GUID, CDV with a log component, jointly enabling accurate construction data
Output: parents, children version management among multiple users and organisations. This
1: p = Getsub (CDV, GUID, 1, TraverseMode = PreOrder) discussion omits further implementation details including many
2: q = p. Get Head ()//get the address of element whose gc = GUID subtle technical issues such as the storage structure design and vis-
3: q = q. GetNext()//get the gp element’s address iting flags for recursive traverse.
4: while (! q. IsList ())//if gpr1. . .gprn exist
5: {put q into array parents 4.3.3. Access control strategy
6: q = q. GetNext() The access control mechanism ensures that only the right user
7: } // find all parent versions has permission to the right data at the right time [3]. The strategy
8: for i = 1 to 3 in PDAS consists of two parts: a global policy and a personalisation
9: q = q. GetNext ()//locate to children sublist’s address policy. The basic global policy adopted in this study is Role Based Ac-
10: while (q) cess Control (RBAC) [31]. Personalisation policy is designed accord-
11: {put q into array children ing to the psychology and willingness of the user. This strategy is
12: q = q. GetNext() implemented in a decentralised manner so that no single organisa-
13: } // find all children versions, not including reference ones tion/user is responsible for overall access permission management.
14: return parents, children The subjects of user profiles and published files are two major
considerations. For the organisational structure, this strategy makes
some minor revisions to the standard RBAC: the user is the owner of
3. Given a series of floor versions, group them into a tag; and given the files he creates, but does not have the right to physically delete
a tag identifier, find all the floor versions under the tag. These those files, as explained in the above section. Therefore, if users find
are implemented in Algorithms 4 and 5, respectively. any mistakes in an uploaded file, the only thing they could do is to
re-upload a new version, as they would be barred from deleting an
Algorithm 4 existing file. High-level users (e.g., project managers) only have
Input: GUIDs, tagname, CDV ‘‘read’’ permission to subsidiary users’ files by default. In contrast,
Output: CDV tagged unless a user is manually granted access permission, a subsidiary
1: n = count (GUIDs) //compute version number under a tag user cannot read either his peer colleague’s or his supervisor’s files.
2: for i = 1 to n A project manager could use a removal action to temporally or per-
2: {p = GetSub (CDV, GUITi, 1,TraverseMode = PreOrder) manently prohibit a user’s right to access a project account. An
3: q = p. Get Head () enterprise account could use a special ‘‘freezing’’ action to tempo-
4: while (!q. IsList ()) rarily or permanently prohibit a project account, with the result
5: q = q. GetNext () //locate to tag sublist that all project members would be prohibited from accessing the
6: InsertNode (q,  tagname, 1) //insert at the beginning project information. Finally, within a project team, user profile
7: } information is transparent to other users.
For the standard SNS part of the system, a user’s profile could be
exposed in three levels: fully shown, partially shown, or basically
Algorithm 5 shown. The default value presented by the system is a basic profile
Input: tagname, CDV that contains a highly limited amount of vocational information
Output: version list under tagname such as ‘‘position: design engineer’’. An optional willingness policy
1: q =  CDV may include settings such as showing the full profile for ‘‘friends’’
2: PreOrder (q) // traverse in PreOrder and ‘‘colleagues’’ (members in the same project), a partial profile
3: {p = q. GetHead ()//get first element’s address for members in a ring/group, and only a basic profile for others.
4: while (!q. IsList ()) The system automatically establishes a ‘‘colleague’’ relationship
5: q = q. GetNext () whenever a user joins a project. The establishment of a ‘‘friends’’
6: q = GetHead () //find the tag sublist relationship requires an ‘‘apply-acknowledge’’ protocol in which
7: while q & & (q.value! = tagname) no access permission is granted to the applicant prior to acknowl-
8: q = q.GetNext() edgement. This rule also holds for ‘‘friend’s friends’’ as a recursive
9: if (q) {q = GetParent(GetParent (q)), put q into array connection in SNS. The access duration policy for published files is
VersionList} ‘‘once shown, show all the time’’. Moreover, if a user quits a rela-
tionship, his access right to newly published files would be auto-
matically cancelled.
186 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188
Fig. 8. Snapshot of cascading BIM with schedule execution and cost analysis in the Shanghai Center project.
5. PDAS data storage in cloud
As mentioned in Section 1, the size of the current individual
construction data file is usually in the range of Megabytes to Giga-
bytes, resulting in an enormous total volume of data in a project.
PDAS is deployed as SaaS and community cloud, which aims to
provide services to any construction organisation. The storage sys-
tem plays an important role in this context.
Cloud storage is a promising solution that provides distributed,
scalable, and widely accessible service to applications. Many
researchers believe that read-mostly data management applica-
tions are suitable and will be one of the first types of applications
to be deployed in the cloud environment [32]. To a large extent,
PDAS is a query-intensive application that features read-mostly
characteristics. Specifically, the application uses a hybrid data
model relational database mixed with the NoSQL database (Mon-
goDB™). Although the latest release of MongoDB™ provides
map-reduction functions and therefore supports cloud deployment
[27], immigrating a relational database to the cloud is still a chal-
lenge for academic researchers [33–35].
Currently, industry vendors only offer a few quasi-cloud storage
products in practice. This research chooses to deploy PDAS in an
EMC Isilon™ cluster that provides some cloud storage features
such as scalability. The data storage policy in Isilon™ cluster nodes
follows the traditional pattern of horizontal distribution. However,
as large objects such as video files are common in the AEC/FM sec-
tor, horizontal distribution is likely to lead to the storage of these
large objects in different storage nodes. Hence, the ‘‘table join’’
operation would cause bulk data transfer among storage nodes, se-
verely degrading the performance of the system. Moreover, storage
nodes would be heterogeneous in a full cloud storage environment,
with different CPU and storage capacities. Therefore, more effective
data distribution strategies need to be studied.
This study proposes an SQL query based hybrid data distribu-
tion strategy with three algorithms. The system first calculates
the database table query mode and then groups related tables
(especially tables involving large objects) into a single potential
distribution unit, and finally checks the allocatable node list to se-
lect a proper node with a current capacity that is optimised for a
balanced data distribution. The research findings on cloud storage
are reported in another paper (please refer to [36]). Testing results
suggest that this strategy is well suited for the data distribution of
large objects in the AEC/FM domain, and the strategy could easily
be extended to a full general cloud storage environment. The
implementation of this strategy is ongoing.
6. Case study and discussion
This section reports the real application of this system in China:
the use of LubanWay in the construction of the Shanghai Center
(whose final official name is Shanghai Tower). The mansion of
the Shanghai Center is designed as the highest skyscraper in China
and the third highest in the world, at 632 m high and covering
570,000 square metres of construction area. The project began in
November 2008 and is currently under construction. The general
contractor, SCG (Shanghai Construction Group), has a registered
capital of 200 million US dollars. More than 100 sub-contractors
 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188
are participating this project. Autodesk Revit™ was used as the
modeling tool in the design phase.
SCG purchased this proposed cloud service in 2011 and created
a project account for SC (Shanghai Center) in MyLuban; all partici-
pants from SCG and the sub-contractors registered individual ac-
counts and joined the SC account. In addition, six special interest
groups were founded for the discussion of construction issues.
Using BIM integration tools, as-planned BIM data (Revit™ models)
were first transformed into LBIM format. Data related to construc-
tion craftwork were then overlaid, including bills, quotas, and pric-
ing modes, thus generating the initial civil engineering model. This
work was finished within five business days. Initial installation
models were built from scratch using the Luban Installation BIM
tool. This was performed within seven business days. These models
were stored in the PDAS cloud database; authorised employees of
SCG and sub-contractors could access these models via the Inter-
net. Project managers setup a schedule for the revision and verifi-
cation of these models, which was published in his personal plan
and shown to authorised personnel. In 30 business days, these
models were revised 56 times and 72 model versions were gener-
ated. Communication regarding this revision process was princi-
pally conducted through messages and discussion topics in
MyLuban. One version of these models was finally agreed upon
and validated as the construction management baseline. To sup-
port construction management reference and guidance, this base-
line model is able to dynamically grow as planned tasks are
executed; meanwhile, it automatically calculates and displays con-
struction costs. Fig. 8 presents a snapshot illustrating this process.
Feedback from general contractors proves that the adoption of
LubanWay has significantly accelerated the project construction
process and decreased the cost of constructing the Shanghai Cen-
ter. The system accurately calculates the total demand for con-
struction materials, further decomposes this volume and assigns
it to daily construction activities, therefore avoiding exceeding
purchase limits and repeated large scale vertical on-site transpor-
tation. The total construction budget of the Shanghai Center is
3550 million US dollars, with 70% for materials and facilities. While
the rate of material waste in China is usually no less than 10%, the
implementation of LubanWay for the construction of the Shanghai
Center enabled this figure to be decreased to no more than 4%.
During the process of transforming Revit™ to LBIM, some com-
plex components failed or were missing, such as hyperboloid, set-
tee, and illumination; this is mainly due to the geometric
mismatch between these two file formats. However, statistics
show that the rate of missing components in the SC is below
0.1%; this is acceptable and in practice is amended by manual
configuration.
7. Conclusions and ongoing research
This paper reports some of the research outcomes of the ongo-
ing LubanWay project. The main contribution of this research is the
design and implementation of a ‘‘project data as a service’’ cloud
application model that solves the big-data lifecycle management
problem in the AEC/FM sector. The research highlights can be sum-
marised as follows: (1) a novel self-organised business social net-
work service application as a unified platform for lifecycle
construction data gathering and sharing; (2) design and implemen-
tation of three as-built BIM tools dedicated to construction in Chi-
na; integration of these as-built BIMs with BSNSs and as-planned
BIMs such as Revit™; (3) a specific logically centralised database
model ensuring the integration of project management data and
project engineering data; (4) an access control, version manage-
ment, and data manipulation mechanism that extends the Gener-
alised List approach and ensures that data are effectively shared
187
among different organisations; and (5) deployment of this system
as an SaaS cloud and a community cloud, enhancing the organisa-
tion-level capacity for data control. This PDAS cloud is currently
employed in real business applications in China and is a prominent
platform for industrial level collaboration for the entire AEC/FM
sector. PDAS can allow construction firms to seamlessly combine
project engineering data and project management data, accumu-
late knowledge from all participants through each phase, effec-
tively and efficiently take charge of project information, and
share with partners according to agreed business roles. Practical
statistics prove that this cloud application is particularly effective
in cost control and elimination in very large construction projects.
Ongoing research work mainly includes: (1) supporting mobile
devices and IFC transformation; (2) improvement and implementa-
tion of the proposed data distribution strategy in cloud storage; and
(3) establishment of a BIM data warehouse for better business intel-
ligence functions and more effective aid to facilities management.
Acknowledgements
This work is partially funded by the Shanghai Rising-Star
Program (B type) and International Enterprise Cooperation Pro-
gram of STCSM (Science and Technology Commission of Shanghai
Municipality) under Grant 11QB1404300 and 12510701700
respectively. The authors would like to thank all industrial collab-
orators for their implementation of our research findings. We also
thank Ruanzhong Co., Ltd. and LubanSoft for their agreement to
publish real project data.
References
[1] W. Shen, Q. Hao, H. Mak, J. Neelamkavil, H. Xie, J. Dickinson, et al., Systems
integration and collaboration in architecture, engineering, construction, and
facilities management: a review, Adv. Eng. Inform. 24 (2010) 196–207.
[2] T. Cerovsek, A review and outlook for a ‘Building Information Model’ (BIM): a
multi- standpoint framework for technological development, Adv. Eng. Inform.
25 (2011) 224–244.
[3] N. Bakis, G. Aouad, M. Kagioglou, Towards distributed product data sharing
environments—progress so far and future challenges, Autom. Constr. 16 (2007)
586–595.
[4] C. Tankard, Big data security, Network Secur. 7 (2012) 5–7.
[5] C. Pettey, L. Goasduff, Gartner Says Solving ‘Big Data’ Challenge Involves More
Than Just Managing Volumes of Data. <http://www.gartner.com/it/
page.jsp?id=1731916>, 2011 (accessed 20.12.11).
[6] T. Rujirayanyong, J. Shi, A project-oriented data warehouse for construction,
Autom. Constr. 15 (2006) 800–807.
[7] Z. Ma, N. Lu, S. Wu, Identification and representation of information resources
for construction firms, Adv. Eng. Inform. 25 (2011) 612–624.
[8] W. Huhnt, S. Richter, S. Wallner, T. Habashi, T. Krämer, Data management for
animation of construction processes, Adv. Eng. Inform. 24 (2010) 404–416.
[9] R. Vanlande, C. Nicolle, C. Cruz, IFC and building lifecycle management, Autom.
Constr. 18 (2008) 70–78.
[10] C.-Y. Chiu, A.D. Russell, Design of a construction management data
visualization environment: a top–down approach, Autom. Constr. 20 (2011)
399–417.
[11] R. Howard, B.C. Björk, Building information modeling-experts’ views on
standardization and industry deployment, Adv. Eng. Inform. 22 (2008) 271–
280.
[12] N.Cˇ . Babicˇ, P. Podbreznik, D. Rebolj, Integrating resource production and
construction using BIM, Autom. Constr. 19 (2010) 539–543.
[13] I. Brilakis, M. Lourakis, R. Sacks, S. Savarese, S. Christodoulou, J. Teizer, et al.,
Toward automated generation of parametric BIMs based on hybrid video and
laser scanning data, Adv. Eng. Inform. 24 (2010) 456–465.
[14] S. Fox, J. Hietanen, Interorganizational use of building information models:
potential for automational, informational and transformational effects, Constr.
Manag. Econ. 25 (2007) 289–296.
[15] R.J. Scherer, S.-E. Schapke, A distributed multi-model-based Management
Information System for simulation and decision-making on construction
projects, Adv. Eng. Inform. 25 (2011) 582–599.
[16] Construction Regulations (in Chinese). <http://www.mohurd.gov.cn/>, 2012
(accessed 05.06.12).
[17] S. Moses, A. Elhamalawi, T. Hassan, The practicalities of transferring data
between project collaboration systems used by the construction industry,
Autom. Constr. 17 (2008) 824–830.
[18] C.M. Eastman, A data model for design knowledge, Autom. Constr. 3 (1994)
135–147.
188 Y. Jiao et al. / Advanced Engineering Informatics 27 (2013) 173–188
[19] C. Koch, B. Firmenich, An approach to distributed building modeling on the
basis of versions and changes, Adv. Eng. Inform. 25 (2011) 297–310.
[20] A. Pradhan, B. Akinci, C.T. Haas, Formalisms for query capture and data source
identification to support data fusion for construction productivity monitoring,
Autom. Constr. 20 (2011) 389–398.
[21] Buzzsaw. <http://usa.autodesk.com/buzzsaw/>, 2012 (accessed 05.06.12).
[22] Bentley solutions. <http://www.bentley.com/en-US/Products/AECOsim+ Building+
Designer/>, 2012 (accessed 05.06.12).
[23] S. Sakr, A. Liu, D.M. Batista, M. Alomari, A survey of large scale data
management approaches in cloud environments, Commun. Surv. Tutor. IEEE
13 (2011) 311–336.
[24] S. El-Omari, O. Moselhi, Integrating automated data acquisition technologies
for progress reporting of construction projects, Autom. Constr. 20 (2011) 699–
705.
[25] M. Tsai, J. Yang, C. Lin, Synchronization-based model for improving on-site
data collection performance, Autom. Constr. 16 (2007) 323–335.
[26] O. Eck, D. Schaefer, A semantic file system for integrated product data
management, Adv. Eng. Inform. 25 (2011) 177–184.
[27] MongoDB. <http://www.mongodb.org/>, 2011 (accessed 20.12.11).
[28] P. Leach, M. Mealling, R. Salz, A Universally Unique IDentifier (UUID) URN
Namespace (IETF RFC 4122). <http://www.ietf.org/rfc/%20rfc4122.txt>, 2005
(accessed 20.12.11).
[29] S. Guha, K. Tang, P. Francis, NOYB: privacy in online social networks, in:
Proceedings of the First Workshop on Online Social Networks (WOSN’08),
ACM, Seattle, Washington, USA, 2008, pp. 49–54.
[30] Y. Rezgui, C.J. Hopfe, C. Vorakulpipat, Generations of knowledge management
in the architecture, engineering and construction industry: an evolutionary
perspective, Adv. Eng. Inform. 24 (2010) 219–228.
[31] ANSI INCITS 359-2004. American National Standard for Information
Technology-Role Based Access Control, American National Standards
Institute, Inc., NY, USA, 2004.
[32] D.J. Abadi, Data management in the cloud: limitations and opportunities, IEEE
Data Eng. Bull. 32 (2009) 3–12.
[33] J. Zhao, X. Hu, X. Meng, ESQP: An efficient SQL query processing for cloud data
management, in: Proceedings of the CIKM Workshop on Cloud Data
Management (CloudDB 2010), Toronto, Canada, 2010, pp. 1–8.
[34] M. Wen, Z. Ding, Selection oriented database data distribution strategy for
cloud computing, Comput. Sci. 37 (2010) 168–172 (in Chinese).
[35] L. Yu, Y. Zhang, S. Wang, Q. Zhang, Research on simulative column-storage
model policy based on row-storage model, J. Comput. Res. Dev. 47 (2010) 78–
885 (in Chinese).
[36] Y. Jiao, L. Li, Y. Wang, N. Ye, A proprietary cloud oriented data distribution
strategy, J. Comput. Res. Dev. 48 (Suppl.) (2011) 239–244. in Chinese.