Automation in Construction 102 (2019) 270–287

Contents lists available at ScienceDirect

Automation in Construction
journal homepage: www.elsevier.com/locate/autcon

Building information modeling services reuse for facility management for T

semiconductor fabrication plants
Chuen-Chyi Hsieha,b, Chang-Yuan Liua, Pai-Yu Wua, An-Ping Jenga, Ru-Guan Wanga,
Chien-Cheng Choua,
⁎

a
Information Technology for Disaster Prevention Program, Department of Civil Engineering, National Central University, Taiwan
b
Powerchip Corporation, Hsinchu Science Park, Taiwan

ARTICLE INFO ABSTRACT

Keywords: As building information modeling (BIM) technology becomes mature, there is an increasing demand for the
Building information modeling interaction or interoperability between BIM tools and various facility management (FM) systems, especially in
Model-driven architecture semiconductor fabrication plants (FABs). Customized BIM services, i.e., plugin programs, have been developed
Facility management for FM systems to reuse BIM data or functionality. However, such development may make an FM system more
vulnerable to external changes such as BIM tool upgrades. The quality of BIM models reused may deteriorate
sharply even if a slight change occurs in any of the upstream BIM services. Based on the model-driven archi-
tecture defined by Object Management Group, this research proposes a semi-automated FM system factory called
EncapsulatingBIM4FM to formalize the reuse process of BIM services so that changes on BIM tools will not
propagate to an FM system. A pilot system for selected FM tasks for an FAB in Taiwan was crafted using
EncapsulatingBIM4FM. The tests demonstrated that BIM and FM systems can achieve software interoperability,
and they can evolve independently based on individual requirements. BIM's central role in the management of a
facility's lifecycle information could be established if EncapsulatingBIM4FM is utilized to develop associated FM
systems for the facility.

1. Introduction
As building information modeling (BIM) technology becomes ma-
ture, more and more facilities have corresponding BIM models created
in the design and/or construction phases [1,2]. Indeed, BIM technology
has been successfully applied to many information-intensive activities
performed in the architecture, engineering and construction (AEC)
domain, such as clash detection and constructability analysis [1–4].
Although BIM models have been recognized as a great asset to facility
management (FM), methods or processes for FM systems to reuse BIM
models still require investigations, especially for specific domains with
unique characteristics [5].
In semiconductor fabrication plants (FABs), some FM work may
need to be performed before the end of the construction phase, e.g.,
equipment inspection and hook-up tasks [6,7]. Recent statistics also
show that every 6 to 12 months, FAB machines need to be upgraded or
replaces to meet new production requirements [8], which will result in
numerous adjustments of pipes, ducts, floor heights, etc. All the
aforementioned circumstances lead to modification of FAB BIM models
and have posted challenges on the FM systems that want to reuse BIM
models.
Currently, some of the FAB engineers use a file-based transforma-
tion approach to the acquisition of BIM data [7]. However, such data
quality is not reliable, and the transformation performance is often
slow, ranged from several minutes to hours [5]. Others develop custo-
mized BIM services or plugin programs residing in corresponding BIM
tools, so that specific BIM data acquisition or designated BIM work can
be completed for the FM systems initiating the requests. This research
concentrates on such use, because more and more BIM tool providers
supply experienced users with extension mechanisms or application
programming interfaces (APIs) to help and expedite the development of
such BIM services, e.g., Maximo Revit Plugin [9,10].
Nevertheless, literature has shown several drawbacks associated
with such BIM API approaches [11–19]. First, from the viewpoint of FM
systems, many of the BIM APIs are over-designed due to the fact that
the APIs are originally designed to provide assistance in the AEC do-
main [13,14]. Second, an FM system may need to deal with two or more
BIM tools designed for different AEC disciplines [15,16]. For instance,
detailed structural analysis results are recorded in one BIM tool,
whereas architecture and construction project-related data are recorded

⁎
Corresponding author.
E-mail address: ccchou@ncu.edu.tw (C.-C. Chou).

https://doi.org/10.1016/j.autcon.2018.12.023
Received 28 December 2017; Received in revised form 7 October 2018; Accepted 26 December 2018
Available online 09 March 2019
0926-5805/ © 2019 Elsevier B.V. All rights reserved.
C.-C. Hsieh, et al.
in another BIM tool. Therefore, if an FM system would like to know the
best locations to place micro vibration sensors to detect movements or
vibrations in an FAB, two customized BIM services, each with its own
programming environment and BIM platform, need to be developed. In
this way, the FM system can be regarded as having coupling relation-
ships to the two BIM tools, which not only complicates its development
work but makes it more vulnerable to any changes resulting from the
BIM tools [17,18].
Lastly, when one BIM tool involved has a newer version, which
often happens recently, its FM system will become obsolete as long as
the corresponding BIM model is updated using the new tool version
[14,19]. For a BIM service developed based on the old version, mod-
ification of the source codes will be needed so as to be compatible with
the new BIM tool version. Currently, commercial BIM tools often pro-
vide a list of API change logs to instruct developers how to rectify their
source codes [20], or a migration wizard to help such API transfor-
mations [21]. Nevertheless, such BIM-induced requirements complicate
the development of an FM system, which may ultimately lead to an
inconsistent BIM model. Therefore, an efficient and effective way for
better reusing BIM models for FM systems in FABs is imperative and has
been suggested for years [16].
In the software engineering domain, varied approaches have been
proposed to address such software interoperability problems, which can
be interpreted as one system reusing data or functions of other systems
[22]. The basic solution is to create a middle layer, among others, in
order to remove the coupling between different systems. However,
since FM systems as well as their facility maintenance data may need to
be long-lived in order to support an FAB whose lifespan is in decades,
such FM systems and data often outlive the BIM tools originally utilized
[23,24]. Thus, it is perhaps worth considering the inclusions of stable
software interfaces and mediating components as the middle layer that
can not only be utilized to accommodate FM requirements but also
sustain external changes made by the BIM tools. This is because FM
systems should not be modified if only BIM-specific requirements are
changed.
Therefore, this research proposes a semi-automated FM system
factory called EncapsulatingBIM4FM that applies model-driven archi-
tecture (MDA) to formalize the reuse of a BIM service for the devel-
opment of an FM system in FABs. Defined by the Object Management
Group (OMG), MDA can assist in the model transformation process to
expedite software development [25,26]. Once a software model is
precisely described using Unified Modeling Language (UML), the code-
generation tools of EncapsulatingBIM4FM can produce platform-spe-
cific source codes. The source codes generated may need a few custo-
mization efforts so as to become a full-fledged application, however.
Such middleware-based techniques have been investigated extensively
in the literature; nevertheless, no research has concentrated on such use
about adapting BIM tools for FM in FABs.
The manuscript is structured as follows. Section 2 reviews back-
ground information and related literature, including BIM integration
and MDA. Section 3 describes the proposed EncapsulatingBIM4FM used
in the FM domain, and Section 4 presents case studies of En-
capsulatingBIM4FM and the assessment results. Section 5 contains re-
search implications and future work discussions, followed by research
conclusions.
2. Background
2.1. Traditional methods of reusing BIM models for FM systems
Reusing BIM models for FM systems can be simply classified into
two types: reusing BIM data or reusing BIM functionality. Currently,
BIM reuse has been documented as one of the main concerns in the FM
domain, such as the report for the Sydney Opera House renovation
project [27]. The report suggested that if the level of BIM reuse can be
increased, the quality of the retrofitting project, including time and
271
Automation in Construction 102 (2019) 270–287
costs, can consequently be improved [27]. Previous researchers also
advocated developing tailored BIM templates (e.g. naming structure,
level of detail, object styles, line styles, units, export settings, etc.) that
suit particular reuse requirements for FM [17]. The following para-
graphs describe the two types of BIM reuse in detail.
Traditionally, standardized file formats such as industry foundation
classes (IFC) and construction operations building information ex-
change (COBie) have been proposed to define information fields that
are useful to FM systems and that can be provided by BIM tools in the
AEC domain [28–32]. Indeed, to ensure the quality of a BIM model
received in FM systems, a comprehensive data transformation plan is
needed, which requires considerable time and effort [13,28]. If such a
plan is not designed or conducted properly, it may lead to an incon-
sistent BIM model [28]. Such poor information sharing circumstances
may be exacerbated if a facility is being retrofitted, because the data
transformation plan may need to be performed multiple times [14].
The U.S. General Services Administration (GSA) published a series
of reports defining guidelines for BIM usage in different lifecycle phases
of a facility [33]. The GSA report specific to the FM domain suggests
that a centralized database be created to store BIM data [33]. Such
database-centric strategies imply that FM systems can use database
technology to integrate BIM and other external information. After re-
levant BIM data attributes are transferred into a database, the typical,
three-tiered software architecture (i.e., the presentation, business pro-
cessing, and database tiers) can be utilized to guide the operations of
FM systems [34]. In addition, one may transfer only the key attribute of
a BIM element into an FM database, and each element ID transferred
can serve as the query condition for FM systems to retrieve all relevant
information from different data sources, including BIM and equipment
suppliers' databases [33]. Another research has further suggested that
the design of such database schema for storing BIM data for FM usage
be performed as early as possible, preferably at the beginning of the
facility lifecycle [35]. Thus, FM systems can regard a BIM model as an
external database, and all database operations such as geometric/non-
geometric data retrieval and modifications to as-built data can be rea-
lized via this architecture [36,37]. Previous researchers also suggested
that the Extract-Transform-Load (ETL) process, derived from data
warehousing technology, be utilized to resolve the problems associated
with reusing BIM data for FM systems [38].
Nevertheless, transferring BIM data attributes into standardized file
formats or databases will eventually discard valuable BIM services
[3,39]. The benefits brought by the integration of BIM data into FM
systems might be more than offset by not reusing such customized BIM
services that focus on data-processing and/or transformation work.
Hence, several researchers have investigated how to reuse dedicated
services or plugin programs implemented in BIM tools. Lee et al. sug-
gested that building object behaviors (BOBs), created in BIM tools for
parametric modeling purposes, be reused in the facility's lifecycle in
order to maintain design constraints, especially for retrofitting a
building [40]. Nevertheless, the translation of such BOBs into actual
parametric definitions and constraints for FM systems is not automatic.
Additionally, BIM functions such as the retrieval of construction-related
data are not supported in BOBs. Shen et al. reviewed varied system
integration approaches, including web-based systems, distributed ob-
jects, software agents, and web services, for the AEC/FM domains [41].
They indicated that the use of a single central repository to store the
design information is not a viable option due to the fragmented nature
and adversarial behavior that characterizes the industry, and suggested
that distributed loosely coupled integration solutions be utilized [41].
Becerik-Gerber et al. presented an integrated graphical user interface
(GUI) that can show BIM elements, live sensor data from energy man-
agement applications, and work orders from traditional FM systems [4].
They argued that integrating certain functions of BIM tools and other
systems into an FM system can enhance the FM process [4]. They also
indicated that there exist a number of technological and organizational
challenges in extending BIM functionality for FM usage, such as the
C.-C. Hsieh, et al.
necessary but difficult procedure of involving BIM and/or CAD tool
providers [4]. Niu et al. presented a technique called smart construction
objects, which were designed to bridge the information gap between
the FM-related, as-built situation and the BIM model [42].
In summary, the reuse of BIM services has been successfully im-
plemented to facilitate the information exchange and interoperability
between different systems in the AEC domain, which can be regarded as
construction project-based interoperability [12]. There are some FM
domains that require high interaction between FM systems and BIM
models or tools [5,7], such as the FAB cases noted before. Present lit-
erature does not include a durable approach that, while reusing BIM
models, FM systems will not be affected by changes resulting from BIM
tools or version upgrades [43]. Lifecycle interoperability between BIM
models and all information systems in the AEC/FM domains can be
therefore achieved if such an approach exists.
2.2. Current practices of reusing BIM models in FABs
Both types of BIM reuse can be seen in various information systems
in FABs. Here, high precision, BIM-based geometry data sets are often
needed [7]. For instance, almost every FAB in Taiwan implements the
Facility Monitoring and Control System (FMCS), which needs the layout
and baseline data of each pipe and duct in order to function properly
[7]. Since some of the pipes and ducts are often adjusted and the ad-
justment work may be performed by different contractors or equipment
installers, it is crucial for FM stakeholders to keep track of every change
made to the original BIM models. The file-based transformation ap-
proach can be utilized to acquire needed FAB BIM model data, although
challenges remain, e.g., the poor data transformation performance.
Hence, the use of computer-aided design (CAD) tools to redraw the
geometry data sets for FM systems can be sometimes seen, which will
lose all BIM functionality as well as semantic information among BIM
elements. Currently, because more and more FAB owners are realizing
the importance of having their property managed by BIM tools, the use
of the BIM file-based transformation approach is becoming the norm in
such FABs producing microprocessors and memory chips in Taiwan [7].
Moreover, if the BIM data sets transferred do not meet FAB site-
specific requirements, customized BIM services need to be developed
and applied. For instance, an air handling unit can be associated with
zero to many nearby fans, depending on system configuration. Since the
traditional file-based transformation approach is developed for the AEC
domain, inconsistency or omission of equipment relationships could be
generated unless such relationships are rectified by a BIM service spe-
cializing in the configuration of air handling units. There are other BIM
services developed for expediting the exchange of information between
AEC and FM stakeholders because before the end of the construction
phase some tasks are planned and performed within hours in order to
commence FAB manufacturing work earlier [6]. The use of BIM APIs
seems to be able to ameliorate site-specific problems; nevertheless, the
aforementioned challenges such as multiple BIM tools and version up-
grades may hinder FM stakeholders from using BIM API approaches.
In addition, in the Emergency Response Center (ERC) of an FAB
much of its data-processing work can be characterized by space-centric
management [6]. In other words, ERC-related data sets are managed in
accordance with the spatial layout of an FAB, which is originally de-
fined in the AEC domain and maintained using BIM tools. For instance,
the Life safety Monitoring and controlling System (LMS), one of the
major applications in the ERC, will collect signals of each gas detector
to be analyzed with a data set containing the exact dimensions of each
space/room [6]. Since each type of spaces/rooms requires distinct
calculation of the dimensions, a customized BIM service may need to be
developed to return such information. Then, the LMS can identify po-
tential threats, to be broadcast to external applications such as the
Access Control (AC) system [6]. The AC system may ask BIM tools again
to locate evacuation routes in order to send commands to release door
locks associated with all impacted spaces/rooms [6]. As gas leakage
272
Automation in Construction 102 (2019) 270–287
could be detrimental to worker health and safety, Semiconductor
Equipment and Materials International (SEMI) has developed a series of
standards and guides for all FM stakeholders for adequately handling
such circumstances, in order maintain the quality of semiconductor
processing [44,45]. To help such gas leak detection and mitigation
work, customized BIM services have been developed to calculate and
obtain the spatial information [6], which can be regarded as reusing
BIM functionality for FM systems.
Lastly, BIM's 3D visualization functionality has long been appre-
ciated in many of the FM systems [7]. If such functionality can be in-
tegrated into FM systems, FM stakeholders can conduct daily work
while seeing the 3D version of relevant building elements, which has
been reported as an effective way to improve FM stakeholders' situa-
tional awareness [7]. In summary, the benefits brought by reusing BIM
models pertain to the information retrieval and interpretation for geo-
metry and/or base data of an FAB. Although such work accounts for a
small portion of the entire FM system functionality, it cannot be ne-
glected or set aside because of the geometry-based data sets tightly
linked to the semiconductor manufacturing and process control.
2.3. Problems associated with BIM APIs from FM view
As noted in the introduction and previous sections, simply trans-
ferring CAD or BIM data for FM systems may lower the reusability level
of BIM models, on both data quality and transformation performance
matters. Nevertheless, current BIM APIs are not designed for FM sys-
tems to reuse BIM models. Directly using BIM APIs may make an FM
system and its development work unstable, which means any slight
change from the BIM requirements side may lead to the re-development
of the FM system, consequently diminishing the asset value [14].
The reason behind this is that the modeling contexts of BIM and FM
are quite different. For example, in the AEC domain each BIM element
is constantly modified to represent the corresponding real-world
building component, such as IfcBuildingStorey. Such BIM elements can
be regarded as being processed in a dynamic environment because
designers or builders can frequently change the elements' geometric
properties and/or other data attributes. After the design and construc-
tion phases, the structure and major building components of a given
facility should not be altered for at least 50 years once finished, and
their corresponding BIM elements become anchored during this long
period of time. Thus, for example, in the AEC domain the number of
stories in a building is a design question, which can be answered by
invoking the corresponding BIM API. But because this number will not
be changed after the design and construction phases, FM systems prefer
using a constant number in lieu of the function call.
In addition to such redundant BIM APIs, there is a more funda-
mental modeling issue associated with current BIM API design. In the
AEC domain, a real-world building component or entity can be re-
presented in BIM tools as a software object. Similar objects can be
grouped into a class. Take as an example adding a story to a facility. In
the design phase, if a facility owner changes his or her mind, architects
may need to add a story accordingly, which can be interpreted as
creating an additional “Level” object in Revit. In IFC, the
“IfcBuildingStorey” class will instantiate an object for representing this
new, real-world story component. However, because it is rare to add a
story to a facility in the FM domain, modeling a real-world story
component as an object in this case might be inappropriate. A better
modeling strategy might be to model each physical story as a distinct
class because the concepts of these stories will not be changed over time
for this facility. Thus, for example, in the FM domain, one object or
instance of the “SecondStorey” class can represent the current main-
tenance condition of the real-world second story component at a spe-
cific time point. In the “SecondStorey” class, its static data attributes
can contain the BIM data, while the other attributes can store FM-re-
lated data. Therefore, it might be more reasonable to model a real-
world building component from the object level (in the AEC domain) to
C.-C. Hsieh, et al.
Fig. 1. Overview of the MDA.
the class level (in the FM domain). By applying this modeling strategy,
one can use a class to represent a real-world building component con-
sidering the requirements from both the AEC and FM domains, and FM-
related data and functions unique to this building component can be
added into the expanded class. For example, each story class in the FM
domain can contain its own budgeting functions for allocating re-
sources.
The proposed modeling strategy follows the basic principle of ob-
ject-oriented design, which suggests that each class take the minimum
number of responsibilities possible and form a cohesive design unit for a
given domain [46]. Theoretically, if a real-world building component
will not be changed in the FM domain, a software interface or a class
should be defined to correspond to it. Furthermore, literature shows
that in the FM domain the spatial layout of a facility, such as the fa-
cility's geometry and the relationships among rooms, stories, stairs, etc.,
principally determines how the facility is managed [5]. Since the spatial
layout will not be changed either, it is suggested that all the building
components relating to the spatial layout be modeled as classes.
Previous literature shows another example regarding the steadiness
of such BIM elements, and it indicates that when a user wants to set up
some FM system for the first time, he or she often need to re-create the
entire facility geometry data [28]. This redrawing work is considered to
be a waste of resources and efficiency but has been in practice for years,
because the geometry data are very stable and such redrawing work
needs to be performed only once in the FM domain [28]. Indeed, a BIM
data set is similar to the base data concept in database theory. It is the
FM-related, transaction-based data set that now becomes dynamic and
requires FM systems to provide sophisticated data-processing functions,
such as managing facility maintenance records [5,47].
Hence, in the FM domain if a spatial layout-related building com-
ponent is modeled as an interface or class, it should contain both the
static and dynamic types of data attributes, with the former derived
from the corresponding BIM element and the latter from FM require-
ments. Similar strategies can be found in other domains such as the
healthcare and management industries, and researchers there have
273
Automation in Construction 102 (2019) 270–287
utilized MDA technology to resolve the associated problem by auto-
matically transforming a model from a generalized repository to a
customized software application [48,49]. In summary, some of the BIM
APIs provide little assistance in the FM domain, while others are useful.
Tailoring BIM APIs to better accommodate FM requirements may be
needed.
2.4. Review of MDA
Developing modern software applications is facing increasingly
complicated situations. Not only are software requirements becoming
more versatile but also more platforms are involved [22]. In the note-
worthy book titled “The Mythical Man-Month”, Brooks states that as-
signing more programmers to a software development project running
behind schedule would be fruitless [50]. Recent software development
work often involves employing software reuse techniques in the hopes
of gaining better software quality while reducing costs [22,51].
MDA technology, in fact, is the OMG's solution to software reuse. In
essence, MDA uses a series of model transformation techniques so that
application developers can concentrate more on domain modeling work
[25]. If a domain model, described in UML, is complete and accurate, it
can be converted by MDA tools into corresponding source codes. Then,
developers simply need to add a few customization codes to finalize the
application, which ensures better quality and takes less time compared
with the traditional software development approach. MDA utilizes the
principle of separation of concerns to define the following three view-
points: (1) a computation-independent viewpoint (CIV), which focuses
on business requirements and contains none of the computer-related
processing details; (2) a platform-independent viewpoint (PIV), which
deals with the operations of a system but does not contain the details for
a specific platform; and (3) a platform-specific viewpoint (PSV), which
integrates the PIV with the details of using a particular platform as the
application environment.
Hence, four types of models and their transformation mechanisms
can be designed based on the three viewpoints, as shown in Fig. 1. A
C.-C. Hsieh, et al.
Fig. 2. Four layers of the MOF.
computation-independent model (CIM) is constructed to describe real-
world business operations and requirements, which are represented in
the CIV. By applying the model transformation rules for the CIM and by
considering the new requirements defined in the PIV, a platform-in-
dependent model (PIM) can be created to describe the same business
requirements but with computation-related needs. If the PIM is defined
comprehensively, a platform-specific model (PSM) can be generated
using the model-to-model transformation mechanism to incorporate the
corresponding PSV. The final model is the source codes that can be
obtained by using the model-to-code transformation mechanism for the
PSM, and the codes generated should be comparable to a full-fledged
application, which implies that application developers might need to
add a few codes to complete the development work.
The OMG also defines the meta-object facility (MOF) mechanism to
provide management of metadata and definitions of the modeling ele-
ments. The MOF mechanism consists of four layers, as shown in Fig. 2.
In the M0 layer, a run-time application/system can be described by
using a UML model, which is located in the M1 layer. In the M1 layer,
there may be many UML models for modeling different application
domains. Hence, a UML class defined in the M1 layer for one applica-
tion domain can instantiate many run-time objects that are located in
the M0 layer. Furthermore, in the M2 layer, the MOF mechanism de-
fines the notations and grammatical rules of the UML. The concepts of
Class, Association, and Attribute, which are often utilized to construct a
class diagram, are defined in the M2 layer. Hence, the modeling ele-
ments defined in the M2 layer can be used to create or instantiate a
specific UML model in the M1 layer. Finally, because not only software
systems but other types of systems also need modeling work, several
modeling languages are available for the M2 layer to provide modeling
assistance, such as Common Warehouse Metamodel (CWM) and Sys-
tems Modeling Language (SysML). Thus, the modeling elements of
UML, CWM, and SysML can be further abstracted into a set of more
274
Automation in Construction 102 (2019) 270–287
fundamental concepts, such as Class, which are defined in the M3 layer.
Again, the elements of the M3 layer can be used to create or instantiate
the elements of the M2 layer. In essence, objects with similar properties
and behaviors in the lower layer can be represented by their abstract
entity, i.e., a class, which is defined in the higher layer. To summarize
the MOF mechanism, abstraction of a class is called a meta class, which
is defined in the M2 layer and can create an instance located in the M1
layer. Abstraction of a meta class is called a meta-meta class, which is
defined in the M3 layer and can create an instance located in the M2
layer.
MDA technology has been utilized in industries such as the health
care and management industries [52]. Komatsoulis et al. proposed the
cancer Common Ontologic Representation Environment (caCORE),
based on MDA [48]. Blobel and Pharow investigated the German health
telematics architectural framework and security infrastructure and ar-
gued that health information systems have to provide intelligent in-
teroperability, because the organizations of the system users, structure,
behavior, data, and semantics are very different [53]. In fact, past lit-
erature shows that MDA technology has been sporadically applied to
the construction industry [54]. For example, the four layers of MDA
were utilized by Kubicki et al. to define multi-visualization of a co-
operative context for building construction activities [55].
To conclude, current computer-aided software engineering (CASE)
tools that support MDA often utilize the MOF mechanism and pre-
defined rules to facilitate model transformation work. CASE tools can
operate in the higher layer to read metadata information about the
lower layer in order to generate appropriate source codes. Hence, ap-
plication developers can concentrate more on domain modeling work
and use such CASE tools to expedite the software development process.
Nevertheless, such tools have not been seen in the field for integrating
BIM into FM systems.
C.-C. Hsieh, et al.
Fig. 3. New meta-model hierarchy for a building.
3. Proposed approach
3.1. Wrapping BIM elements for FM
Research has shown that an as-maintained model of a building is
needed to support FM systems in the management of the current status
or condition assessment results for critical building components and
equipment [56,57]. In such models, data fields are associated with the
space and time dimensions and, consequently, BIM tools can be used to
supply the location and geometry-related data to FM systems. Hence, a
BIM element as well as its counterpart FM object might need to be
combined together to represent the corresponding real-world building
component. The former should possess location and geometric data,
while the latter should contain time-dependent data as well as a link to
the BIM element.
Fig. 3 shows the modified MDA that can accommodate both BIM
and FM needs. For instance, assume that in a residential building a
machinery room contains a permanently installed air-conditioning
system and other critical devices. The room needs to be inspected once
a month to ensure everything works properly. Therefore, an FM system
is created to manage these inspection records, and one inspection re-
cord of the machinery room at a specific time point could be modeled as
an object, whose class is “A-MachineryRoom”, i.e., the machinery room
in “Residential Bld. A”, as shown in the bottom of Fig. 3. In the M0
layer, each of the three objects records the inspection results for all
devices in the machinery room on a given day, and other FM-related
data can be recorded here as well. In the M1 layer, the building, i.e.,
“Residential Bld. A”, contains two stories, i.e., “A-Storey 1” and “A-
Storey 2”. Each story includes several rooms, and each room contains
several components such as windows, doors, and devices. All of the
classes defined in the M1 layer are specific to “Residential Bld. A” and
can be regarded as the backbone of an as-maintained model for the
building. The model is designed based on the spatial layout of the
275
Automation in Construction 102 (2019) 270–287
building and can accommodate more FM requirements by adding re-
levant attributes and/or functions as well as new classes. Note that the
relationships between “Residential Bld. A”, “A-Storey 1”, “A-Storey 2”,
and the rooms are fixed in the M1 layer, while they are changeable and
can be modified in the M2 layer during the design and construction
phases. For simplicity, any building components inside a room will not
be modeled as individual classes, such as windows and doors, because
they play a less important role from the perspective of tradesmen.
In Fig. 3, the M2 layer needs to deal with major, generic building
components, such as room/space and story. The abstraction level of
these building components is similar to that of the classes defined in the
IFC specification, e.g., IfcSpace and IfcBuildingStorey. In fact, the de-
finition of each class in the M2 layer has to be very general because it
will instantiate various objects, each representing a unique, real-world
building component. In other words, in BIM tools, the “Room/Space”
class represents the general concept of a room or a space, and its object
is the actual entity BIM users draw on the screen.
Furthermore, one can define the most generic concept for the
building industry as the BuildingSuperObject class, which can be re-
garded as the meta class to instantiate various classes used in BIM tools.
Since the BuildingSuperObject class is located in the M3 layer, from an
FM system user's viewpoint, it can be regarded as a meta-meta class.
Therefore, the BuildingSuperObject meta-meta class instantiates meta
classes such as IfcBuilding and IfcSpace. The meta classes instantiate
classes such as “Residential Bld. A” and “A-MachineryRoom.” Finally,
the classes instantiate objects as shown in the M0 layer of Fig. 3.
Fig. 4 shows the same example with the considerations of FM-re-
lated attributes. In the AEC domain, one can use a class diagram (see
Fig. 4(a)) to define common attributes and relationships between the
classes used in BIM tools, such as building, story, and room. The UML
object diagram shown in Fig. 4(b) can be used to describe the actual
BIM elements drawn on BIM tools. For example, each room drawn on
BIM tools will contain an attribute called ElmID to represent its element
C.-C. Hsieh, et al.
Fig. 4. Building elements modeled in the AEC and FM domains.
ID. However, in the FM domain, an object defined in the design and
construction phases to represent a major building component will now
become a class under EncapsulatingBIM4FM, such as “A-Machinery-
Room”, as shown in Fig. 4(c). Within these classes, there are BIM- and
FM-related attributes. Reusable BIM data should be modeled as static
attributes with corresponding initial values. FM-related data such as
MaintenanceBudgets can be added into a class as normal attributes so
that a real-world building component can be fully represented by the
two types of data attributes. Overall, the BIM-related, static data at-
tributes with initial values will be accessible to all of the objects per-
taining to the same class. Each object of such a class can be used to
represent the current inspection record for a specific building element,
and the object's member-wise, normal attributes serve as the actual data
bank to store the FM-related, time-dependent data.
Regarding the reuse of a customized BIM service, a parent class is
created for the family of classes whose meta class is the same, except
the class representing the building itself. Fig. 5 shows the revised class
diagram for the aforementioned strategy. For example, in the FM do-
main, the two classes “A-Storey 1” and “A-Storey 2” have the same meta
class, “Storey”, which is an ordinary class defined in the AEC domain.
Because of this, a parent class (A-Storey) is created to include all cus-
tomized BIM services in order to be reused later by the child classes
(e.g., “A-Storey 1” and “A-Storey 2”). The same modeling strategy can
be applied to “A-Room” as the parent class and “A-Room 101”, “A-
MachineryRoom”, and “A-Room 201” as the child classes. In this way, a
customized BIM service originally defined in the AEC domain can be
reused by FM systems because it is defined again in the corresponding
parent class.
Reusing customized BIM services can not only lessen the complexity
of developing an FM system but also increase the information quality of
a building's digital assets. Under EncapsulatingBIM4FM, all updates on
the BIM data are carried out using the original BIM tool so as to keep
276
Automation in Construction 102 (2019) 270–287
the BIM data set up-to-date and to let FM systems reuse the customized
BIM service to retrieve the new query result. In addition, the parent
class should contain BIM-tool-specific codes in order to delegate all
incoming requests to the BIM tool. Thus, FM system developers can
focus on writing codes in the child classes, which include defining FM-
related attributes and customizing FM-specific functions. Each child
class can inherit the static BIM data attributes as well as the customized
BIM services from its parent class.
3.2. Software architecture of EncapsulatingBIM4FM
This section presents the proposed EncapsulatingBIM4FM software
factory, which follows the modified MDA/MOF mechanism in order to
create a middle layer that can integrate the BIM elements possessing
valuable data attributes and reusable services into an FM system. Unlike
traditional MDA, EncapsulatingBIM4FM requires FM system developers
to provide not only a UML model designed for their FM requirements
but also a BIM file containing their building model data. The underlying
BIM tool will serve as a service provider to the FM system for executing
selected BIM services.
Fig. 6 shows the overall software architecture of En-
capsulatingBIM4FM, which consists of the four tool components (Re-
vit2UML/Tekla2UML, Parser, Code Maker, and Project Builder) for
assisting in different types of FM system development work. Inside the
architecture, there are three tool environments (Revit/Tekla, Umbrello,
and Visual Studio) dedicated to providing varied system development
platforms. In this research, the BIM authoring tool can be either Revit
2015 or Tekla Structural Designer 2015i (using Open API 21.1). Um-
brello 2.15, which is a UML model editing tool based on KDE (K desktop
environment), is used for the creation and modification of UML models,
because it fully supports XMI (XML metadata interchange), the standard
defined by the OMG for exchanging metadata information via XML.
C.-C. Hsieh, et al. Automation in Construction 102 (2019) 270–287

Fig. 5. Class diagram for sample building elements and their parent classes.

Finally, because both Revit and Tekla allow application developers to
craft a customized BIM service using Visual Studio, and because a
general-purpose integrated development environment is needed for
crafting a green-field FM system, Visual Studio 2013 C# Version is
selected as the development platform. Each of the proposed tool com-
ponents is described in more detail as follows.
3.2.1. Revit2UML (or Tekla2UML)
When an FM system is being developed, there are three types of
models, i.e., BIM, UML, and the application source codes model, that
need to be reviewed and/or customized, as shown in left side of Fig. 6.
Developers can use Revit or Tekla to review the BIM model and use
Revit2UML or the likes to transform it into the UML model. For

Fig. 6. EncapsulatingBIM4FM architecture.

277
C.-C. Hsieh, et al.
illustrative purposes, since theoretically any BIM model can be de-
scribed using the ifcXML standard [31], the following pseudo codes
show the transformation rules of such 2UML tools based on an ifcXML
BIM file:
Input: an ifcXML BIM file.
Output: the UML XMI file
Goal: Transform the IfcBuilding, IfcBuildingStorey, and IfcSpace
objects in ifcXML into individual classes in UML.
Algorithm:
Create the UML building class with needed static attributes.
For each storey in XPath(//IfcBuilding/IfcBuildingStorey)
Create the given storey class with a link to the building class.
Create needed static attributes.
For each room in XPath(//IfcBuilding/IfcBuildingStorey[@
Name='a storey name']/IfcSpace)
Create the given room class with a link to the storey class.
Create needed static attributes.
End for
End for
Assume that each BIM file contains only one building, and each
level or story element has a distinct name. The first for-loop is utilized
to retrieve each story of the building via an XPath query and to create
the corresponding UML story class. The inner for-loop is utilized to
generate a similar room class structure inside a story class. Although the
UML class diagram generated represents just the skeleton of a given
building, it can contain needed BIM attributes, which will be created as
static attributes in the corresponding UML classes. FM-specific in-
formation will be added later, however.
To accelerate the system performance, PostgreSQL with PostGIS (an
open-source database capable of processing spatial data) is utilized to
help the initial value loading work. A table is created to store the origin
point and the oriented bounding box (OBB) of each building element
extracted, along with relevant BIM element attributes. Detailed ex-
planations of the table design, the use of the OBB technique, and the
performance acceleration mechanism for such FM systems can be found
in the report prepared by the research team [58].
3.2.2. Parser
After running the Revit2UML tool, developers need to revise the
UML model to accommodate FM requirements, such as adding FM-re-
lated attributes. Then, they can use Umbrello again to generate the draft
version of the application source codes, which contain both static and
member-wise attributes. However, the application source codes gener-
ated still lack important features, such as the inheritance structure
shown in Fig. 5 and the mechanism regarding retrieving the static at-
tributes from the spatial database. Hence, the Parser tool is designed to
resolve this issue. It can apply patches to the draft version of the source
codes in order to create source codes that can correctly describe the
overall structure of an FM system, including each parent class needed in
the inheritance mechanism for each story and room class. The following
pseudo codes show the transformation rules of Parser:
Input: the UML XMI file.
Output: the C# source codes with parent classes but without any
reusable BIM services
Goal: Transform each UML class into the corresponding C# source
code and the parent class if applicable, some with static attributes for
BIM data.
Algorithm:
For each UML class in XPath(//packagedElement[@
xmi:type = “uml:Class”]).
Let x = the XMI element of this class.
Let xCol = x.XPath(//ownedAttribute[@isStatic = “true”]).
If x.name = “the building name” Then
For each y in xCol
Create the loading code for the static attribute y
End for
278
Automation in Construction 102 (2019) 270–287
Else
Let z = x.XPath(//generalization[@xmi:type="uml:Generalization
"])
If z = null Then
Create the parent class code based on x
End if
Create the inheritance code to link the parent class z inside x
For each y in xCol
Create or update the loading code for the static attribute y inside z
Remove the static attribute y inside x
End for
End if
End for
Detailed descriptions regarding the UML XMI format can be found
at the book authored by Iqbal [26]. The Parser tool will add a C# parent
class for each existing BIM-oriented class, except for the building class.
Since the UML model contains all reusable BIM data as static attributes,
Parser needs to remove the original static attribute definition in each
child class and to add it in the corresponding parent class with the
initial value loading code. Note that Parser is independent of any BIM
platforms but contains source codes specific to Visual Studio and
PostgreSQL environments. This is typical for FM systems due to the use
of database programming.
3.2.3. Code maker
Because the current IFC/ifcXML specification does not contain in-
formation fields to describe any customized BIM services. Hence, for a
story or room class in the FM domain, developers need to use Umbrello
to add each reusable BIM service function by prefixing “ncubim_” to its
function name. Then, the Code Maker tool can be utilized to create the
delegation mechanism so that each child class can delegate such func-
tion calls to its parent class, and the base function of the parent class
will actually process a request/response message sent between the
parent class and the message queue. The following pseudo codes show
the transformation rules of Code Maker:
Input: the UML XMI file
Output: the C# source codes with parent classes as well as reusable
BIM service function calls stored in the message queue
Goal: Transform each designated UML operation into the corre-
sponding C# source code with the delegation mechanism, i.e., call the
base function defined in the parent class, which will handle the function
call message.
Algorithm
For each UML operation in XPath(//ownedOperation[@
xmi:type = “uml:Operation”]).
Let x = the XMI element of this operation.
If x.name Contains “ncubim_” Then
Let y = x.XPath(..)
//y is the class containing the operation x
Let zid = x.XPath(../generalization[@general])
//zid is the ID of y's parent class
Let z = XPath(//packagedElement[@xmi:id=zid])
//z is y's parent class
Create the delegation code for x inside y
If the handling code does not exist in z's operation Then
Create the handling code for the function call message sent between
z and the message queue
End if
End if
End for
More specifically, this research assumes that each input/output
parameter of such functions should pertain to the alphanumeric data
type. This is because all such services later will be adapted for the web
service version, so that FM systems can invoke them without having
strong coupling relationships with the BIM tools. Note that the source
codes generated by Parser and Code Maker are derived from FM
C.-C. Hsieh, et al.
requirements, and they are dependent on the interfaces (function names
and input/output parameters) defined in the parent classes, not the BIM
tools. If the interfaces are well designed, BIM tool changes will not
affect the FM systems (see the pre-processing part of the application
model shown in Fig. 6).
3.2.4. Project builder (for Revit or Tekla)
As noted previously, an FM system still needs Revit or Tekla to
actually supply BIM data and to run selected BIM services. Thus, the
Project Builder tool is designed to add BIM tool-specific source codes to
finalize the message handling work, so as to actually invoke customized
BIM services. It does not require the UML XMI file, which means it is
independent of FM requirements, but needs a list of customized BIM
services. First, Project Builder will generate the web service version for
all selected BIM services, using the Visual Studio built-in mechanism.
Then, a message controller, located inside Revit or Tekla, will be gen-
erated to handle the message queue and to dispatch each message to the
corresponding BIM service.
Finally, once the work of the Project Builder tool is done, FM system
developers can use Visual Studio to open the project to perform further
FM-related development work in order to deliver the final, full-fledged
FM system (also called the post-processing part of the application
model, see Fig. 6).
3.3. MDA mapping of EncapsulatingBIM4FM
In EncapsulatingBIM4FM, FM system developers need to consider
two types of software application requirements. The first type is related
to BIM, while the second type is related to the FM domain. Normally,
software developers can design a CIM based on the second type FM
requirements. For the first type, however, because at this stage an as-
built BIM model of the given building is available, the CIM developed
should also accommodate the requirements derived from the BIM
model. Currently, both Revit and Tekla can be employed as the BIM
platforms in EncapsulatingBIM4FM, and the research team is devel-
oping the IFC2UML version, which relies on the OpenBIM/xBIM toolkit,
an open-source implementation for BIM and IFC. In the future, other
BIM platforms will be employed, and model transformation tools such
as RhinoPython2UML, ArchiCADGDL2UML, and AECOsimMVBA2UML
will be developed so that an FM system can reuse the data attributes
and customized services from different BIM platforms.
Once the modeling work associated with the CIM is complete, a PIM
should be developed, which is described entirely using UML. On the
BIM requirement side, for instance, developers can use the Revit2UML
tool to transform a Revit file into a UML class diagram that contains the
spatial layout of a building, among others. On the FM requirement side,
developers can add new attributes, relationships, sequence diagrams, or
other UML constructs into the UML model. It should be noted that most
of the classes and relationships in the UML class diagram are generated
based on the BIM requirement side, which implies that for the FM
system under analysis, its key information-processing tasks should
pertain to space-centric management and that the smallest management
unit should be a room or space. Finally, once the PIM (i.e., the UML
model) is complete, the Parser, Code Maker, and Project Builder tools
will be utilized to transform the PIM into the PSM, i.e., the complete
source codes of the application.
3.4. New FM system based on EncapsulatingBIM4FM
The collaborations between the BIM tool and a new FM system are
elaborated in this section.
3.4.1. Internal components of an FM system
Using EncapsulatingBIM4FM, an FM system consists of the client
and server programs, as shown in Fig. 7. The client program is FM-
oriented and includes the GUI application, FM objects, and the FM
279
Automation in Construction 102 (2019) 270–287
database. The server program is BIM-oriented and includes BIM objects,
the message queue with the database, the message controller, and
customized BIM services. FM system developers are responsible for
crafting the client program; however, the majority of the server pro-
gram will be generated by using EncapsulatingBIM4FM. The following
paragraphs describe each component of the FM system in detail.
The GUI application contains user interfaces with control logic and
utilizes the application model to manipulate the FM objects, which can
be interpreted as child classes (e.g., “A-Room 101” in Fig. 5) to re-
present the as-maintained model of a given building. As noted pre-
viously, part of the source codes of the FM objects are generated by
EncapsulatingBIM4FM, and both the GUI application and FM objects
contain none of the BIM-specific codes; thus, such an FM system will be
more stable compared with the one using embedded BIM APIs. In ad-
dition, the FM objects may use the FM database to manage relevant
data, such as maintenance records and sensor data.
While the FM objects can be classified as child classes, the BIM
objects can be interpreted as parent classes (e.g., “A-Room” in Fig. 5).
All the source codes of the BIM objects are generated by En-
capsulatingBIM4FM, so that the corresponding BIM services can be
seamlessly reused by the FM objects. It should be noted that currently
both Revit and Tekla require that their customized BIM services (add-in
in Revit and Open API program in Tekla) dwell only in their underlying
BIM platform; hence, an external system needs to include specific li-
braries and environments to invoke a BIM service. This is also the main
reason why a strong coupling relationship exists between an FM system
and the BIM tool in the traditional system configuration.
To resolve this problem, the web services mechanism with message
queuing is utilized to transport the messages sent between the FM and
BIM objects. The FM objects are the web service consumer, and the BIM
objects play as the web service provider. If each function parameter
defined in the BIM objects pertains to the alphanumeric data type,
EncapsulatingBIM4FM will add “[WebMethod]” to the beginning of
each such function in order to ask Visual Studio to automatically adapt
such functions into the web service version. In this way, the BIM object
will store each incoming request from any FM objects into the message
queue. Then, the BIM object will periodically check the queue for any
response message from the BIM service and will return it to the desig-
nated FM object once found. In other words, the client and server
programs can be deployed in different machines and be developed
using different programming languages and environments due to the
use of web services.
If Revit is utilized, both the message controller and every custo-
mized BIM service are implemented as Revit add-in programs, with the
former generated by EncapsulatingBIM4FM and the latter developed by
Revit developers. In Tekla, they are implemented as Open API pro-
grams. Following the previous discussion regarding the message queue,
the message controller can periodically check the queue for any request
message from the BIM objects and will execute the corresponding BIM
service. Once the service result can be obtained, the message controller
will prepare a response message and place it into the queue, which will
then be retrieved by one of the BIM objects.
The use of EncapsulatingBIM4FM can facilitate the development of
an FM system, because developers can add new attributes and functions
into FM objects entirely based on FM requirements; meanwhile, they
have the ability to reuse BIM data attributes and customized services
via the aforementioned mechanism. Further, the use of
EncapsulatingBIM4FM can reduce the coupling effect between the FM
system and the BIM tool, because any change on the BIM tool side will
not propagate changes on the client program, which is essential to FM.
3.4.2. Changes on the BIM data, services, or tool
As noted previously, an FM stakeholder may want to use another
BIM tool or a newer version of the original BIM tool to manage the
building's digital assets. Detailed scenarios regarding the changes or
upgrades of BIM tools are elaborated below:
C.-C. Hsieh, et al.
Fig. 7. Structure of a new FM system based on EncapsulatingBIM4FM.
(1) If the BIM model or service needs modifications and if both the web
service interfaces and the BIM tool are unaltered: In this common
scenario, BIM model data or customized BIM services need to be
modified to reflect the changes. Since the building's spatial layout
remains the same, no additional actions will be needed in the FM
system.
(2) If the BIM platform is changed or upgraded but the spatial layout of
the building is not altered: In this scenario, there is no need to run
Revit2UML or Tekla2UML. The UML model generated by the ori-
ginal 2UML tool is correct even though the BIM platform is
changed. Hence, only the Project Builder tool needs to be modified
to generate correct project settings and corresponding source codes
based on the new BIM platform, so that EncapsulatingBIM4FM and
the FM system can cooperate well again. This is because changing
the BIM platform will not affect the pre-processing part of the ap-
plication model (see Fig. 6). In other words, only the message
controller as well as all the customized BIM services need to be
modified based on the new BIM platform. No change will occur in
the other components of the FM system. It should be also noted that
the message controller is not dependent on FM requirements;
hence, once the Project Builder tool is updated, it can be reused
again for all FM systems where their BIM tools use the new version.
(3) If both the BIM platform and small portions of the building's spatial
layout are changed: For example, some rooms may need to be
merged or retrofitted to improve the accessibility. Since the UML
model should always correspond to a building's spatial layout, one
can either manually modify the UML model to accommodate such
changes or revise the corresponding 2UML tool to automatically
generate a UML model with the correct spatial layout. Then, since
the Parser/Code Maker tools operate purely on UML models, they
can be utilized again to generate the new source codes of the BIM
and FM objects. Note that because the parent class of all the room or
story classes is the same, only the source codes pertaining to se-
lected child classes (e.g., the retrofitted rooms) need to be updated.
The rest of the modification work is the same as described in the
previous scenario, which implies that the Project Builder tool, the
message controller and all the customized BIM services need to be
revised to accommodate the new BIM platform.
In summary, the use of EncapsulatingBIM4FM can generate a set of
software interfaces specifically designed for the building, whose
maintenance-related data are managed by the FM system. Such a
wrapping mechanism can ensure that the BIM data attributes and ser-
vices can be reused by the FM system in accordance with the building's
spatial layout. Furthermore, the coupling effect between an FM system
and its BIM tools can be lessened because the FM system is no longer
dependent on any of the BIM APIs. Such arrangement of the FM sys-
tem's internal components allows FM and BIM requirements to evolve
independently without affecting each other's development work.
280
Automation in Construction 102 (2019) 270–287
4. Example and evaluations
4.1. Pilot system requirements
In Taiwan, an earthquake fault passes through the Hsinchu Science
Park (HSP), which is a highly concentrated manufacturing area for
semiconductor chips and liquid crystal displays, respectively estimated
at about 49% and 33% of worldwide production [8]. Here local gov-
ernments constantly require that each FAB in the HSP prepare damage
assessment reports to describe the conditions of selected equipment and
building components after the occurrence of an earthquake, in order to
define appropriate disaster mitigation plans for the future. Recently, the
research team was invited to utilize EncapsulatingBIM4FM to develop a
pilot system for one of the FABs, and the staff from the FM and in-
formation technology (IT) departments joined the development. Firstly,
the research team introduced the research background and objectives to
the staff. The staff expressed that, because they presently complete the
reports without using any information systems, and because tailoring
their current FM systems, e.g., Maximo, to such assessment needs would
be a costly operation, they would like to see how efficient and effective
EncapsulatingBIM4FM is in integrating BIM into the pilot system. It
should be noted that the pilot system discussed here was for demon-
strating EncapsulatingBIM4FM and thus might lack features pertaining
to earthquake damage assessments at other FABs.
A central utility building (CUB) of the FAB with two BIM models
was selected, one in Tekla to represent structural components and the
other in Revit to represent architectural and HVAC components.
Important requirements of the pilot system were gathered and com-
piled. First, since each room of the CUB contains different types of
equipment, an assessment form needs to be room-specific, meaning that
some rooms may associate with lots of assessment fields while others
may not. Second, users of the pilot system need to review an assessment
report along with the 3D view of that scene. Traditionally this re-
quirement is complicated considering that every several months certain
floors in the CUB may need to be raised or lowered for adjusting the
hidden voids for the passage of new mechanical and electrical devices.
Typically, FM stakeholders will preserve every BIM model whenever
changes occur, so that a specific date version of the BIM models can be
rendered with its assessment report. The final requirement is about the
BIM tool upgrade. The pilot system was initially implemented using
Tekla 2015i and Revit 2015 in order to be compatible with the existing
FAB BIM models. The IT staff would like to take this opportunity to
upgrade Revit from 2015 to 2017.
Detailed requirements regarding the new FM classes of the pilot
system are described here. Principally, if a room of the CUB contains
critical equipment and devices, the room object will have an association
relationship with a Template object and include an array of
Assessment objects. The Template class defines the data fields needed
in an empty damage assessment plan, which involves the name of a
given template, the template planner, the template creation date, and
C.-C. Hsieh, et al.
Fig. 8. Class diagram for the pilot system.
an array of CheckItem objects. Each CheckItem object represents an
empty assessment form for a given device and contains its associated
inspection questions as well as the corresponding ViewAngle object,
which implies that an FM system user can ask BIM tools to show the
critical device at the specific angle. In fact, a room object describes the
overall assessment results of the room on a specific day, which involves
a set of links to the corresponding Assessment objects. The actual as-
sessment result for a device is recorded in the Assessment object, while
a Template object and its accompanying CheckItem objects can be
used jointly to describe an empty damage assessment plan with blank
forms for a room and all of the devices inside. Fig. 8 shows the UML
class diagram for the pilot system.
Since two BIM tools will be involved in the pilot system, their
reusable BIM services are summarized here. A Tekla service function
called ncubim_GetElmDimen() is reused by the pilot system. It re-
quires a room element ID and will return an XML string describing the
dimensions of all the structural elements of the room. For Revit, the
three reused service functions are: (1) ncubim_ShowElement(), which
requires an element ID and a viewing angle (i.e., nine floating numbers
for the eye position, the up and forward unit directions) and will show
the 3D view of the element based on the given viewing angle; (2)
ncubim_GetEquipSupplierInfo(), which requires a room element ID
and will return all its equipment and devices with suppliers information
as an XML string; and (3) ncubim_CalAffectedDimen(), which requires
a room element ID and will return the adjusted dimensions of the room
as an XML string. It should be noted that no change will occur in the
Tekla model because structural components cannot be adjusted.
4.2. Steps of using EncapsulatingBIM4FM
Fig. 9 shows the overall steps of using EncapsulatingBIM4FM. The
research team introduced the proposed approach, and the IT staff fol-
lowed the steps to craft the pilot system with the research team's as-
sistance. Each swimlane in Fig. 9 indicates the tool used by developers
to complete one or more development tasks.
281
Automation in Construction 102 (2019) 270–287
In “Step 1: Open BIM Model”, a developer can use Revit or Tekla to
open a designated BIM file representing the CUB. After verifying the
level of detail constraint of the BIM model [58], in “Step 2: Execute
Revit2UML or Tekla2UML”, the developer can run the tool to transform
the BIM model into the UML model. It should be noted that because
only some of the rooms in the CUB contain critical equipment and
devices, the developer can select these valuable rooms and their cor-
responding levels to generate the classes that require further pro-
gramming work. Then, the developer can use Umbrello to open the
preliminary UML model and revise the class diagram generated (Step
3). He or she can also design new sequence diagrams (Step 4). A class
that is generated based on the spatial layout of the CUB already pos-
sesses BIM-related attributes, which are static and may be shared
among its instances with respective initial values. Developers can add
new FM-related attributes to such classes. Alternatively, they can create
a new class for representing an FM-specific concept such as ViewAngle.
Once the design of the sequence diagrams is finished, the developer
can perform “Step 5: Umbrello's Code Generation Wizard”, which
means Umbrello can generate the draft version of the application source
codes. The developer can even perform Steps 3–5 back and forth in
order to obtain a better UML model with the correct class and sequence
diagrams. Detailed descriptions regarding the BIM and UML design
guidelines for the class and sequence diagrams can be found in the
report prepared by the research team [58].
In “Step 6: Adjust source codes for C# classes”, the developer can
launch the Parser tool. It will adjust the source codes to create correct
class inheritance hierarchy. The developer can then perform “Step 7:
Generate source codes for sequence diagrams” in order for the Code
Maker tool to generate the dynamic aspect of the source codes, in-
cluding the delegation mechanisms for reusing selected BIM plugin
programs. Then, the developer can perform “Step 8: Generate source
codes for Revit add-in or Tekla Open API” and specify the parameters in
order for the Project Builder tool to generate a real Visual Studio project
with appropriate Revit add-in settings as well as to apply a Revit-spe-
cific code patch to the parent classes (BIM objects). In “Step 9: Add
C.-C. Hsieh, et al. Automation in Construction 102 (2019) 270–287

Fig. 9. Steps for using EncapsulatingBIM4FM.

Fig. 10. Changing the viewing angle in the pilot system.

282
C.-C. Hsieh, et al.
application-specific codes”, the developer can design a user interface
for each room so that users can complete the assigned inspection work,
write additional codes to handle the user interfaces and to process BIM/
FM data, review the source codes previously generated. Finally, the
developer can perform “Step 10: Build FM application” to actually
implement the FM system. Fig. 10 shows one of the forms of the pilot
system and implies that an FM system user can ask Revit to show the
critical equipment and device at the specific angle. In the pilot system
case, the client/GUI program, Revit, Tekla, and Controller are in fact in
the same computer, and Controller periodically checks the message
queue. The client program will ask users to provide input parameters in
order to ask Controller to actually finish the task inside Revit.
The CUB consists of four stories and 125 rooms or spaces. Detailed
descriptions regarding the BIM and UML design guidelines can be found
in the report prepared by the research team [58]. Since Revit 2015
should be upgraded to the 2017 version, the developers modified the
three Revit service functions in accordance with the manual of Revit
2017 Software Development Kit. Then, the developers utilized Revit
2017 to open the BIM model and to run the Project Builder for Revit
2017 version. Once the aforementioned tasks were finished, the pilot
system worked well again with Revit 2017 and Tekla 2015i under En-
capsulatingBIM4FM.
4.3. Evaluations of EncapsulatingBIM4FM
This section presents two evaluations conducted for proving the
concept of EncapsulatingBIM4FM. The first evaluation aimed at mea-
suring the performance of the pilot system, because
EncapsulatingBIM4FM cannot be regarded as a workable approach if
the system performance is slow. The second evaluation aimed at as-
sessing the efficiency and effectiveness of EncapsulatingBIM4FM under
different usage contexts. The following paragraphs describe the details.
In the first evaluation, since EncapsulatingBIM4FM adds another
layer for FM systems to invoke a BIM service, the added time resulting
from the layer should be measured. At first, the research team injected a
logging code fragment into each of the BIM services to verify whether
all BIM requests originating from the client program were correctly
carried out in the corresponding BIM tool. The results showed that all of
the BIM requests were received and successfully performed by the BIM
tool. Then, the research began to measure the performance of
EncapsulatingBIM4FM, by modifying the logging code fragments to
measure the added time. Every BIM service was executed eleven times
in order to calculate an average value. This is because in modern in-
formation systems, the initial execution of a function call may take
longer time, compared with the following executions [22].
Table 1 lists the performance results of invoking a BIM service, in-
dicating the average time needed for a BIM object and the message
controller to process each request and response message. It should be
noted that the actual time needed for executing a BIM service is de-
pendent on how the service is implemented inside the BIM tool and is
not included in the Table 1. In summary, less than one additional
Table 1
Average times needed for a BIM object and the message controller to process a
request and response message for invoking a customized BIM service.
Customized BIM service Added time Average added
for the first time for each
call following call
ncubim_GetElmDimen() in Tekla 0.531 s. 0.037 s.
ncubim_ShowElement() in Revit 0.503 s. 0.045 s.
ncubim_GetEquipSupplierInfo() in Revit 0.512 s. 0.018 s.
ncubim_CalAffectedDimen() in Revit 0.557 s. 0.032 s.
Average added time for invoking any one of 0.526 s. 0.033 s.
the BIM services utilized in the pilot
system
283
Automation in Construction 102 (2019) 270–287
second is needed when using EncapsulatingBIM4FM to invoke a BIM
service.
In the second evaluation the basic validation strategy was to invite
experts to assess the efficiency and effectiveness of
EncapsulatingBIM4FM. Here, the efficiency was measured with respect
to the efforts required to develop and to maintain an FM application
using the traditional or new approach (which will be introduced
below). Since the quality of BIM models is always the key to successful
management of a facility's lifecycle information, the effectiveness of
EncapsulatingBIM4FM was measured in terms of quality improvement
for BIM models using the traditional or new approach. The research
team, together with the previous FM and IT staff, analyzed possible
contexts of reusing BIM for FM, and four usage contexts were gen-
eralized from the pilot system, described as follows:
(1) FM application helping the transformation of part of the BIM/CAD
data for FAB operations: As indicated by the FM staff, they often
require a small portion of the BIM/CAD data for varied daily op-
erations, and the data set obtained must contain the latest version
of selected elements geometry. In the traditional approach, they
employed customized applications to load the needed BIM/CAD
data. Certainly, such an application requires the assistance of the IT
staff who knows how to use BIM APIs. In the new approach, the
research team re-developed one application using
EncapsulatingBIM4FM to generate the same information as listed
using the traditional approach. For instance, during equipment
move-in or move-out processes, contractors frequently send the
BIM/CAD models to the ERC for checking any new spatial mod-
ifications against existing SEMI standards, and they hope that the
ERC can respond to this request as soon as possible. Currently
several customized applications have been developed for such data
extraction purposes by directly using BIM APIs. One of the appli-
cations was selected for this usage context.
(2) FM application asking the BIM tool to perform specific BIM ser-
vices: There are varied applications throughout the FAB that fit the
aforementioned usage description. The research team selected one
existing application as the traditional approach, which utilized BIM
APIs to show tabular information regarding equipment suppliers.
Then, the research team re-developed the application using
EncapsulatingBIM4FM as the new approach.
(3) FM applications asking both Revit and Tekla to perform specific
BIM services: Although it would be better to use one integrated
application to obtain all needed data sets from the two BIM tools,
the research team selected two existing applications as the tradi-
tional approach and re-developed them separately based on
EncapsulatingBIM4FM as the new approach, in order to maintain
consistency for this validation. Both approaches calculated and re-
trieved the dimensions of selected BIM elements. The reason behind
the use of Tekla BIM services was that the design team of the FAB
has extensive experience in FAB engineering and possesses several
Tekla BIM services for advanced parametric calculation. Thus, the
traditional approach simply copied the output of one Tekla BIM
service, while in the new approach the research team developed a
wrapper function inside the Tekla programming environment to
directly reuse the original service.
(4) FM applications asking two Revit versions to perform specific BIM
services: The 3D visualization function such as the one shown in
Fig. 10 has been implemented in several FM applications in the
FAB, by using different libraries and techniques. The research team
selected two such applications (one relied on Revit 2015 APIs and
the other relied on Revit 2017 APIs) as the traditional approach.
Then, the research team re-developed the same 3D visualization
function, based on Revit 2015 and 2017 APIs, under the En-
capsulatingBIM4FM architecture as the new approach. It should be
noted that the original FAB BIM model is stored in the Revit 2015
version, to be transformed into the 2017 version. Any further
C.-C. Hsieh, et al.
modifications should still be made to the 2015 version to maintain
model consistency.
Senior engineers who work in different departments of the FAB
were invited as the experts to attend a workshop for the second eva-
luation. As noted above, inside each usage context the research team
defined the tradition approach as application(s) previously utilized in
the FAB to realize given requirements, while the new approach implied
the use of EncapsulatingBIM4FM. A total of six FM stakeholders with an
average of 12.1 years of related work experience and six experts from
the IT department with an average of 7.3 years of BIM experience
joined the workshop. The FM experts were all familiar with the input,
output, and purposes of the traditional approach for each usage context.
The IT experts were all familiar with the traditional application de-
velopment of each usage context. During the workshop, the research
team introduced the research background and objectives to the experts.
Since the new applications, based on EncapsulatingBIM4FM and the
four usage contexts, were ready for demonstrations, the research team
showed the FM experts how to use them and let the experts assess the
degree of quality improvement for BIM models after they utilized both
the traditional and new applications under each usage context. As for
the IT experts, the research team further explained the proposed de-
velopment process of EncapsulatingBIM4FM (see Fig. 9) and the de-
tailed source codes of each new application. The IT experts were asked
to assess the degree of development and maintenance efforts after they
studied or recompiled both the traditional and new applications under
each usage context.
All the experts were encouraged to discuss with each other and to
make any open comments. Because the objective of the second eva-
luation was to assess the efficiency and effectiveness of
EncapsulatingBIM4FM, each subject question was measured relative to
the expert's experience with the traditional approach. To preserve
consistency throughout the assessment, each question was designed to
be case-specific, with questions that presented experts with the fol-
lowing evaluative options:
• EncapsulatingBIM4FM was much better than traditional;
• EncapsulatingBIM4FM was better than traditional;
• EncapsulatingBIM4FM and traditional were equal;
• EncapsulatingBIM4FM was worse than traditional; and.
• EncapsulatingBIM4FM was much worse than traditional.
For example, an expert could select any one of the five options to
answer a question such as, “With EncapsulatingBIM4FM, to what extent
was the quality of BIM models improved?” Once the assessment had
been conducted, the response values were recorded and calculated. The
qualitative measures were each assigned a numeric value from 1 to 5,
with 1 being the much worse option. The research team averaged the
assessment results, which are listed in Table 2.
Question A of Table 2 shows the assessment results of the FM ex-
perts. Three FM experts stated that because the traditional applications
of Usage Contexts 3 and 4 were not stable, they occasionally experi-
enced unexpected shutdowns of BIM tools that might harm the BIM
model quality. Such situations were resolved in the corresponding new
applications of Usage Contexts 3 and 4. This may be due to the fact that
most of the new source codes were generated by En-
capsulatingBIM4FM, to avoid wrong use of BIM APIs involving either
two different tools or versions. For Usage Contexts 1 and 2, the quality
of BIM models was almost unaltered among the applications.
Regarding Question B of Table 2 from the IT experts' perspective,
the use of EncapsulatingBIM4FM could reduce the development efforts
for all the usage contexts. Two IT experts expressed that in the new
approach they wrote fewer codes and dealt directly with the spatial
layout of a facility, which expedited the overall development process
for the new applications. As for the maintenance efforts (see Question C
of Table 2), the assessment results behave consistently from all IT
284
Automation in Construction 102 (2019) 270–287
Table 2
Assessment results of the efficiency and effectiveness of EncapsulatingBIM4FM.
Subject question Expert Usage Mean
group context
(A) With EncapsulatingBIM4FM, to what extent FM 1 3.3
was the quality of BIM models improved? 2 3.0
3 4.3
4 4.5
(B) With EncapsulatingBIM4FM, what was the IT 1 4.3
ease of development of FM application(s)? 2 3.8
3 3.7
4 4.5
(C) With EncapsulatingBIM4FM, what was the 1 4.2
ease of maintenance of FM application(s)? 2 4.2
3 4.7
4 4.8
Note: The four usage contexts are: (1) FM application helping the transforma-
tion of part of the BIM/CAD data for FAB operations; (2) FM application asking
the BIM tool to perform specific BIM services; (3) FM applications asking both
Revit and Tekla to perform specific BIM services; and (4) FM applications
asking two Revit versions to perform specific BIM services.
experts' perspective, that is, the experts might assign different pre-
ference levels to such a question but no expert thought that it is Anti-
EncapsulatingBIM4FM (i.e., the worse or much worse option). Four IT
experts explicitly stated that the new approach removed BIM tool-
specific programming techniques, which might allow programmers to
write more FM-oriented functionality in order to extend or expand such
FM applications, making the codes maintenance work easier.
In addition, several experts suggested that if a room/space is very
critical, accessing its BIM elements should be authorized and mon-
itored, which is difficult to be realized using the traditional approach.
The research team responded that such security mechanisms could be
easily implemented under EncapsulatingBIM4FM (e.g., in each BIM
object). The IT experts expressed that EncapsulatingBIM4FM serves as a
software application factory that can purposely build an application for
one specific facility. The programming interfaces generated and utilized
by FM systems are stable because the software interfaces correspond to
the facility's spatial layout.
5. Implications from EncapsulatingBIM4FM and future work
Implications from this research can be elaborated in accordance
with how people or organizations relate to the use of
EncapsulatingBIM4FM. FM stakeholders, by definition, are primary
users of FM systems and can be regarded as indirect users of
EncapsulatingBIM4FM. Because FM stakeholders are not supposed to
know the details regarding how to use BIM tools, and because BIM
models have long been regarded as a great asset to the FM domain, a
new FM system can be created using EncapsulatingBIM4FM to serve the
purpose of bridging BIM models and FM requirements. The quality of
BIM models will be improved due to the fact that FM stakeholders can
not only see the 3D scene of selected BIM elements but manipulate
specific BIM models in a disciplined way. This cannot be achieved by
using the traditional file-based transformation approach. Therefore,
more customized FM systems relying on EncapsulatingBIM4FM can be
expected to be able to supply FM stakeholders with abundant BIM-
based, AEC-related information.
FM system developers, by definition, are primary users of
EncapsulatingBIM4FM. Traditionally, they are often faced with the mix
of BIM-induced to FM-specific requirements. Using
EncapsulatingBIM4FM, they can now concentrate more on FM-related
development work and write source codes inside BIM tools only if
corresponding BIM services are not available. Further, if multiple BIM
tools or different BIM versions are involved in an FM system, since the
client and server programs are decoupled under EncapsulatingBIM4FM,
C.-C. Hsieh, et al.
FM developers can create or modify any one of the programs without
affecting the other. For instance, suppose that FM developers revise a
client program only, which may help the new FM system meet strict
production schedules because developers can reuse the old or original
BIM models and services through the stable software interfaces med-
iating both the client and service programs. When FM developers have
more time, they can revise the server program and utilize the actual
BIM tool or the correct version of the BIM tool, without modifying any
of the client programs. In the semiconductor industry this feature is
valuable because a running FM system cannot be stopped for days to
wait for such BIM tools changes or upgrades.
As for BIM service developers, whether at the AEC domain or FABs,
they are encouraged to design and/or develop BIM services in ac-
cordance with the spatial layout of a facility. In other words, if a BIM
service may be reused in the FM domain, it should be associated with
either a floor or a room/space, which may require few modifications of
the existing source codes. For instance, in the AEC domain an FAB
design team may have several BIM services designed for fire safety
analysis. Some of the BIM services need to be performed again in the
FM domain because of equipment move-in or move-out processes.
Hence, these BIM services should be modified to become room-specific,
which can be accomplished by the research team within an hour
usually.
For BIM tool providers, they may need to consider to incorporate
COBie into a standardized message format for their BIM tools to ex-
change information with external applications in the FM domain.
Usually the performance of the file-based transformation approach is
slow. Because of the widespread use of web service technology nowa-
days, BIM tools can act as the web service provider to respond to any
FM-oriented requests and to return a series of COBie-compatible mes-
sages in a more efficient way. For sharing business information among
computers, consumer electronics, electronic components, semi-
conductor manufacturing, telecommunications, and logistics compa-
nies, a non-profit consortium called RosettaNet has been established for
such purposes for years [59]. If AEC/FM information systems would
like to achieve lifecycle interoperability, further enhancements of
COBie and/or EncapsulatingBIM4FM may be needed toward the goal
similar to RosettaNet.
Currently, EncapsulatingBIM4FM relies on Revit and Tekla as the
underlying BIM platforms and Visual Studio as the development plat-
form. Future work includes addressing portability issues such as de-
veloping other 2UML tools as well as Project Builder–like tools. The full
development for OpenBIM/xBIM is a top priority because it is open-
source and supports IFC and COBie. Some common BIM attributes re-
trieval and GUIs may need to become templates to be reused in various
contexts. For instance, EncapsulatingBIM4FM should be able to gen-
erate codes for realizing advanced visualization services as well as for
managing security-related function calls. Finally, the validation con-
ducted thus far and documented in this paper represents an initial va-
lidation of real BIM data, with real domain experts. However, further
validations need to be conducted in order to ensure that
EncapsulatingBIM4FM is fully mature, including how much of the time
EncapsulatingBIM4FM can expedite the development of an FM system
reusing BIM services.
6. Conclusions
Building information modeling (BIM) technology has traditionally
been used more for the design and construction phases of a facility,
with limited applications to the operations and maintenance phase. BIM
technology has also been expected to play a central role in the man-
agement of various information used during the entire lifecycle of a
facility [4,60]. While different systems in the architecture, engineering
and construction (AEC) domain and BIM tools can exchange informa-
tion mostly without difficulty, true software interoperability between
BIM and facility management (FM) systems is still daunting. A plethora
285
Automation in Construction 102 (2019) 270–287
of the current approaches for integration between BIM and FM systems
tend to focus on exporting building model data to universally accep-
table formats. The ration behind this is to bypass the interoperability
barrier between BIM and FM systems. While this has been well re-
searched in current literature, a deficiency in such approaches is that
FM systems are not able to take advantage of other services or functions
supported by BIM tools.
This research proposed a methodology called
EncapsulatingBIM4FM, which utilizes model-driven architecture
(MDA) and web services mechanisms, to help FM systems reuse BIM
tools functionality. EncapsulatingBIM4FM aims at such an FM system
that is self-developed to accommodate specific requirements and that
involves extensive reuse of BIM models. Other types of FM systems that
need the geometry or designated attribute data of a facility only in the
initial phase for system configuration are not included in this research.
This is because existing approaches such as the use of industry foun-
dation classes (IFC) and construction operations building information
exchange (COBie) specifications have often been utilized for such one-
time data transformation work [61].
FM systems dealing with spatiotemporal data are characterized by
the fact that better data analytics results can be obtained if their tem-
poral data sets can be fused with the corresponding spatial attributes.
BIM tools have long been recognized as the best data source for FM
systems to acquire their facility-related geometry data. With the use of
EncapsulatingBIM4FM, FM system developers can reuse a BIM service
by invoking the corresponding version defined in the FM object. Since
the class diagram generated by EncapsulatingBIM4FM resembles the
spatial layout of a building, such BIM-oriented, tailored interfaces are
more stable and straightforward for FM system developers to finalize
the implementation work of their FM system.
The FAB staff were invited to review EncapsulatingBIM4FM and the
pilot system. From their perspective, using EncapsulatingBIM4FM can
lead to a more efficient way to develop a green-field FM system that
requires BIM. In addition, the pilot system demonstrated that better
software reusability can be achieved compared with their previous
experience of using the traditional approach. The average time added to
invoke a BIM service for an FM system was found to be less than 1 s.
In addition, the proposed EncapsulatingBIM4FM defines the archi-
tecture of an FM system reusing BIM services. Since most FM systems
concentrate on temporal data and associated transactions (e.g., a
maintenance record), with the use of EncapsulatingBIM4FM the spatial
data resulting from BIM models can be easily integrated into the time-
oriented FM data, so that a spatiotemporal and comprehensive data set
for FM can be prepared. Previous literature shows that BIM services can
be implemented in the FM domain using portal-related mechanisms
[62]. This research has furthered such mechanisms and suggested that
all request and response messages sent between BIM tools and FM
systems be monitored and inspected by EncapsulatingBIM4FM. This is
because in the FM domain BIM models may become too sensitive to be
retrieved by unauthorized persons. In the semiconductor industry FAB
design teams usually have to perform in-house design, i.e., all BIM tools
and models always at FAB owners' computers. Therefore, during the
operations and maintenance phase of FABs, accessing BIM models must
be audited, too.
The academic contributions of this research center on applying the
MDA and meta-object facility mechanism to the integration of BIM
services into an FM system, considering the differences in usage at the
levels of abstraction of the building elements between the AEC and FM
domains. The four tools of EncapsulatingBIM4FM, along with the pro-
posed usage steps, can help automate BIM integration work for an FM
system. Even if the underlying BIM platform is upgraded or changed, at
most two of the EncapsulatingBIM4FM tools need modifications. If,
during the operations and maintenance phase, any changes in BIM data
can be carried out by using the original BIM tool under
EncapsulatingBIM4FM, a living BIM data set can be maintained, which
facilitates the sharing of BIM data throughout the facility's lifecycle.
C.-C. Hsieh, et al. Automation in Construction 102 (2019) 270–287

Acknowledgements date: 1 November 2017.

[22] I. Sommerville, Software engineering, 10th edition, Pearson, London, UK, 978-
0133943030, 2015.
The research was supported in part by the Ministry of Science and [23] K. Yu, T. Froese, F. Grobler, A development framework for data models for com-
Technology of Taiwan under Grants NSC100-2119-M-008-007, puter-integrated facilities management, Autom. Constr. 9 (2000) 145–167, https://
MOST103-2221-E-008-054-MY3, and MOST105-3113-E-008-002. doi.org/10.1016/S0926-5805(99)00002-3.
[24] Y. Song, M.J. Clayton, R.E. Johnson, Anticipating reuse: documenting buildings for
Additionally, we would like to thank Pai-Yu Wu and An-Ping Jeng for operations using web technology, Autom. Constr. 11 (2002) 185–197, https://doi.
the assistance in preparing the manuscript and anonymous reviewers org/10.1016/S0926-5805(00)00097-2.
for providing helpful comments on the refinement of this paper. [25] D.S. Frankel, Model driven architecture: applying MDA to enterprise computing,
Wiley, Hoboken, New Jersey, USA, 978-0471319207, 2003.
[26] U. Iqbal, Review-Scrum (R-Scrum): Introduction of Model Driven Architecture
References (MDA), LAMBERT Academic Publishing, Saarbrücken, Germany, 978-3659707254,
2015.
[27] Cooperative Research Centre for Construction Innovation (CRC), Adopting BIM for
[1] C. Eastman, P. Teicholz, R. Sacks, K. Liston, BIM Handbook: A Guide to Building
facilities management: solutions for managing the Sydney Opera House, CRC,
Information Modeling for Owners, Managers, Designers, Engineers and Contractors,
Brisbane, Queensland, Australia, 978-0977528226, 2007.
Wiley, Hoboken, New Jersey, USA, 978-0470541371, 2008.
[28] M.P. Gallaher, A.C. O'Connor, J.L. Dettbarn Jr., L.T. Gilday, Cost analysis of in-
[2] R. Volk, J. Stengel, F. Schultmann, Building Information Modeling (BIM) for ex-
adequate interoperability in the U.S. capital facilities industry, NIST GCR 04-867,
isting buildings — literature review and future needs, Autom. Constr. 38 (2014)
National Institute of Standards and Technology, Gaithersburg, Maryland, USA,
109–127, https://doi.org/10.1016/j.autcon.2013.10.023.
2004Online https://nvlpubs.nist.gov/nistpubs/gcr/2004/NIST.GCR.04-867.pdf ,
[3] T. Beach, I. Petri, Y. Rezgui, O. Rana, Management of collaborative BIM data by
Accessed date: 1 November 2017.
federating distributed BIM models, J. Comput. Civ. Eng. 31 (4) (2017), https://doi.
[29] E.W. East, N. Nisbet, T. Liebich, Facility management handover model view, J.
org/10.1061/(ASCE)CP.1943-5487.0000657.
Comput. Civ. Eng. 27 (1) (2013) 61–67, https://doi.org/10.1061/(ASCE)CP.1943-
[4] B. Becerik-Gerber, F. Jazizadeh, N. Li, G. Calis, Application areas and data re-
5487.0000196.
quirements for BIM-enabled facilities management, J. Constr. Eng. Manag. 138 (3)
[30] G. Kelly, M. Serginson, S. Lockley, N. Dawood, M. Kassem, BIM for facility man-
(2012) 431–442, https://doi.org/10.1061/(ASCE)CO.1943-7862.0000433.
agement: A review and a case study investigating the value and challenges,
[5] P. Teicholz, BIM for Facility Managers, IFMA Foundation & Wiley, Hoboken, New
Proceedings of the 13th International Conference on Construction Applications of
Jersey, USA, 978-1118382813, 2013.
Virtual Reality, London, UK, October 30–31, 2013 Online http://itc.scix.net/data/
[6] Chuen-Chyi Hsieh, Critical Infrastructure Interdependency Analysis for
works/att/convr-2013-20.pdf , Accessed date: 1 November 2017.
Semiconductor Fabrication Plants, M.S. Thesis Department of Civil Engineering,
[31] buildingSMART, IFC Specifications (including ifcXML and OpenBIM), Online
National Central University, Taoyuan, Taiwan, 2011 Online https://etd.lib.nctu.
buildingSMART, http://www.buildingsmart-tech.org/specifications, (2015) ,
edu.tw/cgi-bin/gs32/ncugsweb.cgi/ccd=5erSWW/record?r1=1&h1=1 , Accessed
Accessed date: 1 November 2017.
date: 1 November 2017(in Chinese).
[32] M. Belsky, R. Sacks, I. Brilakis, Semantic enrichment for building information
[7] C.W. Chung, Y.H. Lin, Development roadmap of facility management integrated
modeling, Comput. Aided Civ. Inf. Eng. 31 (2016) 261–274, https://doi.org/10.
BIM technologies in Public Utilities Service Department of Taiwan Semiconductor
1111/mice.12128.
Manufacturing Company, J. Prop. Manag. 5 (1) (2014) 83–88 Online http://www.
[33] General Services Administration (GSA), GSA building information modeling guide
airitilibrary.com/Publication/alDetailedMesh?DocID=20765509-201404-
series: 08 – GSA BIM guide for facility management, GSA, Washington, D.C., USA,
201411270025-201411270025-83-88 , Accessed date: 1 November 2017(in
(2012) Online https://www.gsa.gov/cdnstatic/largedocs/BIM_Guide_Series_
Chinese).
Facility_Management.pdf , Accessed date: 1 November 2017.
[8] M.D. Platzer, J.F. Sargent Jr., U.S. semiconductor manufacturing: industry trends,
[34] R. Elmasri, S.B. Navathe, Fundamentals of Database Systems, 7th ed., Pearson,
global competition, federal policy, CRS Report 7-5700, Congressional Research
London, UK, 978-0133970777, 2015.
Service, Washington, D.C., USA, 2016Online https://fas.org/sgp/crs/misc/R44544.
[35] D. Gleason, “Getting to a facility management BIM.” Lake Constance 5D-conference,
pdf , Accessed date: 1 November 2017.
Konstanz, Germany, October 28–29, Online https://www.tekla.com/de/trimble-
[9] Maximo, Maximo release 7.6: User's guide, IBM, Armonk, New York, USA, (2014)
5d/facility-management-bim.pdf, (2013) , Accessed date: 1 November 2017.
Online https://www.ibm.com/support/knowledgecenter/en/SSLKT6_7.6.0 ,
[36] S. Lee, O. Akin, Shadowing tradespeople: inefficiency in maintenance fieldwork,
Accessed date: 1 November 2017.
Autom. Constr. 18 (5) (2009) 536–546, https://doi.org/10.1016/j.autcon.2008.11.
[10] D. Wood, BIM for operations, Online IBM, https://goo.gl/QeiejJ, (2014) , Accessed
002.
date: 1 November 2017.
[37] S. Lee, O. Akin, Augmented reality-based computational fieldwork support for
[11] P. Parsanezhad, J. Dimyadi, Effective facility management and operations via a
equipment operations and maintenance, Autom. Constr. 20 (4) (2010) 338–352,
BIM-based integrated information system, CIB Facilities Management (CFM) 2014
https://doi.org/10.1016/j.autcon.2010.11.004.
Conference, Copenhagen, Denmark, May 21–23, 2014 Online http://unitec.
[38] W. Thabet, J. Lucas, S. Johnston, A case study for improving BIM-FM handover for a
researchbank.ac.nz/handle/10652/3034 , Accessed date: 1 November 2017.
large educational institution, Construction Research Congress 2016, San Juan,
[12] E.M. Wetzel, W.Y. Thabet, The use of a BIM-based framework to support safe fa-
Puerto Rico, 2016, pp. 2177–2186, , https://doi.org/10.1061/9780784479827.
cility management processes, Autom. Constr. 60 (2015) 12–24, https://doi.org/10.
217.
1016/j.autcon.2015.09.004.
[39] J. Patacas, N. Dawood, V. Vukovic, M. Kassem, BIM for facilities management:
[13] O. Davtalab, Benefits of real-time data driven BIM for FM departments in operations
Evaluating BIM standards in asset register creation and service life planning, ITcon
control and maintenance, ASCE International Workshop on Computing in Civil
20 (2015) 313–331 Online https://www.itcon.org/papers/2015_20.content.00383.
Engineering, Seattle, Washington, USA, June 25–27, 2017, https://doi.org/10.
pdf , Accessed date: 1 November 2017.
1061/9780784480823.025.
[40] G. Lee, R. Sacks, C.M. Eastman, Specifying parametric building object behavior
[14] K. Kensek, BIM guidelines inform facilities management databases: a case study
(BOB) for a building information modeling system, Autom. Constr. 15 (6) (2006)
over time, Buildings 5 (2015) 899–916, https://doi.org/10.3390/
758–776, https://doi.org/10.1016/j.autcon.2005.09.009.
buildings5030899.
[41] W. Shen, Q. Hao, H. Mak, J. Neelamkavil, H. Xie, J. Dickinson, R. Thomas,
[15] R. Liu, R. Issa, Design for maintenance accessibility using BIM tools, Facilities 32
A. Pardasani, H. Xue, Systems integration and collaboration in architecture, en-
(3/4) (2014) 153–159, https://doi.org/10.1108/F-09-2011-0078.
gineering, construction, and facilities management: a review, Adv. Eng. Inform. 24
[16] F. Shalabi, Y. Turkan, IFC BIM-based facility management approach to optimize
(2) (2009) 196–207, https://doi.org/10.1016/j.aei.2009.09.001.
data collection for corrective maintenance, J. Perform. Constr. Facil. (2016),
[42] Y. Niu, W. Lu, K. Chen, G.G. Huang, C. Anumba, Smart construction objects, J.
https://doi.org/10.1061/(ASCE)CF.1943-5509.0000941.
Comput. Civ. Eng. 30 (4) (2015), https://doi.org/10.1061/(ASCE)CP.1943-5487.
[17] O. Davtalab, J.L. Delgado, Benefits of 6D BIM for facilities management depart-
0000550.
ments for construction projects – a case study approach, The International
[43] Y. Wang, X. Wang, J. Wang, P. Yung, G. Jun, Engagement of facilities management
Symposium on Automation and Robotics in Construction and Mining (ISARC 2014),
in design stage through BIM: framework and a case study, Adv. Civil Eng. 2013
Sydney, Australia, July 9–11, 2014 Online http://ecodomus.com/wp-content/
(2013) 1–8, https://doi.org/10.1155/2013/189105.
uploads/2015/05/isarc2014_submission_122_davtalab.pdf , Accessed date: 1
[44] Semiconductor Equipment and Materials International (SEMI), Guide for de-
November 2017.
termining and describing mass flow controller leak rates, SEMI E16-0517, SEMI,
[18] M. Kassem, G. Kelly, N. Dawood, M. Serginson, S. Lockley, BIM in facilities man-
Milpitas, California, USA, (2017) Online http://ams.semi.org/ebusiness/standards/
agement applications: a case study of a large university complex, Built Environ.
SEMIStandardDetail.aspx?ProductID=211&DownloadID=4013 , Accessed date: 1
Proj. Asset Manag. 5 (3) (2015) 261–277, https://doi.org/10.1108/BEPAM-02-
November 2017.
2014-0011.
[45] SEMI, Test Method for Pressure Transducers Used in Gas Delivery Systems, SEMI
[19] T.W. Kang, C.H. Hong, A study on software architecture for effective BIM/GIS-based
F113–1116, SEMI, Milpitas, California, USA, (2016) Online http://ams.semi.org/
facility management data integration, Autom. Constr. 54 (2015) 25–38, https://doi.
ebusiness/standards/SEMIStandardDetail.aspx?ProductID=211&DownloadID=
org/10.1016/j.autcon.2015.03.019.
3885 , Accessed date: 1 November 2017.
[20] Revit, Revit 2016 API Developers Guide, Autodesk, San Rafael, California, USA,
[46] B. Meyer, Object-Oriented Software Construction, 2nd edition, Prentice Hall, Upper
(2016) Online http://help.autodesk.com/view/RVT/2016/ENU/?guid=GUID-
Saddle River, New Jersey, USA, 978-0136291558, 1997.
F0A122E0-E556-4D0D-9D0F-7E72A9315A42 , Accessed date: 1 November 2017.
[47] B.T. Lewis, R.P. Payant, The Facility Manager's Emergency Preparedness Handbook,
[21] Tekla, Tekla open API user assistance, Trimble, Espoo, Finland, (2015) Online
American Management Association, Saranac Lake, New York, USA, 978-
https://teklastructures.support.tekla.com/191/en/sys_tekla_open_api , Accessed
0814473627, 2003.

286
C.-C. Hsieh, et al.
[48] G.A. Komatsoulis, D.B. Warzel, F.W. Hartel, K. Shanbhag, R. Chilukuri, G. Fragoso,
S. de Coronado, D.M. Reeves, J.B. Hadfield, C. Ludet, P.A. Covitz, caCORE version
3: implementation of a model driven, service-oriented architecture for semantic
interoperability, J. Biomed. Inform. 41 (2008) 106–123, https://doi.org/10.1016/j.
jbi.2007.03.009.
[49] J. Lucas, T. Bulbul, W. Thabet, An object-oriented model to support healthcare
facility information management, Autom. Constr. 31 (2013) 281–291, https://doi.
org/10.1016/j.autcon.2012.12.014.
[50] F.P. Brooks, The Mythical Man-Month: Essays on Software Engineering, 2nd edi-
tion, Addison-Wesley, Boston, Massachusetts, USA, 978-0201835953, 1995.
[51] E. Eykholt, Best of Booch: Designing Strategies for Object Technology, Cambridge
University Press, Cambridge, UK, 978-0137396160, 1998.
[52] W. Raghupathi, A. Umar, Exploring a model-driven architecture (MDA) approach to
health care information systems development, Int. J. Med. Inform. 77 (2008)
305–314, https://doi.org/10.1016/j.ijmedinf.2007.04.009.
[53] B. Blobel, P. Pharow, A model driven approach for the German health telematics
architectural framework and security infrastructure, Int. J. Med. Inform. 76 (2–3)
(2007) 169–175, https://doi.org/10.1016/j.ijmedinf.2006.05.044.
[54] R. Jardim-Goncalves, A. Grilo, A. Steiger-Garcao, Challenging the interoperability
between computers in industry with MDA and SOA, Comput. Ind. 57 (2006)
679–689, https://doi.org/10.1016/j.compind.2006.04.013.
[55] S. Kubicki, G. Halin, A. Guerriero, Multi-visualization of the cooperative context in
building construction activity: a model-based approach to design AEC-specific vi-
sualization interfaces, 11th International Conference on Information Visualization
(IV '07), July 4–6, 2007, pp. 590–595, , https://doi.org/10.1109/IV.2007.79.
[56] M.J. Clayton, R.E. Johnson, Y. Song, Operations documents: addressing the
287
Automation in Construction 102 (2019) 270–287
information needs of facility managers, in: M.A. Lacasse, D.J. Vanier (Eds.),
Durability of Building Materials and Components 8, Institute for Research in
Construction, Ottawa, Ontario, Canada, 1999, pp. 2441–2451 Online http://www.
irbnet.de/daten/iconda/CIB2205.pdf , Accessed date: 1 November 2017.
[57] J. Zhang, F. Yu, D. Li, Development and implementation of an industry foundation
classes-based graphic information model for virtual construction, Comput. Aided
Civ. Inf. Eng. 29 (2014) 60–74, https://doi.org/10.1111/j.1467-8667.2012.
00800.x.
[58] C.Y. Lin, C.C. Chou, Development of MDA-based framework for generating BIM
applications applied to the operations and maintenance phase of buildings,
Research Report No. 993402003, Department of Civil Engineering, National Central
University, Taoyuan, Taiwan, 2016Online https://goo.gl/8uQfbo , Accessed date: 1
November 2017(in Chinese).
[59] Wikipedia, RosettaNet, Wikipedia, Online https://en.wikipedia.org/wiki/
RosettaNet, (2017) , Accessed date: 1 November 2017.
[60] E. Alreshidi, M. Mourshed, Y. Rezgui, Cloud-based BIM governance platform re-
quirements and specifications: software engineering approach using BPMN and
UML, J. Comput. Civ. Eng. 30 (4) (2016), https://doi.org/10.1061/(ASCE)CP.1943-
5487.0000539.
[61] J. Patacas, N. Dawood, V. Vukovic, M. Kassem, BIM for facilities management:
evaluating BIM standards in asset register creation and service life, ITcon 20 (2015)
313–331 Online https://www.itcon.org/papers/2015_20.content.00383.pdf ,
Accessed date: 1 November 2017.
[62] A. Motamedi, A. Hammad, Y. Asen, Knowledge-assisted BIM-based visual analytics
for failure root cause detection in facilities management, Autom. Constr. 43 (2014)
73–83, https://doi.org/10.1016/j.autcon.2014.03.012.