Advanced Engineering Informatics 25 (2011) 224–244

Contents lists available at ScienceDirect

Advanced Engineering Informatics

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

A review and outlook for a ‘Building Information Model’ (BIM):

A multi-standpoint framework for technological development
Tomo Cerovsek *
University of Ljubljana, Faculty of Civil and Geodetic Engineering, Jamova 2, 1000 Ljubljana, Slovenia

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

Article history: This study provides a review of important issues for ‘Building Information Modelling’ (BIM) tools and
Received 19 November 2009 standards and comprehensive recommendations for their advancement and development that may
Received in revised form 11 June 2010 improve BIM technologies and provide a basis for inter-operability, integration, model-based communi-
Accepted 15 June 2010
cation, and collaboration in building projects.
Available online 13 July 2010
Based on a critical review of Building Product Modelling, including the development of standards for
exchange and the features of over 150 AEC/O (Architecture, Engineering, Construction, and Operation)
Keywords:
tools and digital models, a methodological framework is proposed for improvements to both BIM tools
Building Information Modelling
Standards
and schemata. The features relevant to the framework were studied using a conceptual process model
Standpoints and a ‘BIM System-of-Systems’ (BIM-SoS) model. The development, implementation, and use of the
Engineering communication BIM Schema are analysed from the standpoint of standardisation.
Project information management The results embrace the requirements for a BIM research methodology, with an example of methods
and procedures, an R&D review with critique, and a multi-standpoint framework for developments with
concrete recommendations, supported by BIM metrics, upon which the progress of tools, models, and
standards may be measured, evaluated, streamlined, and judged. It is also proposed that any BIM Schema
will never be ‘completed’ but should be developed as evolutionary ontology by ‘segmented standpoint
models’ to better account for evolving tools and AEC/O practices.
Ó 2010 Elsevier Ltd. All rights reserved.

1. Introduction 1.1. The role of standards for BIM

Product-model data exchange in project communication is of-
ten one of the most expensive and yet least adequately managed
processes [45] in the product lifecycle. Despite the fact that the
AEC/O (Architecture, Engineering, Construction, and Operations)
industry spends billions each year [41] on inter-operability issues,
little added value is obtained. Moreover, the exchange of building
product-model data is increasingly demanding as tools for model-
ling, analysis, visualisation, and simulation evolve.
The key issue in this area has historically been, and remains,
how to achieve inter-operability between multiple models and multi-
ple tools that are used in the whole product lifecycle. This has led to
over 30 years of standardisation efforts towards a standard common
product model. Three important inter-operability standards that ex-
ist today, ISO 10303, ISO 15531, and ISO 13584, enable engineering
enterprises to technologically integrate product-development pro-
cesses; these are known as STEP, MANDATE, and PLIB, respectively
[77].
* Tel.: +386 1 4768 521; fax: +386 1 4250 681.
E-mail address: tomo.cerovsek@fgg.uni-lj.si
The role of standards can be labelled by the ‘3C’ (competitive-
ness, conformity, and connectivity) [116]. Furthermore, standardi-
sation is considered a key instrument towards innovation [37].
Unfortunately, applications of the STEP standard for ‘Building
Information Modelling’ (BIM) that enable product-model data ex-
change, for example, ‘Industry Foundation Classes’ (IFC), ISO/PAS
16739, do not yet exhibit the three roles of any standard enabling
innovation: (1) inter-operability, (2) trust, and (3) comparability.
Two essential questions for the future of project communica-
tion are, ‘‘Will another 30 years of standardisation be sufficient?”
and ‘‘What is the way forward for BIM technologies?” The necessarily
broader context for the AEC/O industry may be adopted from the
‘European Inter-operability Framework’ (EIF) [38], which provides
policies and guidelines for the standardisation of interactions
between organisations beyond technological standpoints.
Several studies [4,57,124] have indicated that, until recently,
project communication has been little studied from more than a
technological standpoint. Some recent research has addressed
non-technological issues, e.g., adoption frameworks [88,108], BIM
business process re-engineering [8,83], experience with practical
use of BIM [53,109], impact of ICT [65] and BIM [109], and the role

1474-0346/$ - see front matter Ó 2010 Elsevier Ltd. All rights reserved.
doi:10.1016/j.aei.2010.06.003
 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
of visual communication in BIM [27]; this research has not, how-
ever, addressed the two essential questions stated above.
1.2. Study scope and goals
The goal of this study was to introduce a framework for the vali-
dation and verification of the technological development of BIM tools
and standards that would be relevant for standardisation organisa-
tions, researchers, software vendors, and AEC/O software end-users.
The essential proposition of this study is that it may be possible to
advance and develop BIM tools and standards towards new, harmo-
nised, innovative solutions if a multi-standpoint framework was
developed that took into account:
 Complementary research methodologies: The research must con-
sider affected groups, primarily building-project stakeholders,
AEC/O software developers, and developers of standards for
exchange, who all directly or indirectly affect project communi-
cation. It is important to be aware that the technologies can be
improved through the study of non-technological issues.
 Evolving practices and models: AEC/O practitioners continually
attempt to improve the way they analyse, document, and com-
municate information about the form, function, and technical
parameters of buildings. This leads to continual development
of AEC/O software, the development of which follows a pattern
common to any engineering domain: to describe and solve prob-
lems with an ever-increasing level of detail, accuracy, and effi-
ciency. Accordingly, the complexity of models and tools is
increasing.
 Engineering communication channels: Too much effort is cur-
rently expended on the subject of communication rather than
on the semiotics of communication (verbal and non-verbal
between humans via computer): ‘‘it is a virtue of any system, if
the system is aware of other systems” [122].
2. Methodology
The requirements for the research methodology were estab-
lished in three steps. First, based on the initial literature and soft-
ware review, a list of problem-methodology pairs was created.
Second, problems were separated from methodologies and
grouped into clusters by related research results. Third, conflicts
and synergies between methodologies were analysed against
‘problem-methodology’ pairs and clusters and finally synthesised
into ‘seven requirements for the methodology of BIM research’.
Based on these requirements, the methodology should do the
following:
1. Discover groups of related problems, rather than tackle very
specific and isolated technical problems
2. Assess and evaluate BIM practices in building projects and the
development of BIM tools/schema
3. Capture and correlate irreversible and limiting processes to
growth and innovation in BIM solutions
4. Streamline R&D toward new innovative solutions to support
BIM-based collaboration and services
5. Assess BIM solutions in the project life cycle (pre-construction,
construction, and post-construction)
6. Analyse BIM communication channels between machines, soft-
ware, and humans that are using ICT
7. Streamline those processes that foster advancement in existing
use and new adoption of BIM solutions
These seven requirements translate into a need to analyse BIM
from a broader, more holistic perspective, within which a clear dis-
tinction between observational and experimental research activi-
225
ties must be made. The traditional literature review was
extended using two complementary research methods, a process
method and a systems method.
2.1. Literature and software review
A detailed literature and software review is given in the individ-
ual sub-sections, along with the introduced concepts. Briefly out-
lined, the initial literature survey covered the following:
 Theoretical foundations – theories: Systems theory [122], infor-
mation theory [103], observational theory [18]
 Studies on the use of ICT in construction: ICT use within the con-
struction organisation [102] and between organisations [1],
industry preparedness [4] and project communication [124]
 BIM reviews and case studies: Reviews of BIM developments [57],
and capabilities [70], case studies [35,90], BIM implementation
frameworks [83,88,108] and industry perception [53,109]
The software review covered AEC/O software as follows:
 Lessons learned from early prototypes: The focus was on inter-
faces, automation of modelling, capturing of intent, and docu-
mentation, e.g., SketchPad [110], a consistent database for
integrated design by Yaski [14], integrated design models
[5,34,65], and early CAD/BIM software
 Development of the AEC software library: The library was started
10 years ago [115] and later contained 4000 tools [6], from
which 150 tools with BIM exchange features were selected
 Personal participation in BIM practices on large-scale pro-
jects, including a representative case study of a hospital
building of over 28,000 sq meters with several digital domain
models
2.2. The process centred and systems-thinking approach
In this approach, knowledge is used to refer to knowledge about
processes and its results [23]. The knowledge of relevant processes
was documented and studied through a series of IDEFØ diagrams,
which were used as meta-descriptions of modelling workflows for
the development of integrated models (see Fig. 1) and of workflows
for the standardisation of model-data exchange (see Section 4). Fig. 1
shows the development of a 5D model (3D – geometry, 4D – costs,
and 5D – time) in an integrated environment.
Based on an awareness of the limitations of conceptual process
modelling, an additional approach was introduced. The inability of
IDEFØ to model cycles and causal dependencies was compensated
for by systems-thinking, where systems represents a view of prob-
lems [55,122]. The systems-thinking approach has also been
adopted in the ‘General AEC reference model’ (GARM) [44] and ap-
plied in frameworks such as knowledge management [101].
Several systems-thinking methods including causal modelling,
system-archetypes, structural dynamics, and ‘System-of-Systems’
(SoS) [105] were used in this work to identify synergies of related
systems. A detailed discussion of the development and use of
BIM-SoS is beyond the scope of this paper, and only the outcome
is presented. The systems were divided into three categories:
directed, collaborative and virtual [80] and were studied from
multiple standpoints (i.e., organisational, technological and per-
sonal [63]).
2.3. Structure of the paper
In Section 3, a set of relevant basic definitions for standpoints
are provided to assure common understanding of the terminology.
In Section 4, a conceptual IDEFØ model is used to identify relevant
226 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
Drawings / Models
Standard DB Make Building Model
Project DB (3D Model) Assigned
Recipes &
A1 Quantities
Estimate Project
(4D Model)
A2
New Recipes
Vico Vico
Constructor Estimator
Fig. 1. The IDEFØ diagram representing complex BIM integration in a 5D modelling environment, where building geometry (3D) is linked with costs (4D) and schedule (5D) of
construction. Model from several tools are integrated into the integrated (5D) model.
standpoints for the development of a standard schema enabling
exchange. In Section 5, the framework, comprehensive recommen-
dations, and metrics are presented. In Section 6, a discussion and
validation are given. Section 7 concludes the paper with final re-
marks and answers to the two introductory questions.
3. Definitions of standpoints
A standpoint is ‘‘a position from which objects or principles are
viewed and according to which they are compared and judged”
[82]. Standpoints may be inter-subjective, i.e., shared by at least
two subjects [118], and are used for descriptological foundations
[96], both of which are highly relevant for BIM.
Thus, standpoints allow for judgments that are beyond the no-
tions of viewpoint, perspective, aspect, or domain. A standpoint is
not necessarily linked to a professional domain or to notions con-
nected with a particular view (e.g., professional or process-view). A
standpoint can be any concept that can provide a position for fur-
ther analysis. Although standpoints may be subjective, they are
very valuable because they can provide a reasonably objective ac-
count of also marginal but important issues.
Standpoint analysis depends on the selection of concepts that
are essential for the studied context. The context of BIM covers
‘‘a set of interacting policies, processes, and technologies” [108] used
for ‘‘modelling, visualisation, analyses, simulation, and documenta-
tion” [35]. In this study, the essential concepts for BIM were identi-
fied in the context of project communication with BIM, the
research proposition, and the ‘seven requirements for the methodol-
ogy for BIM research’. The initial literature review, as well as the
developed models (e.g., Fig. 1), supported the epistemological anal-
ysis and a filtering of essential concepts for BIM, described here as
the ‘five initial standpoints for BIM analysis’:
 model
 modelling tool
 communicative intent
 individual project work
 collaborative project work
Constructor Model (.pln)
Recipes / Methods / Resources (.db)
Scheduling
data
Schedule Project
Schedule Model (.dpp)
(5D Model)
A3
Publish 5D model 5D model (.5dm)
A4
Vico Vico
Control 5D_presenter
3.1. ‘BIM Model’ and ‘BIM Schema’ from the standpoint of a ‘model’
A model is a simplified representation used to describe or inter-
pret problems and solutions. A model that describes other models
is a meta-model. A schema is a formal meta-model representation
used to prescribe instance models. A schema can be viewed as an
agreement on a common vocabulary of modelling constructs, i.e.,
concepts that are allowed to constitute instance models.
AEC/O models from diverse professional domains may possess
some identical or related parts, or, in some cases, use the results
of each others’ analyses. The multiplicity of models with common-
alities led to the idea of creating a common model to be used by
several tools in project communication. The solution was termed
‘Building Product Modelling’ (BPM) [32], now labelled as ‘Building
Information Modelling’ (BIM). A ‘Building Product Model’ was de-
fined as the total sum of information about a building [15]. In this
paper, the terms ‘BIM Model’ and ‘BIM Schema’ are used; these
terms have the following meanings:
 A ‘BIM Model’ is a digital representation of an actual building
for project communication over the whole building-project life-
cycle. A physical, tangible appearance of a building from a time
standpoint can be represented by three model categories: ‘as-it-
was’, ‘as-it-is’, or ‘as-to-be’.
 A ‘BIM Schema’ is a non-linguistic data structure that describes
abstractions of generalised properties of a collection of states of
information about buildings to be used in project communica-
tion. The term ‘conceptual modelling’ is used to denote the
modelling of schemata.
A standpoint determines model categories; Gielingh’s lifecycle
standpoint gives seven categories [44]: as-required, as-designed,
as-planned, as-built, as-used, as-altered and as-demolished; a
business process standpoint gives five [49]: requirement, design,
production, commissioning, and operation model; and a product-
procurement standpoint gives four [66]: as-designed, as-ordered,
as-delivered, and as-owned. Models from standpoint categories
differ in their levels of detail and complexity, and may be
inconsistent.
 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244 227

Therefore, there is a need to determine relationships and dis-
tances (i.e., similarities) between models because even the same
model representation may have different forms (e.g., order or nota-
tion), which must be unified before any comparison is made. ‘BIM
canonicalisation’ is a process in which an arbitrary BIM Model or
Schema is transformed into a special type of form, i.e., a BIM canon-
ical form, that shares the same representational power with the
underlying form but adheres to a predefined set of principles.
3.2. ‘BIM Model’ and ‘BIM Schema’ from the standpoint of ‘modelling
tool’
A ‘BIM tool’ is an AEC/O modelling tool that allows for manipu-
lation of BIM models. A typical commercial BIM tool has two impor-
tant features: (1) the modelling constructs are parametric 3D digital
objects (called elements or parts) that represent real-world (physi-
cal) components with relationships and non-geometric metadata;
and (2) different model views are integrated through a single data
source that enables constant synchronisation of model views, so
that a change in one model view is instantly reflected in others
(i.e., floor plans, sections, 3D views, schedules, bills of quantities).
Each BIM tool describes a building model in its own language,
which is not necessarily understood by other BIM tools because
tools use different modelling constructs and features to create,
manipulate, and physically store digital models in native file for-
mats. As noted in previous Section 3.1 the same building may be
represented by seven categories of BIM Models, which may be con-
structed by the same tool or by different tools and, therefore, made
of different modelling constructs.
A BIM Model is shared from a standpoint of an end-user as soon
as it is used by more than one AEC/O (BIM) tool and/or person. The
goal of model sharing is to allow the exchange and use of model data
outside the native modelling environment (this is software where
the model was originally created and format in which it was stored
for later use). Only agreed formats, schemata, or APIs [24] can sup-
port the exchange of model data. Model may be exchanged at differ-
ent granularities, ranging from the entire model, model view, its
parts, individual components to a single name-value pair.
An ‘internal BIM Schema’ is used to denote a schema that is
used inside the modelling environment of a BIM tool. An ‘internal
BIM Schema’ represents features and models of a ‘BIM tool’. As
such, an ‘internal BIM Schema’ documents the modelling con-
structs, and knowledge embedded in the BIM tool.
In addition to a BIM tool, an ‘external BIM Schema’ is usually
used in order to harmonise information exchange (inter-operabil-
ity). The ‘external BIM Schema’ has the role of ‘BIM Esperanto’ for
the BIM tools that otherwise do not understand each others’ geo-
metrical model data with metadata.
While ‘internal BIM Schema’ describes concepts that depend on
the BIM tool and specific domain and specific project phase, the
aim of an ‘external BIM Schema’ is to prescribe the exchange of
building information across professional domains and project
phases. The focus of this paper is an ‘external BIM Schema’ that
is developed as a standard for building-model data exchange. This
standard is developed with standardised modelling methods, lan-
guages, and physical representations of the model-data.
3.3. ‘BIM Model’ and ‘BIM Schema’ from the standpoint of
‘communicative intent’
Communicative intent depends on the context of communica-
tion. A ‘BIM communication model’ (BCM) consists of sender-encoder
and decoder-receiver, which are project stakeholders and/or BIM
tools, the message, which is BIM Model data that varies in level of
detail, modelling constructs, and granularity, and communication
channels, which may be analogue or digital. Table 1 identifies
important standpoints for the use of BIM Model and BIM Schema
in project communication. Note, see Table 1, that modelling con-
structs (code) for a BIM Model are conceptually the same as in-
stances of modelling result (message) for a BIM Schema. In
theory, a CASE tool could connect the two automatically.
3.4. BIM from the standpoint of ‘individual project work’
The contribution of an individual to a given project can only be
evaluated on the basis of the available input (design problem),
process (design), and output (design solution) [26]. For a model-
ler, the modelling in a design can be either internal or external
[64]. The modelling is internal if designers seek individual reflec-
tion. The modelling is external when models (representations)
must be communicated between project stakeholders. Similarly,
the re-use of design knowledge can be internal (readily available

Table 1
Standpoints for the comparison of the roles of the BIM Model and BIM Schema in project communication.

Standpoint BIM Model BIM Schema (enabling exchange)

Communicative intent To document information about a specific building in project
phases (pre-, construction, post-).
(semiotics) (to externalise project ideas for project realisation)
Authors Design offices, AEC/O project teams, individual AEC/O practitioners
that collaborate on the projects.
(sender) (Architects, Structural, Mechanical Engineers)
Audience Actual building-project stakeholders having different project roles
and professional backgrounds.
(receiver) (Architects, Engineers, Contractors, Public Bodies)
Authoring environment BIM tools are software packages that are used for modelling and/or
are integrated design environments.
(encoder) (Archicad™, Revit™, AllPlan™, Tekla™, SAP2000™)
Modelling constructs Parametric 3D elements and components that are digital
equivalents of their real-world (physical) counterparts.
(code) (types of building elements and components)
Modelling result 3D digital representation of actual building that represents
simplified physical properties of building.
(message) (model views, elements with a cross-section, material)
Message formatting Each BIM modelling tool has its native format, but for the external
exchange depends on the tool.
(encoding) (native/open model formats: rvt, pln, ifc, cis, xml, pdf)
To standardise data structures used for the exchange of building
information
(to specify data structures for the exchange)
Standardisation organisations for international or industry
standards, i.e., ISO, IAI, CSI.
(AEC/O and computer science experts)
Vendors of AEC/O software used to represent form, function, or
behaviour of buildings.
(AEC/O software vendors)
Information modelling software that enables specification of data
structures with relationships.
(EDM modeller™, STEP tools™)
High-level ontological constructs such as abstract entities, types,
properties, parity relations, etc.
(entities, data types, relationships)
Non-linguistic data structures describing abstractions/
generalisations of information states.
(types of building elements and components)
The most common format is ISO STEP EXPRESS; other encodings are
possible: XML, OWL, OCL...
(open schema formats: exp, owl, xsd)
228 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
Table 2
Standpoints for the evaluation of BIM support for individual work (examples are described in brackets).
Standpoint Internal (controlled by BIM modeller)
Resources Information, material and time resources
(input) (interpreted design problem, priorities, used time)
Process Internal workflow selected by the modeller
(process) (modelling workflow: 2D, 3D, combined)
Process result Internal project communication needs
(output) (requirement, design, production, operation model)
BIM literacy Personal skills, knowledge, and competences
(competencies) (precision, productivity, profession, BIM literacy)
BIM tool Modelling constructs, features, and interfaces
(tool features) (components, libraries, documentation)
Table 3
Standpoints for the evaluation of BIM-enabled collaboration (examples are described in brackets).
Standpoint Character (characteristic types)
Reference location Same or different physical/digital locations.
(virtual, real-world; augmented, immersive BIM)
Time Synchronous or asynchronous.
(BIM access: concurrent, parallel or sequential)
Group Goals, identity, and relationships in BIM practises.
(project, organisation, and community level)
Teamwork Forming, Storming, Norming, Performing.
(presence indicators, teamwork stages via BIM tools)
Business process Project phase and types of activities in contexts.
(pre-construction, construction, post-construction)
Information sharing Internal and external BIM Model content.
(content types, format, metadata, structure, IPR)
Application sharing Type of BIM collaboration and access control
(workspace, app., code, services per session object)
Communication channel Type of communication architecture and channel
(client–server, p2p, hybrid; protocols)
in the ‘internal memory’ of a designer) or external (documented
in ‘external memory’ by others, e.g., in corporate memories/repos-
itories) [30]. For related overview of knowledge sharing consult
[98].
Table 2 lists standpoints relevant to the externalisation of pro-
ject communication in BIM from the standpoint of the individual
project work of a practitioner. Note that a BIM Schema has no expli-
cit value for a BIM modeller, who is only using the implementation in
the tools that are involved in the exchange of model data. The stand-
points relate only to the modelling input, process and output, along
with critical competencies and tools that affect the work of an indi-
vidual. The lifecycle of a BIM Model is affected by project context,
project stakeholders and, the tools they use, all of which require
standards. Only readily available BIM content can have immediate
impact on AEC/O information policies.
3.5. BIM from the standpoint of ‘collaborative project work’
Collaboration between people who frequently work together
and who potentially have common context is often facilitated. A
successful collaboration on projects strongly depends on information
that does not need to be communicated at all. However, the location,
time, personnel, processes, and means of communication involved
in the work have different characters and the capacities for collab-
oration. Table 3 reviews some relevant standpoints for the evalua-
tion of BIM-enabled support for collaborative project work through
communication channels that make use of BIM tools, models, sche-
mata, model servers, and networking on top of the general ICT
infrastructure, tools, services, and protocols. Two arbitrary stand-
points from Table 3 can be used to create a two-dimensional ma-
External (not controlled by BIM modeller)
Knowledge externalised by others
(external input sources, available time/money)
External workflows affecting an individual
(project phase, construction technology)
External results in the project context
(produced via stakeholders’ communication)
Literacy of the project stakeholders
(the ability to supply/consume BIM Models)
Operating system and hardware limitations
(operating system capacity, hardware capacity)
Capacity (measures for metrics)
Number of ‘physical/virtual locations’ or models.
(GPS or URLs of people, sites, models)
Duration, time-frame, and frequency of BIM use.
(frequencies: model versioning, audit trail, CRUD)
Size of group, number of goals and relationships.
(intensity of collaboration, collaborators per task)
Number of actors, professional roles, and teams.
(number of companies and groups involved)
Number of activities, resources used for results.
(workflow capacity, productivity capacity)
Granularity and volume of exchange.
(granularity, number of units, and size of exchange)
Application capacity to share BIM Models
(synchronous users limits, transmission modes)
Number of communication channels and capacity
(communication modality; bandwidth limitation)
trix for the evaluation of BIM. Similarly, one can build
taxonomies (principles of classification) if the standpoints are used
for levels in the hierarchy.
4. BIM from the standpoint of ‘standardisation with ISO STEP’
In this Section, BIM is studied from the standpoint of standardi-
sation with ISO STEP; this was studied using a ‘conceptual process
model’ [25] and a ‘BIM System-of-Systems’ (BIM-SoS) model. The
ISO STEP is relevant because it is used for all the major schemata
(IFC [85], ISO/PAS 16739, CIS/2 [36]).
The IDEFØ context diagram in Fig. 2, Use standard ISO STEP for
the exchange of BIM Models, depicts all ‘inputs, controls, outputs,
and mechanisms’ (ICOMs) that are external to the observed con-
text. The diagram does not show sub-activities inside the process
context or ICOMs between sub-activities.
The inputs (arrows to the left of the rectangle) include the gen-
eric inputs Exchange scenario and Information about buildings and
two inputs related to an actual building: Project communication
and AEC/O models. The controls (arrows from the top) are the ISO
STEP standards, the Software controls of the AEC/O tools and Other
controls, i.e., theories, provisions from building codes and stan-
dards. The arrows with square brackets indicate controls that are
not presented in detailed diagrams.
The outputs (arrows to the right of the rectangle) of the process
context are ‘External BIM Schema’ (IFC in exp), ‘BIM Model’ in open-
file format according to ISO STEP, and a Shared BIM Model (.ifc file
as a STEP physical file). The mechanisms are Information modelling
software, used by ‘Construction Informatics’ – CI experts, and AEC/
O software, used by AEC/O practitioners.
 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244 229

ISO - STEP ISO - STEP Software Other

Part 11 Part 21 controls controls
(EXPRESS (STEP (embedded (codes,etc)
schema) physical file) features)

Exchange scenario 'External BIM Schema'

(BPML, IFC IDM) (IFC in exp, xsd, owl)
Information about buildings 'BIM Schema' certification
(real-world, documented, undocumented) Use standard ISO STEP (including deployment)
for the exchange of BIM Models
Project communication 'BIM Schema' translator
(actual building project) (IFC import/export utility)
AEC/O models Shared 'BIM Model'
(actual building model) (.ifc file)
A0

CI experts AEC/O
(AEC/O & practitioners
Information modelling software CS (architects, AEC/O Software
(EDM modeller, STEP Tools) experts) engineers) (architectural, engineering)

Fig. 2. The IDEFØ context diagram illustrates the use of ISO STEP for the exchange of BIM Models with inputs, controls, outputs, and mechanisms (ICOMs). The use of ISO STEP
is limited to the sequential exchange of BIM Models with STEP physical files.

According to the IDEFØ principles, each activity can be hierar-
chically broken down into sub-activities until the desired level of
detail is reached. The code at the bottom right corner of the activity
rectangle indicates the position in the hierarchy. The breakdown
depends on the model’s purpose and scope.
The purpose of the presented conceptual process model is to
formally document the use of the ISO STEP standard for the ex-
change of BIM Models. The scope of the process model is limited
to the levels required to illustrate the application of ISO STEP over
the lifecycle of the BIM Model and BIM Schema. Fig. 3 illustrates
the breakdown of the process context (coded as A0 in Fig. 2) into
the following three sub-activities: (A1) ‘BIM Schema’ development,
(A2) ‘BIM Schema’ implementation, and (A3) ‘BIM Model’ sharing.
The activity names in parentheses are generic (e.g., ‘BIM Schema’
development), while the activity names above them (e.g., Develop
EXPRESS Schema) refer to the ISO STEP-specific approach. The dia-
gram in Fig. 3 illustrates the use of two essential parts of the ISO
STEP standard: Part 11, used for the BIM Schema, and Part 21, used
for the physical file of a ‘shared BIM Model’.
For each activity in Fig. 3, the goals (what), objectives (how),
and ICOM components are described. Additionally, historical
background and recent developments are also discussed in the

C1 C2 C3
ISO - STEP Part 11 ISO - STEP Part 21 Software controls
(EXPRESS schema) (STEP physical file) (embedded features)

Exchange scenario
(BPML, IFC IDM)
I1 EXPRESS schema
Develop
EXPRESS Schema (IFC,CIS 'BIM Schema') 'External BIM Schema'
I2 O1
Information ('BIM Schema' development) (IFC in exp, xsd, owl)
about buildings
(real-world, A1 Implemented schemata
documented, (internal and external)
undocumented) 'BIM Schema' Implemented workflows
Implement implementation (applications' exchange)
'External BIM Schema'
Standard EXPRESS Schema (translator: IFC, CIS) 'BIM Schema' certification
O2
exchanges Model View Definitions ('BIM Schema' implementation) (including deployment)
'BIM Schema' translator
O3
Internal BIM schemata 'Internal BIM Schema' A2 (IFC import/export utility)
(tools used in exchange)
Project communication Translator
settings Import/export
(actual building project)
I3 STEP physical file O4
('BIM Model' sharing) Shared
I4 'BIM
AEC/O models A3 Model'
(actual building model) (.ifc file)
Translator code
Information modelling software CI experts AEC/O Software AEC/O Software AEC/O practitioners
(EDM modeller, STEP Tools) M1 M2 (AEC/O & CS experts) vendors (architectural, engineering) M4 M3 (architects,
engineers)

Fig. 3. Main sub-activities and relationships in the use of ISO STEP ‘BIM Schema’ enabling the exchange of BIM Models (legend: green lines: process knowledge; blue lines:
process-result knowledge; red dashed lines: desired inputs and outputs).
230 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
sub-sections. The numbers of the headings of the sub-sections cor-
respond to the activity-code labels at the bottom of the activity
rectangles in Fig. 3. For example, Section 4.1 covers activity A1
(BIM Schema development).
4.1. ‘BIM Schema’ development (conceptual modelling)
Here, the goal of conceptual modelling is to standardise the ex-
change of BIM Model data. The core of the BIM Schema is usually
not altered; the modellers are mostly only extending/improving
the schema.
The objective of the conceptual modelling is to generalise prop-
erties of instances of information about building models (parts/
views) that appear in exchange scenarios that are required for suc-
cessful project communication. These data-exchange structures
may be divided into explicit and implicit classes:
 ‘Explicit data’ are modelled and stored explicitly in the
exchanged digital file. Explicit data are available after the
exchanged file is parsed – without transformations (e.g., column
radius: r). Explicit data also include explicitly defined ‘deriva-
tion rules’ (e.g., area: A = pr2).
 ‘Implicit data’ are not modelled and stored but determined from
explicit data. After parsing is done, explicit data are used to obtain
implicit data. Implicit data are – but is not exclusively – ‘derived
data’, which uses explicit data (e.g., radii, heights and materials
for all columns in a floor may be used to derive a total weight of
columns per floor). Note: implicit data are not limited to a single
physical file, and it is not even necessary that ‘derivation rules’
exist for ‘implicit data’.
The following main ICOM components determine the concep-
tual modelling of the BIM Schema:
 Inputs: The inputs are models of processes (I1) and process
results (I2):
 (I1) Exchange scenario: This is described with a process
model (e.g., IDEF, BPML), which is external to the AEC/O soft-
ware that is used in the exchange scenario. According to the
ISO STEP terminology, this model is called the ‘Application
Activity Model’ (AAM) [59]. Examples of such process
models are the ‘Design Exchange Protocol’ (DEP) for CIS/2
BIM Schema [36] and the ‘Information Delivery Manual’
(IDM) for the IFC Schema [85].
 (I2) Information about buildings: This is the result of pro-
cesses (see Table 5) that represent input sources for the
BIM Schema. This input also includes existing schemata,
‘integrated resources’ (IR) and ‘application protocols’ (AP).
These are documented in ISO STEP Part 41 to Part 49 and
in the applicable application-interpreted models.
 Controls: Prescribe the way the modelling language is used
(Figs. 2 and 3):
 (C1) ISO STEP Part 11. It defines language EXPRESS [59].
 Outputs: The main result is presented here:
 (O1) EXPRESS schema: A schema is a collection of entities (or
classes), attributes, and relationships between entities that
define patterns for instances [74]. ISO STEP uses graphical
and textual representations. The ‘Application Reference
Table 4
The analogy between MDA models, ISO STEP layers, and ANSI/SPARC schemata.
MDA model ISO STEP Layer ANSI/SPARC Schema
Computational independent model Application layer External schema
Platform independent model Logical layer Conceptual schema
Platform specific model Physical layer Internal schema
Model’ (ARM) is an information model that describes infor-
mation requirements within constraints found in the appli-
cation context that are satisfied in the ‘Application
Interpreted Model’ (AIM) and IR.
 Mechanisms: The schema is authored by the following:
 (M1) Construction Informatics (CI) Experts: The work of CI
experts is coordinated by three organisations, the Interna-
tional Alliance for Inter-operability (IAI), the International
Organisation for Standardisation (ISO), and the Steel Con-
struction Institute (SCI).
 (M2) Information modelling tools: The CI experts use EXPRESS
modelling tools (e.g., EDM Modeller and STEP ST) which
automatically synchronise or validate ARM and AIM.
The evolution of product-model data-specification languages
began in the 1980s with PDES-STEP [32] and continued evolving
with the ISO STEP EXPRESS data-specification language for standard
schemata. For details on development history, consult [32,57]. Over
thirty years of standardisation efforts have been justified by the fol-
lowing: more products being developed for the global market, the
increasing complexity of the products, different hardware and soft-
ware tools that use the same information and the need to automate
processes. The development of information-modelling methodolo-
gies played a decisive role in achieving these goals through stan-
dardisation. Several modelling paradigms have been used for BIM
Schemata: relational, ‘object oriented’ (OO), and process centred
[14,32]. Practically all BIM Schema standardisation efforts have
been strongly influenced by the following two paradigms:
 A 40-year old ANSI/SPARC layered approach for databases used
in ISO STEP [59]; its legacy can be traced to this decade, as
evident in the ‘model-driven architecture’ (MDA) [91] (see
Table 4)
 A 30-year old distinction between a building kernel and domain
models, which was adopted for early models like RATAS and
BCC [32]
In the 1980s, five requirements for a BIM Schema were set by
Bjork [15]. According to this view, a BIM Schema should (1) include
all information about buildings; (2) cover all information needs by
all stakeholders in all phases; (3) be non-redundant; (4) be soft-
ware-independent; (5) be format-independent. Eastman [34]
added a requirement to represent function, abstraction, and repre-
sentation with extensible semantics. Relevant requirements for the
modelling language were set [14] including usability, comprehen-
sibility, intentionality, extensibility, implementation-ability, and
standardisation-ability. A detailed process overview of the stan-
dardisation process, as relevant for BIM, is discussed in [16].
The work on BIM Schemata has been coordinated in different
standardisation and research organisations. BIM Schema develop-
ment has usually not arisen from nothing; rather, it was and still
is an iterative process in which new data structures are added to
existing schemata [5,32,85]. The schema modelling, illustrated in
Fig. 3, shows one development cycle; each new exchange scenario
requiring modifications (or additions) also requires an additional
cycle as illustrated in Fig. 3.
The ‘Integrated Design Model’ (IDModel) [5] is an example of an
external schema based only on the analysis of internal schemata of
Description
Data from the users’ aspect and applications
Concepts from software developers’ aspect, regardless of implementation
Organisation of data, storage, and manipulation within application
 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
Table 5
Available input sources of information about buildings for modelling in BIM.
Source type Content type
Physical-world Buildings, also under construction
(construction results)
Scale building models (man or machine)
Documented Text (word processing tools)
Structured data (databases/spreadsheets)
Technical drawings (CAD/CAE software)
Still imagery (cameras/CAE software)
Audio (midi devices)
Video/virtual reality (camera/CAE software)
Engineering data types (AEC/O modelling tools)
Undocumented Cognition (perception, mental ability)
Sporadically generated(not captured, tacit knowledge)
the AEC/O design tools used in the exchange scenarios. The IDMod-
el procedure includes three steps: (1) modelling of the internal
schemata of individual design tools, (2) analyses of the internal
schemata and their transformation to a common form, and (3)
merging these into an integrated BIM Schema for exchange. The
modelling of internal schemata is not problematic, but canonicali-
sation and matching existing data structures to external schema
has proven a very tedious task [5]. A ‘Modelling Support Environ-
ment’ (MSE) was developed to ease the mapping and conversion
of ARM to AIM. To trace the legacy of this pioneering work, more
recent developments are explored.
Let us begin the critique with Table 5, which lists input sources
that should be used for any BIM Schema that is to constitute a total
sum of information about buildings. It is evident that such a vol-
ume of information cannot be captured in a single BIM Schema.
Therefore, only a reasonable subset of information should be taken
into account. The conceptual modelling depends on the paradigm
behind the modelling methodology (its available modelling con-
structs) and on the use of natural languages. Therefore, the result
of a conceptual modelling may be measured by the coverage of
BIM Schema, its inner structure, usability and usage. The overall
quality of the BIM Schema depends on:
 Input sources of information
 Observation and interpretation of input
 Modelling methodology, languages, and tools
Input sources of information about buildings for BIM Schema
can be divided into the following three categories: (1) real-world,
(2) documented, and (3) undocumented (see Table 5). If all input
sources of information have been used, a BIM Schema in the
form of a total sum of information about buildings may be
obtained. However, the availability, quantity, and quality of
input sources of information are simply too challenging due to
‘information overload’ or due to ‘unavailability of information’
about buildings.
Observation and interpretation of input depends on authors and
modelling tools. The BIM Schema is a ‘documented observational re-
port’ that depends on the ‘observational powers of authors, their per-
ceptions, and attention’. The ‘correctness’ of the interpretation of the
input depends on authors’ prior contextual knowledge, comprehen-
siveness, consistency, and cognitive abilities.
231
Examples of items
Real-world buildings in the building lifecycle. Real-world processes
related to building life cycle
Man-made scale models of buildings. Machine-made, i.e., CNC machines,
3D prints
Specifications, codes and standards, contracts, messages, reports, meeting
minutes, project diaries, RFI/RFC/submittals
Quantity survey data; change orders logs; different forms; employee
payroll records; job cost records; inventory records
Plan views/3D views; elevations/sections; shop drawings; technical
specifications; schematic representations
Site surrounding images; scanned sketches; site images; building
products images; other raster images
Real-time conferencing, audio presentation, recorded minutes; daily
phone conversation for coordination
Time lapse/recorded videos, QuickTime VR; recorded videos, 4D models/
software-generated simulations
Existing schemata, integrated resources, Process models; 3D, GIS data;
simulation models: I/O in native and open formats
Individual cognitive abilities, ability to conceptualise, i.e., memories,
domain knowledge, and explanatory capabilities
Ad hoc solutions that are not documented and sometimes do not possess
any reasonable explanation
Modelling methodology that affects the BIM Schema (e.g., IFC) is
affected by STEP methodology and the IDM (Information Delivery
Manual). Like the IDModel, IFC Schema is a result of an iterative
process with extended exchange capabilities. The modelling lan-
guage syntax and expressiveness of the AAM and ARM strongly af-
fect the BIM Schema. AAM models are most frequently modelled
with IDEFØ or BPML [85]; this may not be appropriate for the
description of causal dependencies and iterative processes, which
are typical of AEC/O projects. ARM is based on ISO STEP Part 22,
which has not changed a great deal in the last 30 years except add-
ing support for multiple schemata and the ability to reference a
single entity. Surprisingly, the expressive powers of modelling lan-
guages, underlying paradigms, and the use of natural language
have never been rigorously evaluated. Although other languages
(e.g., XML Schema [85], RDF [13], UML [32], Object Constraint Lan-
guage (OCL) [54,89], or Object-Z notation [121]) may provide
greater expressive power and new applications, no comparisons
of their use in BIM have yet been made. The modelling tool limits
the authors with its features and interfaces that usually follow a
specific modelling methodology, which may not be fully imple-
mented in the software tool. Due to its ISO STEP legacy, the IFC is
still in one single EXPRESS file, although EXPRESS allows the use
of multiple schemata. Multiple schemata could enable better
traceability and stakeholder buy-in. The IDM and ‘Model View Def-
initions’ (MVD) target one single schema, which reduces manage-
ability. Another key drawback is that the existing procedure does
not eliminate redundant data structures; this especially relates to
data that could be derived from explicit sources (e.g., quantity
take-off data).
Natural language has an important role. Although a BIM Schema
is a nonsentential semantic model that defines entities with types,
relationships, and properties, much of its semantics is also carried
in the natural language used for naming. For example, an entity
could be named ‘Casing4PileFoundation’ or simply ‘conceptX’. To
allow humans to properly interpret it and use it in the software,
the entity ‘conceptX’ would require many complex formal defini-
tions, while ‘Casing4PileFoundation’ already carries a lot of mean-
ing. The semantics of expression in a natural language is very
important but to date there have been no known studies on the effect
of natural language on schemata.
A Review of the five requirements for a BIM Schema (see
Section 4.1) shows that, with the exception of (4) software and
232 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
(5) format independence and extendible semantics, the require-
ments are not yet met. (1) input sources from Table 5 cannot be
covered in the schema; (2) all the information needs of all the
stakeholders cannot be covered; and (3) the IFC schema may allow
redundant or even inconsistent data.
Implicit, derived data are prepared by ‘sender’ BIM tool that do
interpretations and transformations that result in the loss of the
semantics and origin of the exchanged data for a ‘receiver’ BIM
tool. More than 10,000 lines of an IFC 24 schema contain only
52 DERIVE statements, mostly for coordinate systems, axes and
the like. The ‘DERIVE’ statements could reduce redundancies in
model data. Model-based exchange is fairly limited, e.g., linking
and splitting of elements to zones, required for model-based
scheduling and estimating, is not possible, and this could be also
solved with external rules [123].
The standardisation process of IFC in ISO/PAS 16739 follows the
standard six-step ISO procedure that results in three main delive-
rables [62]: the PAS (Publicly Available Specification) is the first
version, followed by the DIS (Draft), which is finalised as the IS
(International Standard). This may take years, and may reduce
the possibility for a timely response to evolving tools. It might be
reasonable to consider some applications of BIM Schema to be
standardised within IEEE Standardisation, which has, compared
to ISO, a far more flexible three-step (initiate-produce-manage)
process [58] and may lead to double-logo IEEE/IEC standards. For
an overview of the development cycles of CAD standards also con-
sult [16].
4.2. ‘BIM Schema’ implementation
The goal of the implementation is to transform a native model
data structure (native file format) from/to a standard data-exchange
structure (open-file format) supported in heterogeneous
environments.
The objective is to define a mapping between internal and exter-
nal schema and vice versa. Some of the mapping rules used by the
translator are hard-coded, while others may be configurable by the
end-users (e.g., geometrical representations). The import/export
process requires two mappings for a translator:
 ‘Model import’ requires a mapping from the external to internal
BIM Schema; and
 ‘Model export’ requires a mapping from the internal to external
BIM Schema.
The ICOMs for the implementation are:
 Inputs: Besides MVDs [56], there are two main inputs for BIM
mapping:
 External BIM Schema: A BIM Schema in EXPRESS for model-
data exchange (i.e., IFC)
 Internal BIM Schema: An ‘internal BIM Schema’ of a BIM tool
implementing IFC support
 Controls: The mapping is controlled by various parts of ISO
STEP, including:
 ISO STEP 21: Part 21 [60] prescribes the structure of a phys-
ical file.
 Outputs: The main output of the implementation is a software
component:
 Translator: The translator may be a stand-alone tool or an
add-on for a BIM tool.
 Mechanism: The implementation is done by:
 AEC/O Software vendors: The developers of engineering
software.
The implementation of integrated tools can be ‘loosely coupled’
(i.e., components are not aware of each other) or ‘tightly coupled’
(i.e., components use shared code). Loosely coupled implementa-
tions can be file-based, direct-link, database, and API [94], or
can be hybrid, (i.e., use combined implementations, such as di-
rect-links and a remote database, as in Vico Office Suite™). For
a file-based implementation, the ISO STEP Part 11 (EXPRESS)
and Part 21 (Clear-text encoding) provide a powerful mechanism;
with a schema, we also define structuring in a ‘step physical file’
(SPF) – the file format for the exchange. In theory, only a mapping
between internal and external schemata is required for each new
translator.
In heterogeneous applications, a direct import/export of mod-
els is often not possible because vendors are unaware of each
others’ internal schemata or file formats. Native file formats
enable vendors to keep their market position, and, therefore, for-
mats are sometimes intentionally ciphered to prevent competi-
tors from developing translators. Note that vendors implement
only those features that improve the position of their software
in the market, and this rule also applies for the implementation
of IFC.
The implementations depend on documented ‘external BIM
Schema’ and ‘internal BIM Schema’. The ‘Model View Definitions’
(MVD) systematically document the existing capabilities for the
exchange and required changes in the IFC BIM Schema [56]. The
problem is that some vendors [111] see the exposure of their inter-
nal schemata as an IPR issue and claim that round-tripping and de-
sign intent have nothing to do with IFC, whereas others believe in
and trust IFC [46,86].
The release cycle of a BIM Schema is a balancing loop with a de-
lay (see Fig. 4), where resulting ‘external BIM Schema’ will always
lag behind ‘internal BIM Schema’. If the exchange between tools is
not supported by the BIM Schema, software developers will use
other formats and/or API to exchange model data. The develop-
ment systems of major players (e.g., Graphisoft™, Autodesk™,
Bentley™, Tekla™, Vico Software, and Nemetchek™) and schema
authors (e.g., IAI, and ISO) have very little synergies.
A simple principle sustains both tools and schemata develop-
ers: end-users buy a new version if improvements are substan-
tial, or if they need it because others are using it. The
development cycles of AEC/O software (BIM tools) follows a
well-known business model common to CAD [66]; each new re-
lease must include new features, improve speed, handling of
models, or/and bug fixes flavoured with new support options.
BIM Schema usability strongly depends on features and inter-
faces of BIM tools.
Modelling: Recent developments have improved surface, mass
modelling and modelling aids, and introduced new concepts, e.g.,
parametric binding of building components, assemblies, lots, ad-
vanced adaptivity and associativity. Along with tools for creative
modelling (e.g., intuitive push/pull extrusion in SketchUp™,
alternatives in Generative Components™ and free-form model-
ling in Rhinoceros™), more creative geometrical conceptual
modelling capabilities have been added to other tools (e.g., dou-
ble-curved surfaces with NURBS and LOFTS in Revit™) and more
features are dedicated to the automation of construction detail-
ing (e.g., components and shop drawings in Tekla™, and
Robot™).
Interfaces: This covers menus, workspaces, views, and standard
features. Traditional, feature-oriented menus are being replaced
with workflow-centric and contextual menus (e.g., ArchiCAD™,
SketchUp™, Ribbon in Revit™, and Mini toolbar in Tekla™). Work-
spaces, toolbars and components can be customised (e.g., favour-
ites in ArchiCAD™, ‘most recently used’ in Bentley™), and allow
better control of views (e.g., 3D UI control, X-ray, and part visibility
filtering.). BIM tools adapt standard MS Office™ features (e.g.,
intelligent context-aware copy-paste on and between model parts,
its properties, and templates).
 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
Fig. 4. The BIM development causal model. The BIM tool-development process has two reinforcing loops: (R) the incremental growth of BIM tools’ core features and (R)
improvements in inter-operability, and a balancing loop: (B) ‘BIM Schema’ releases.
A BIM Schema should support as many as possible modelling
constructs and interfaces important for project communications.
In conceptual modelling and implementation there is one common
important problem: how to identify the same schema concepts
and/or their instances. Many implementation problems emerge be-
cause there is no unique mapping (‘‘bijection”) between concepts in
internal and external schemata. Important barriers to bijection be-
tween instances (BIM Models) are geometry-related:
 Redundant geometries that represent the real-world: The same
geometry can represent several real-world components (e.g., a
simple box can be used to represent foundations or columns)
and modelling is arbitrary (e.g., a foundation may be modelled
with one or more boxes).
 Redundant geometrical representations of geometries: Different
geometrical representations (boundary, CSG, or surface model)
can represent the same geometry (e.g., a simple box).
4.3. ‘BIM Model’ sharing
The goal of model sharing is to enable project stakeholders and/
or tools to use a ‘BIM Model’ outside of its native modelling
environment.
The objective of model sharing supported by ISO STEP is to as-
sure inter-operability between heterogeneous tools through a
standard format defined with a schema (e.g., IFC). The ICOMs are:
 Inputs: The sharing in the actual building project requires mod-
els in formats that depend on:
233
 Project communication: Actual building project communica-
tion between stakeholders.
 AEC/O models: Models in native or open formats that are used
as inputs for import/export.
 Translator settings: Options for import/export depending on
purpose, e.g., for energy analysis, for structural analysis, or
for quantity takeoff [46].
 Controls: The import/export is controlled by software and
implicitly also by ISO STEP.
 Outputs: The model(s) to be used outside the native modelling
environment:
 Shared BIM Model: The access to models can be either snap-
shot, view, file or database [35]. A shared BIM Model may
contain data structures modelled by several heterogeneous
tools.
 Mechanisms: AEC practitioners and AEC/O tools with embed-
ded translators for import/export.
The illustration of a shared (as a central) product model has
been used for years with different interpretations; for software
developers, the central circle is their BIM tool or native model,
while schema developers understand it to represent a standard
BIM Schema (e.g., an IFC). Model sharing depends on ownership,
access, format, size and dynamism. The exchangeability E depends
on the model (its size, granularity and complexity), the tools, the
exchange method, and the literacy of the involved participants:
BIM  ExchangeabilityðModelÞ
¼ EðModel; Tools; Method; ParticipantsÞ
234 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
If two BIM tools that manipulate two models, which are merged
into one single model, are observed, three triplets characterise the in-
ter-operability between two or more BIM tools:
 Three modes of model access: (1) sequential, (2) parallel, and (3)
concurrent;
 Three types of standardisations: (1) formats, (2) schemata, and (3)
APIs [24]; and
 Three levels of implementations: (1) file, (2) active, and (3) data-
base [32].
Sequential use of models: In this mode, models are exchanged
asynchronously (Table 6). The MVD categorises the sequential ex-
change into Export, Import, Roundtrip, or Generic [85]. In the
sequential exchange source-model data cannot be queried interac-
tively; instead, downstream applications (import-only tools, as
illustrated in Table 6) must work with the data they get and must
use transformations (e.g., reductions, simplifications; translations,
and interpretations [12]). If a direct exchange between two tools
is not possible, some features may be exchanged through an ex-
change path of imports/exports that includes several tools. This
path may be determined from the registry of tools linked to sup-
ported formats and features [9]. Recently, the exchange in hetero-
geneous environments is facilitated (e.g., ArchiCAD™ Open design
collaboration; Allplan™ Round-tripping [46]), but the difference in
models, incompatible modelling constructs and APIs make inter-
operability and automation very difficult and unreliable.
Parallel use of models: In this mode, two BIM tools use the same
source-model and each tool can make changes to a model synchro-
nously and independently; these changed models are later submit-
ted, versioned, reviewed and merged (Table 6). The parallel use of
models from different physical locations requires a central reposi-
tory for a model, like the model server that was implemented al-
ready a decade ago for homogenous environment [2,97]. Long
transactions [2] are essential for the transition from single-user
to collaborative CAD because end-users are, as a result, able to
work individually and submit their changes to a remote server;
users can later track who did what and when (e.g., entities added,
updated, or deleted). If models from the same or different domains
are manipulated in parallel, they must be merged, or at least
checked for consistency with tools enabling clash detection (e.g.,
ArchiCAD™, Tekla™, NavisWorks™) and change management
(e.g., Bentley Project Wise™, Vico Doc Set™, and Tekla™).
Concurrent use: In this mode tools have a constant connection,
either to the remote database, or work as peer-to-peer to submit
changes to a target model (Table 6). Up to date, the concurrent
use is only possible in homogeneous environments, either via (cen-
Table 6
Synchronicity of ‘BIM Model’ sharing from the standpoint of information flow, location, teamwork stages [114] and collaborative features [119]. Note that some asynchronous
teamwork activities are pre-requisites for synchronous use of models.
Standpoint (When)
Information (What) Model
Model contents exchange
Workflow (How) Information flow from a source-model (SM)
to a target model (TM) used by
BIM tools (#1 & #2)
Location (Where) Same
Different
Teamwork (Who) Forming
Norming
Storming
Performing
tral, master) native file shared on the network (e.g., Tekla™, Re-
vit™, Allplan™, ArchiCAD™ 12), on a remote database
(VicoOffice™), or on a BIM server (e.g., Bentley Project Bank™, or
ArchiCAD™ 13). The model server enables a complete audit trail
as in ‘concurrent versions systems’ (CVS), while BIM tool is used
to submit, receive, review, and merge model data on the client side.
Remote, database-centred, applications are changing the way in
which CRUD (Create, Read, Update, Delete) operates on models:
to speed-up the process of model exchange model content is ex-
changed at smaller granularities (e.g., ArchiCAD™ 14 Teamwork).
Table 6 reviews synchronous or asynchronous sharing of mod-
els. Note that sequential exchange is always asynchronous, while
parallel and concurrent use of models may have different synchro-
nicity levels, for example, long transactions can last days, while
some model data may be exchanged instantly.
Teamwork features in current BIM tools enable coordination of
modelling work (e.g., modellers can have identities, assign tasks/
rights for the model elements, layers, and zones), send/receive
model data, and allow basic communication (e.g., messaging, com-
menting, redlining, and tagging of models within BIM tools). How-
ever, support for tactical coordination [119] is weak, therefore,
there are many possible improvements for norming, storming
and performing teamwork phases (see Table 6). Note that it is usual
that only a small portion of modelling results are communicated to
other project stakeholders, who often do not know in advance what
exactly they need, and once they need a specific data, they want it in-
stantly. Therefore, BIM Models should be available in special model
repositories (e.g., Vico Doc Set Manager™), on remote project port-
folios (e.g., Onuma), or on public repositories (e.g., SketchUp 3D
Warehouse™; Autodesk Seek™). Very promising are also new
standards, like 3D PDF™ [61] for archival, and X3D, U3D, O3D
and Web3D for interactive and linked models with services. The
increasing number, size and complexity of models require better
‘information retrieval’ (IR). Querying of models (or model contents)
is possible within BIM tools (e.g., Find and Select ArchiCAD™; Tek-
la™ Filter), while searching for BIM Model contents (e.g., views,
parts) is not supported externally to BIM tools.
5. A framework for technological development
The technological advances in project communication with BIM
are also affected by three lifecycles:
 The lifecycle of a building project: The phases (pre-, construction,
and post-) and stakeholders’ legal relations (own, design, bid,
build, operate, use, or transfer) define the project lifecycle.
Asynchronous Synchronous
BIM Model exports and imports BIM Model on server or CVS
Whole models, libraries, xrefs Elements, components, views
#1 Export SM Import #2 Load #1 Submit
Roundtrip SM Concurrent access TM
Import TM Export Load #2 Submit
Versioning/Revision/Change Merge
Single user BIM tools, files, screen Caves, augmented reality
Snapshots, files, merged model Immersion, long transactions
Invite members, assign team roles BIM presence indicator
Rise attention, propose solution Negotiation, discuss rationale
Revise, roll back, comment, tag Floor control, tracking changes
Commit, audit trail, versioning Participative BIM modelling
 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
 The lifecycle of BIM technologies: The maturity (cutting-edge,
state-of-the-art, dated, obsolete) and the release cycles of infra-
structure, hardware, and software define the technology
lifecycle.
 The lifecycle of a BIM Model: Two stages, active (CRUD and man-
agement of model contents) and inactive (retrieval and man-
agement of metadata and models) define the model lifecycle.
These ‘lifecycles’ (and systems that support them) are inter-re-
lated and may also affect other lifecycles (e.g., building lifecycle)
and systems (e.g., organisational system). In this context, ‘inter-
operability’ is required on the technological, semantic, and organi-
sational levels [38]. The inter-operability depends on the ability of
systems to be aware of other systems (Section 1.2) that can be
achieved through ‘standardisation’ (development, implementation,
and deployment). BIM standards can be those used within a do-
main (e.g., CAD [16]), project, organisation, or industry (e.g., NBIMS
[78]). The three axes, lifecycle, inter-operability, and standardisation,
define the ‘BIM cube’ framework (Fig. 5).
Table 7 gives an overview of barriers and limitations depicted
on Fig. 5. A detailed description of recommendations and applica-
tion of the framework is suggested in the sub-sections.
5.1. Recommendations for ‘BIM Schema’ development
The development ‘BIM Schema’ should improve gradually. Be-
fore any substantial changes are made to the schema, its assess-
ment, existing potentials, coverage, and modelling features should
be studied.
Assessment: analyse the usability and manage-ability of the ‘BIM
Schema’. The ‘BIM Schema’. features should be categorised as (1)
essential/critical/customisable from the standpoint of schema
developers and certifiers and as (2) easy/hard/impossible from
the standpoint of software vendors and of end-users. Schema
developers and software vendors should document barriers for
mapping to/from ‘external BIM Schema’. Vendors should record
the effort required for the implementation, typical errors and error
rate, and their satisfaction. The establishment of these criteria
Fig. 5. The ‘BIM cube’ framework for technological development of project communication and information management with model-based communication. The adoption,
technological development and advancement of BIM in building projects depends on standardisation and inter-operability, intelligence (left) and barriers (right); illustration
inspired by [38,108].
235
could facilitate schema development and ease the introduction of
new implementations. Using a ‘BIM Schema usability metrics’, it
would be possible to identify frequently changed and/or problem-
atic parts, which could be developed separately as a subschema
that could change more rapidly, as proposed in [57].
Existing potentials: make more use of the existing ‘BIM Schema’.
The use of a ‘BIM Schema’ is very limited (to exchange only), but
could be used for the following: information retrieval, adaptive
model presentations, for formal reasoning, for connectivity be-
tween virtual and physical worlds, for networking with hardware
such as sensor networks in intelligent buildings, for connectivity
among various models, or for schema-based compression [120]
of BIM Models, enabling the use of large models on mobile devices.
Existing coverage: analyse input sources for a BIM Schema. The
analysis and traceability of the schema coverage should study
the following: (1) the representational media (e.g., professional lit-
erature, building codes, and project documentation), (2) processes
supported by viewpoint modelling [31], a technique well known
from requirement engineering, which would base on observations
and interviews with experts in various stages of building projects,
(3) ‘internal BIM Schemata’ of AEC/O tools, (4) differences between
as-designed and as-built models, and (5) comparison of model-
based communication throughout project phases, i.e., as-designed,
as-built and as-exchanged models for different project types.
Modelling features: make a comparative study of modelling con-
structs. The study should evaluate the affect of the conceptual mod-
elling methodology and natural language on the BIM Schema. A
possible approach is the comparative meta-ontology, the ‘Bunge–
Wand–Weber’ (BWW) framework [99], that evaluates the model-
ling language by (1) grammar, (2) method, (3) schema, and (4) con-
text. However, it still does not cover the semantics carried in the
natural language used for BIM Schema features.
Based on the review and critique, a gradual improvement of the
BIM Schema should continue with automation, contextualisation,
canonicalisation, and meta-schemata.
Automation: facilitate BIM Schema modelling. The qualitative and
quantitative coverage of a BIM Schema depends on the speed and
consistency of modelling. Therefore, semi-automatic techniques
236 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244

Table 7
Barriers and limitations, developments, and recommendations for BIM technologies and standards.

Activity Barriers and limitations R&D developments Recommendations

BIM Schema Usability and manage-ability [14,57,94]
development
Limited use of ‘BIM Schema’ [85,88]
Limited coverage of a ‘BIM Schema’
[15,33,113]
Expressiveness of modelling constructs and
complexity [42]
Manual modelling and mapping to concepts
[5]
BIM Schema Barriers to implement-ability of ‘BIM Schema’
implementation features [57]
Limited information on internal schemata
[111]
Insufficient testing procedures [68]
Unknown loss of information [68]
Redundant implementation [5] [75]
BIM Model sharing Limited availability; use; re-use; model data
(deployment) structuring [84,88]
Limited capacity of tools to connect non-3D
and 3D data [78]
Limited teamwork features [119]
Static presentations; limited referencing of
models [69]
Single user communication channels
[76,84,123]
BIM Model development Inconsistent/time-consuming manual
(technologies) modelling [84]
Tightly coupled solutions Revit™, Bentley™,
Allplan™
Time-location technology [10] limited
integration of models
Project lifecycle models [44,49,66], not-
connected, manually modelled
Professional applications [53] and single
model applications
Metrics; schema size reduction [7,57,88]
Document existing capabilities [56];
identification of patterns [107]
Analysis of input sources [56,88]
OO Metrics [23,42,100]
Schema modelling automation [40,72,73]
MVD and predictable releases of BIM
Schema [56,57]
BIM tools’ API, e.g., SketchUp™, Tekla™,
Allplan™
MVD-based certification process [56]
Self-assessment of exchange scenarios
[120]
Redundancy reduction [11]
BIM repositories [20,22,48]; 3DPDF;Vico
Doc Set Manager
Work-task frames [78]; semantic
enrichment and KM [17,98,112]
Versioning, change-merge concurrency
[50,87,97,99]
BIM augment reality [51]; immersive
technologies [71]
Multi-user communication channels
[23,84]; ArchiCAD™ 13
Templates [23,117]; patterns, model-based
reasoning [107]; APIs
Space-based SoA [24,47] Onuma™, Vico
Open Office™
Location-aware apps [19,67]; EEML;
VRcontext™
Laser, photo-gram; automatic as-built
models [21,39,93,95,104,106]
Non-technical apps (ArchiCAD VBE™, Vico
5D™, Onuma™)
Schema profiling with metrics, and
advanced usability metrics
Make more use of schema: IR, reasoning,
compression, networks
Study presentational and representational
media
Comparative study of constructs BWW and
use of natural language
Schema automation; canonical form;
evolutionary ontology
Implementation metrics for developers and
implementers
Dynamic external; automatic API/script
internal schema
Repeatable testing procedures with audit
trails and specimens
Estimate data loss in exchange – with
round-tripping ratio
BIM canonical form and joint certification
for specific MVDs
Vocabularies for BIM Models; BIM search,
interactive, e.g., X3D
MVD based workflows; cross-functional
recordable API
Tactical coordination; multiuser BIM
adaptation, BIM wave
Soft-associativity with platform-
independent BIM URI
Commutation test; multi-domain
communication intelligence
Open templates; automatically generated
reverse schemata
SaaS on BIM elements & Framework for PAC
vs. MVC
‘time–technology–task–location’ (T3L)
driven BIM applications
Technological BIM Models CASB complex
adaptive BIM
Non-technological BIM Models with
decision-support systems

could support conceptual modelling, i.e., especially with the iden-
tification, grouping and comparison of existing and newly mod-
elled entities. Some attempts to automate schema modelling
have included: dynamic modelling from linguistic analyses of the
content from several exchange scenarios, where automatically
generated concepts may be used for detailed manual conceptual
modelling [40]; generation of a BIM Schema based on textual doc-
uments [72]; from process models; and real-world building com-
ponents [73]; and parametric meta-schemata [79]. Another
important issue for schema automation is the forward and back-
ward compatibility of schemata versions and existing instance
models in open-exchange formats.
Contextualisation: provide support for adaptive BIM Models for dif-
ferent tools, purposes and audiences. Semantic enrichment could in-
clude multidisciplinary annotation of BIM. This could add new
expressive power and adaptive presentation styles (e.g., interactiv-
ity, semi-automatic identification of concepts, linking, and defini-
tions). In this manner, the content could be interpreted more
easily and could make models to be used and re-used properly,
and more easily integrable into decision-making systems [17].
Canonicalisation: develop BIM canonical forms. The canonical
form (Section 3.1) could ease the implementation of translators;
improve the consistency of schema modelling; ease the exchange,
and merging of model. It could provide a common denominator for
similarity measures required for the comparison of models, or for
the identification of parts of models that are common to different
models. These could enable identification of parts that could be
re-used, or parts that were repurposed or otherwise related. The
redundancies in BIM Schema could also be more systematically
identified, categorised and eliminated. A canonical form of models
and schemata could also be developed semi-automatically.
Meta-schemata: promote evolutionary ontological development.
The solution could be an evolutionary ontology theory developed
with a standard ISO 19673, which includes the ‘Metadata Frame-
work for Inter-operability’ (MFI). Ontology also explicates the
implication of domain concepts. When there is a change in the do-
main or in people’s viewpoints, ontologies require updating. An
important part of the approach utilises the ‘four layers’ of RGPS
(Roles, Goals, Process, Services), which could provide an appropri-
ate approach for constantly evolving AEC/O practices and tools.
 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
5.2. Recommendations for ‘BIM Schema’ implementation
The implementations could be improved by documentation, test-
ing, automatism and collaboration.
Documentation: of implementation. Documented implementation
and certification could significantly ease new implementations. The
implementers of a standard BIM Schema should publish what they
have implemented, i.e., parts of internal and external schemata.
Software vendors could also publish workflows that work across
several AEC/O - BIM tools and services. These workflows should
be external to the tool and fully functional, at least for those MVDs
that vendors have implemented and were certified.
Testing: with round-tripping ratio. The initial testing of the
implementation should start with a self-test in the form of
round-tripping, as known at w3c [120]. Any implemented format
or API for exchange should be labelled as loss (data are lost), lossless
(no lost or changed data), or exact (no changes). Third-party bench-
marks, similarly to the ISO STEP ‘conformance-testing procedure’,
should be repeatable, comparable, and auditable. Most of the
third-party benchmarks of the IFC implementations are not repeat-
able and, therefore, cannot be treated as scientific. Each benchmark
report should provide a description of inputs, procedures and outputs,
i.e., it should provide the items listed here: the specimens used, ex-
act and complete descriptions of the settings for the translator,
tools and operating system, documented workflow with a com-
plete audit trail of individual operations, and interim results of
each step. Although ‘round-tripping’ is not a certification criterion,
as noted in [111], it would be helpful for the end-users to know the
‘round-tripping ratio’, defined as the number of external or internal
schema entities that can be round tripped divided by the number
of all entities in an internal or external schema.
Automatism: internal and dynamic external schema. Any BIM tool
that has documented API and scripting language could generate its
internal schema automatically. The availability of internal schemas
could allow third-party vendors to develop interfaces to external
schema. BIM tools’ translators should also allow for the use of
(whole or a part of) schemata dynamically, and not only one
hard-coded schema.
Collaboration: in certification. The certification should enable
complex workflows that may involve several software packages
from the same, or from different software vendors to be certified
for a specific ‘Model View Definition’ (MVD). This may lead to com-
plex workflows, possibly supported by external workflow engines to
work as robustly integrated applications, thus expanding the exist-
ing capabilities of IFCs. The eligibility criteria for participants in
collaborative certification should be strictly defined.
5.3. Recommendations for ‘BIM Model’ sharing
BIM Models should be first available, accessible, and searchable
in BIM-aware repositories (with advanced tools, services, methods
and techniques), and support teamworking, networking and
automation.
BIM-aware repositories: with linked tools and web services. BIM
Models should be pre-processed and made readily available in cor-
porate BIM libraries as content with assigned metadata; labelled
with copyright license templates, indexed and searchable. The
BIM-aware repositories could enable the evolution of a new gener-
ation of services and business intelligence applications, e.g., BIM
querying, dashboard, business semantics, aggregators, decision-
support systems, BIM-based Technology-Enhanced Learning (TEL)
and competency management. The workflows related to BIM Sche-
ma and BIM Models could provide a very rich context for learning.
The models throughout a project lifecycle require information
management beyond neutral file exchange, where models should
be made available also for nontechnical users (e.g., ArchiCAD VBE™
237
and Vico 5D presenter™). This should be assisted with interpreta-
tion utilities, which could act as a learning technique that com-
bines factual with stimulating explanatory information and may
allow use of models at different levels of abstractions.
Teamworking: generic versioning and change-merge control. BIM
tools should improve the support for all teamwork stages (forming,
norming, storming, and performing) as described in Table 6 and
enable collaborative real-time (Google Wave like) applications. A
generic API for versioning and change-merge supported by a set
of BIM canonical forms could facilitate collaboration in heteroge-
neous environments. Additionally, a problem of referencing be-
tween BIM Models [69] could be solved with a BIM URI (BIM
Uniform BIM Resource Identifier) standard allowing platform-
tool-format-independent referencing to views, parts, components,
and other model contents (e.g., house.ext#floor = 1&room =
2&select = columns).
Networking: automation, channels and actuators. Researchers
should study BIM communication, particularly communications
channels and semiotics. The automation should focus on repetitive,
time-consuming tasks: remodelling and conversions throughout
project phases. Evolution should lead to BIM actualisation that re-
fers to active product models (APM) that are modelled and ‘exe-
cuted’ in a connected digital medium, which can actively (in
real-time) affect its subject’s system. Automation and actualisation
could enable easier transitions among models required in a project
lifecycle (i.e., from as-designed to as-demolished, see Section 3.2)
including the recognition of physical models [39]. A model-based
actuator could act as a plug-and-play interface that triggers rele-
vant actions for hardware/software related to BIM.
Existing limitations and barriers to model sharing could be ad-
vanced with applications that would enable BIM adaptation, view-
based collaboration and collaborative intelligence,
BIM adaptation: to allow for repurposing, templates, and decision-
making. Most BIM tools were developed for designers and not for
nontechnical end-users. BIM Model presentations should be adapt-
able to the following: (1) the audience – the needs of the technical
and nontechnical project stakeholders, possibly as defined by ubiq-
uitous end-user profiles; and (2) the computing environment – the
modality, hardware and software used for presentation. The adap-
tation of the model requires pre-processing of the model data. The
solutions should enable repurposing, which would operate on li-
braries and integrated BIM Models. Models should be transformed
for future needs in the form of templates to allow for the re-use of
related organisations, process workflows, or products.
View-based collaboration. Many communication problems are
caused by insufficiently communicated design information result-
ing in incorrect model interpretation by receivers because receiv-
ers do not have sufficient information about semantics and
context, which could be stored in collaborative data-views.
Collaborative intelligence. A possible solution may be found in BIM
collaborative intelligence, which could significantly improve semi-
otics and BIM as a communication medium in collaborative prac-
tices. The collaborative intelligence could advance cross-
institutional support for participative types of BIM authoring, distri-
bution, and retrieval. The BIM tools’ teamwork features should
therefore go beyond simple roles, basic model rights for model CRUD
and coordination to task management, negotiation, and tactical
coordination. Relevant features should include those listed here:
 BIM context and reference carriers: The referencing to and
between models should be application-independent and could
provide connectivity among models, tools and services.
 BIM transformation carrier: Information on settings for import/
export features should be carried within the exchanged model
file, transferable for later use and repeatable from the base
model.
238 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
 BIM intent and soft associativity: Soft associativity could manage
links between information without hard-coded event handlers.
The design intent should be stored within a model. Tools should
be able to identify features native to current tools and parts that
affect other models/tools.
 Workflow templates: Workflows may include third-party appli-
cations and can be defined manually or through process mining
of audit trails or/and conceptualised workflow patterns [23].
5.4. Recommendations for BIM technologies
The main goal is not only to improve BIM tools, but also insuf-
ficient information management [78] of BIM data. Future BIM
technologies should assure flexibility with advanced services, inte-
gration of diverse model, adaptation, design intelligence, competency
management, model capturing, querying and re-use. To achieve these
goals model-based services [92] should be developed and make
use of:
 Balanced use of MVC and PAC Architectures: The Model-View-
Controller (MVC) is overused compared to the Presentation–
Abstraction-Controller (PAC). Most BIM tools use MVC, which
is justifiable only for those software systems that hold an entire
model in memory during operation. There are many potential
applications that do not require holding the whole model in
the memory (e.g., Business intelligence). An open-source PAC
framework could lead to a new generation of BIM tools.
 Space-Based Architectures and ‘Software-as-a-Service’ (SaaS):
Space-based architectures (SBA) combine service-oriented
architectures (SOA) and distributed resources such as grids.
SBA architectures are especially appropriate for AEC/O software
if: (1) pre-processors can be deployed separately, and (2) the
processing is time consuming. With the evolution of web ser-
vices for BIM technologies, SOA architectures could support a
new generation of BIM applications [24,47].
Flexibility with ‘software-as-a-service’ (SaaS): SaaS gives a full
control of programming code, easier updates, and allows more
flexible licensing. The SaaS could support explicitly or implicitly
intra- or inter-linked in textual or geometrical model contents,
which should be available at different granularities and in several
BIM Model spaces. These may be achieved with BIM ETL (Extract,
Transform and Load) locally or remotely (see Fig. 6), enabling
open integration, adaptation, intelligence, management and data
re-use.
Integration of diverse models: The integration may include: CAD/
BIM/GIS models with ETL (e.g., Safe.comTM), schemata (e.g., IN-
SPIRE, CityGML, IFC, IFD), models and sensors, (e.g., ‘Extended Envi-
ronments Markup Language‘ (EEML)), energy analysis (e.g., ‘green
Fig. 6. ETL (extract, transform, and load) supporting the information management of BIM Model data and services.
building XML’ (gbXML)), and data warehouses [48]. User interfaces
may integrate city, site terrain, building, equipment models [19],
or, additionally, aerial photography, lidar, and BIM/CAD models
in a VR environment (e.g., VRcontextTM).
Adaptivity: CASB – ‘Complex adaptive system’ CAS with BIM: CASB
illustrates the application of the BIM Cube framework within de-
sign process (Fig. 7). It includes standardization, inter-operability,
and intelligence connected to a five dimensional information space
[28]: process, product, project, resource and knowledge. CASB
could connect different BIM Models, its parts and external services,
and adapt to a changing environment so that it could have the
capacity to change and learn from past activities.
Design-intelligence: The approach illustrated in Fig. 7 could be
used to automate the transition (mapping) between architectural
design and construction technology. This mapping is defined by
three components: (1) a source architectural model, (2) a target
technological model and (3) a mapping between the two. A
source BIM Model could be made of different geometrical
entities, whereas the target model should show key aspects of ap-
plied construction technology. The ‘Model evaluator’, ‘Technology
Intelligence’ and ‘Technology Mapper’ are mechanisms imple-
mented for business intelligence connected to CASB that support
designers in their decision-making. Services could be distributed
while each construction company could develop its own informa-
tion spaces, and different technology mappers for the technolo-
gies they use (e.g., a Precast Mapper or a Steel-Facade Panel
Mapper).
BIM-enhanced learning and competency control: The adoption of
BIM depends on a maturity level that requires business process
re-engineering [88]. The BIM literacy of project stakeholders is a
key for the adoption of BIM. BIM Models could be an excellent
source of information about building projects and could serve as
reference models for learning and competency management of
individuals, teams, and organisations. The BIM-aware repositories
could represent the core competencies of a company and provide
up-to-date dynamic monitoring of the existing skills and knowl-
edge needs of the AEC/O companies, which identify existing com-
petencies and gaps that indicate learning opportunities. A BIM
Model could also be used to represent design competencies that
are mapped to the design problem.
BIM Model capturing, querying and re-use: Technologies should
support capturing, collection, and transfer of BIM Model knowl-
edge throughout entire project lifecycle. As-built models can be
created automatically, e.g., laser, machine vision, RFID, or photo-
grammetry [21,39,93,95,104,106]. The information management
and retrieval of models would require new crawling, indexing,
and querying techniques. The adaptation should use communica-
tion patterns to facilitate interpretation and to enable the re-use.
The patterns for re-use can be identified through machine-learning
 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244 239

Fig. 7. CASB – Complex Adaptive System with BIM for design intelligence based on BIM Cube framework.

techniques [107] or through manual modelling [23]. An algorithm 6. Discussion

could use a set of BIM Models to generate a reverse subschema
(template) common to a selected set of BIM Models. The templates
could also be used for different:
 Modelling environments: workspace templates with views,
modelling templates (workflows, views, and zones), and
documentation (BIM lifecycle/stakeholder/scale-dependent
presentations).
 Modelling granularities: from components (e.g., stairs), systems
(e.g., HVAC systems) and parts to whole buildings. The granular-
ity of models is important for both searchability and re-use.
The purpose of this section is twofold: (1) to discuss the BIM
Schema with a systems-thinking approach, and (2) to validate
the suggested framework and conveyed knowledge, and to provide
metrics.
6.1. A systems-thinking discussion of schema
From the systems-thinking perspective [122], a BIM Schema has
the role of a super-observer, because it must support a multiplicity
240 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
of views and aspects. To this, it is essential to answer two
questions:
 What is observed? The BIM Schema is the result of observations,
while schemata implementations are tested experimentally.
The BIM Schema depends on the interest, attention, interpreta-
tion, and documentation of observers. BIM Schema authors can
only describe things as they appear to them, and these observa-
tions depend on their previous experiences. Additionally,
observables are vast amounts of constantly changing informa-
tion (real-world, documented, and undocumented) that have
multiple representations; the same model data are often
replicated in multiple communication channels, while some
information may be lost in the project lifecycle and not cannot
be observed.
 Does the data-specification language support observations? Alter-
natives to EXPRESS, e.g., OCL, OWL, or Object-Z, could provide
better handling of states, contextual statements, pre- and
post-conditions, and narratives. Thus, an existing schema,
upgraded to OCL or OWL, could enable greater formal reasoning
power. Here, it is also important to understand the difference
between a building-classification system and a BIM Schema: a
BIM Schema is developed for different views, while building-
classification systems are developed for a specific view. A ‘BIM
Schema’ may be developed for different views, but not without
a view. A fragmented viewpoint modelling [31] that represents
isolated views could significantly improve schema stakeholder
buy-in, the traceability of contributions, and the speed of con-
ceptual modelling, which could, in long run, provide delayed
commitment of alternative representations positively affecting
the evolution of a BIM Schema.
Conclusion: the definition of a schema in Section 3.1 should be
extended as follows: ‘A schema is an observational report in the form
of a non-linguistic structure, which describes a collection of states of
information about buildings. It is a subjective semantic model as it is
based on the perceptual abilities of authors and their expressive pow-
ers, and limited by the input, methods, languages and tools used’.
6.2. Validation and metrics
In this section, the framework is validated according to the six
categories of validity [3]: descriptive, theoretical, interpretive, rea-
soning, internal, and external.
Descriptive validity: The relevance and significance of this study
extend the outcome of previously conducted related studies
addressing similar issues, i.e., problems related to the BIM Sche-
ma-development process [32,42,57,73,113], issues related to BIM
frameworks [88,108], and research methodologies [84]. However,
the enumerated studies differed in focus, level of detail and cover-
age. A distinctive property of the present work is its complemen-
tary methodological approach, and multiple standpoints that
provide the basis for suggestions for the development of a BIM
Schema for exchange.
Theoretical validity: The seven requirements for the research-
methodology validation were identified based on the initial litera-
ture survey, review of research, and developments in commercial
tools and standardisation. The approach was based on observa-
tional theory [18] and process analysis [81] supported by a sys-
tems-thinking theory [122] that all fulfilled the goals of this
study. Because there is no single tool that can handle all the re-
quired information about buildings, there will always be a need
to share models between tools. This issue requires the study of
cost/benefits of different tools on a project basis [29].
Interpretive and reasoning validity: The process model and sys-
tems-thinking analysis of the BIM lifecycle establish a framework
for further research on activities and ICOM components. This rea-
soning is supported with the review of related developments, a de-
tailed review of software features, a process model, and an ‘SoS-
BIM’ model. Conclusions are made based on references to schemata
and tools’ features, end-user needs, and developers’ strategies. Fur-
thermore, the paper establishes a comprehensive critique and rec-
ommendations for tools and standardisation that may lead to new
research directions.
Internal and external validity: Statements provided in the pa-
per are supported through the process and systems-thinking
analyses. The claims may be also generalised to other fields be-
yond the AEC/O domains building-project context, and BIM. Sim-
ilar problems are common to other industries, including product-
data technologies within the STEP framework and in general (as
described in [43]), requirement engineering [3] and software
engineering. The adopted research methodology can also be ap-
plied to many other relevant fields; the same is true for the
standpoints. To sustain interest in the BIM Schema it should ex-
hibit trust and competitive advantages over other formats and
API.
The progress in BIM solutions must be measured both qualita-
tively and quantitatively. Identified standpoints in Sections 3 and
4 can be used to measure and streamline the technological, organ-
isational and personal advantages of the BIM Model and BIM
Schema:
 BIM Model metrics: Metrics shall be based on both internal and
external BIM model metadata, type of modelling constructs,
CRUD with times and participants, data exchange (the [sub]
schemata, features, formats, and API utilised), IPR (access and
copyrights), and system environment (models, tools and ser-
vices). The metrics should provide model-based audit trail,
not only who did what, when, but also why and how, and
should reveal communication problems.
 BIM Schema metrics: The metrics should provide measures for
usability, correctness, complexity, and coverage of modelling
constructs. Note that object oriented (OO) metrics known from
software engineering can be used only partially (e.g., depth of
inheritance tree and number of children [7]), while complete
metrics like MOOD [52] could be used for BIM tool code (e.g.,
encapsulation, inheritance, coupling, and polymorphism). How-
ever, there are no known metrics for measuring a BIM Schema’s
correctness, coverage, constructs and natural language. BIM
Schema authors and certifiers should categorise features as
essential/critical/customisable.
 BIM Model usability metrics: The usability metrics should cover
derivatives of the model, usage of parts of the model, specific
use in other applications, broken connectivity to exchanged
BIM Models, and/or information-retrieval services, and possi-
ble inconsistencies caused by the communication channel.
Utilisation of the BIM Model usability measure could be pro-
vided through a comparison of ‘as-designed’ and ‘as-built’
models. The metrics could provide ‘key performance indica-
tors’ (KPI) from technological, organisational and personal
standpoints.
 BIM Schema usability metrics: The metrics should cover the cer-
tification process, which currently may not exhibit trust and a
sufficiently critical relationship between schema developers
and software vendors (from the standpoint of industry practi-
tioners). BIM Schema usability metrics should quantify times,
error rate, satisfaction and features in external schema as
easy/hard/impossible compared to the internal schema. The
usability metrics for both the BIM Model and Schema should
track changes and release criteria for releases of BIM tools and
standard BIM Schema and relationships between model,
schema and audiences (end-users).
 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
7. Conclusions
The recommendations presented in this study are important for
researchers, software developers, and end-users of BIM solutions.
The results include methodological and practical directions for
improvements of BIM tools and BIM Schema standardisation. The
concept of a standpoint proved to be very powerful and goes be-
yond the notion of domain, perspective, viewpoint or aspect.
Standpoints may include technological and non-technological is-
sues and can be freely combined for research purposes.
The requirements for the methodology of this study, as well as
the methodology itself are valuable results that contribute to a bet-
ter understanding of BIM potentials. The methodology combines
the advantages of conceptual process modelling and the holistic
power of systems-thinking concept of ‘System-Of-Systems’ (SoS).
This gives a complementary approach in which the inability of IDEF
to model cycles and causal dependencies is compensated by sys-
tems-thinking. With this approach it is possible to identify many
relevant standpoints that can contribute to the improvement of
BIM technologies and standards, in such a way to match evolving
practices and communication channels.
The dilemma arising from the past success of standardisation
and future decades of development of a standard schema should
be reworded as follows: ‘‘How can a BIM Schema support constantly
evolving tools and practises?” BIM tools and services are not, and
never will be, finished. Therefore, BIM Schema should be con-
stantly improved (and never finished) to be able to support evolv-
ing tools, ICT, and practices. However, because paradigms have not
been changed after 30 years despite drastic changes in ICT and col-
laborative practices, the assumptions used for a BIM Schema
should be revisited.
A BIM Schema development should be a living system. Govern-
ments should support BIM Schema standardisation because it
can improve the management of governmental assets. Standards
provide three important roles: (1) inter-operability, (2) trust, and
(3) comparability. To date, BIM standards, such as IFC, have suc-
ceeded in making only partial progress in inter-operability;
although limited, this progress is very important and its impact
will be evident years from now. However, BIM standardisation
does not yet exhibit trust or enable comparability. A major prob-
lem is BIM Schemata redundancy. A Schema should not allow
any explicit data structures that can be derived from other expli-
cit data structures. Such quick fixes speed-up schema develop-
ments but cause redundancies that may lead to inconsistencies
and new inter-operability problems. The speed, traceability, and
extensibility of the BIM Schema standardisation could be im-
proved with dynamic segmented modelling [31] and evolution-
ary ontology.
The BIM Schema standardisation could be significantly moti-
vated by and improved with:
 Clear evidence of competitive advantage and the coverage of
the BIM Schema compared to other exchange formats or APIs.
The analysis of coverage should assess the coverage of represen-
tational media and include a comparison of differences between
‘as-designed’, and ‘as-built’ models.
 Research on the expressiveness of modelling constructs with
BWW and evaluation of the importance of natural language
used in the modelling would be very valuable for future
schemata.
 Formal specification of the canonical form for BIM modelling,
mapping between internal and external schemata, and for dif-
ferent granularities of BIM Models that could significantly
improve the overall conceptual modelling and exchange of
models in heterogeneous environments.
241
The implementation and deployment could be significantly im-
proved with:
 Published implemented subschema and mapping between
internal and external BIM Schema;
 Published parts of internal BIM Schema that are not implement-
able with a given external schema;
 Published workflows, which include heterogeneous tools and
operate on the lossless level.
The adoption of BIM practices requires business process re-
engineering, which should be supported by a process-compe-
tency-driven approach. Motivation towards better productivity,
control, and quality should be observed from the personal, organ-
isational and technological standpoints. The transition should be
supported by appropriate organisational structures. End-users
could be motivated with features that reduce error levels and im-
prove presentation styles, interpretation, re-use, and repurposing
of models. Better understanding of communications and semiotics
could lead to better BIM technologies.
The developments should focus on support for all teamwork
stages. Collaborative environments for BIM should enable collabo-
rative modelling and the use of models to provide a complete an-
swer, not only to ‘‘Who did what and when?” but also to ‘‘Why
was it done?” (intent) and how the information was used. To make
more use of models, BIM Models should be first available, possibly
in BIM-aware digital repositories, with metadata from controlled
vocabularies, thus enabling better information retrieval and man-
agement supported by BIM Schemata (e.g., as an interface in crawl-
ing, indexing, and searching of BIM Models). Actualisation of BIM
Models and Schema should support plug-and-play interfaces
(e.g., for project process and product templates, for connectivity
between sensors in intelligent buildings) and allow for extended
use, for example, for schema-based compression, BIM competency
management and learning.
Acknowledgements
Part of the research, presented in this paper, was supported by
the Ministry of Science and Technology of the Republic of Slovenia
and by the Slovenian Research Agency (ARRS) funded research pro-
gramme E-Construction (P2-0210). Their support is gratefully
acknowledged. Special thanks to Bilal Succar for insightful com-
ments and suggestions on an earlier version of this paper. The
author is grateful to the reviewers for their useful comments,
which helped to improve the quality of the paper.
References
[1] A. Adriaanse, H. Voordijk, G. Dewulf, The use of interorganisational ICT in
United States construction projects, Automation in Construction 19 (1) (2010)
73–83.
[2] R. Aish, Collaborative design using long transactions and ‘‘change merge”, in:
D. Donath (Ed.), Promise and Reality: State of the Art versus State of Practice
in Computing for the Design and Planning Process – 18th eCAADe Conference
Proceedings, Weimar, Germany, 2000, pp. 107–111.
[3] H. Akkermans, J. Gordijn, What is this science called requirements
engineering? in: 14th IEEE International Requirements Engineering
Conference (RE’06), IEEE, Minneapolis, MN, USA, 2006, pp. 273-278.
[4] M. Alshawi, B. Ingirige, Web-enabled project management: an emerging
paradigm in construction, Automation in Construction 12 (4) (2003) 349–364.
[5] R. Amor, G. Augenbroe, J. Hosking, W. Rombouts, J. Grundy, Directions in
modelling environments, Automation in Construction 4 (3) (1995) 173–187.
[6] R. Amor, D. Bloomfield, T. Cerovšek, C. Finne, M. Groosman, G. Gudnasson, A.
Hutchison, J. Hyvärinen, G. Ólafsson, E. Oliveri, O. Rio, Ž. Turk, Information
Services to Enable European Construction Enterprises, Building Research
Establishment, Watford, UK, 2001.
[7] R. Amor, Y. Jiang, X. Chen, BIM in 2007 – are we there yet?, in: D. Rebolj (Ed.),
CIB W78, University of Maribor, Maribor, 2007, pp. 159–163.
[8] Y. Arayici, P. Coates, L. Koskela, M. Kagioglou, C. Usher, K. O’Reilly, BIM
implementation for an architectural practice, in: A. Dikbas, E. Ergen, H. Giritli
242 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
(Eds.), Managing It in Construction/Managing Construction for Tomorrow,
vol. 26, CRC Press, Taylor & Francis Group, Istanbul, Turkey, 2009, pp. 45–51.
[9] A. Ball, L. Ding, M. Patel, An approach to accessing product data across system
and software revisions, Advanced Engineering Informatics 22 (2) (2008) 222–
235.
[10] R. Barak, Y.S. Jeong, R. Sacks, C.M. Eastman, Unique requirements of building
information modeling for cast-in-place reinforced concrete, Journal of
Computing in Civil Engineering 23 (2) (2009) 64–74.
[11] V. Bazjanac, Implementation o semi-automated energy performance
simulation: building geometry, in: A. Dikbas, E. Ergen, H. Giritli (Eds.),
Managing It in Construction/Managing Construction for Tomorrow, vol. 26,
CRC Press, Taylor & Francis Group, Istanbul, Turkey, 2009, pp. 595–602.
[12] V. Bazjanac, A. Kiviniemi, Reduction, simplification, translation and
interpretation in the exchange of model data, in: D. Rebolj (Ed.), CIB W78,
University of Maribor, Maribor, 2007, pp. 163–171.
[13] J. Beetz, B. de Vries, J. van Leeuwen, RDF-based distributed functional part
specifications for the facilitation of service-based architectures, in: D. Rebolj
(Ed.), CIB W78, University of Maribor, Maribor, 2007.
[14] B.-C. Bjork, Requirements and information structures for building product
data models, VTT Building Technology, VTT, Espoo, Finland, 1995.
[15] B.-C. Bjork, H. Penttila, A scenario for the development and implementation of
a building product model standard (1978), Advances in Engineering Software
11 (4) (1989) 176–187.
[16] B.-C. Björk, M. Laakso, CAD standardisation in the construction industry – a
process view, Automation in Construction, in press.
[17] S. Boddy, Y. Rezgui, M. Wetherill, G. Cooper, Knowledge informed decision
making in the building lifecycle: an application to the design of a water
drainage system, Automation in Construction 16 (5) (2007) 596–606.
[18] J. Bogen, Theory and observation in science, in: E.N. Zalta (Ed.), The Stanford
Encyclopedia of Philosophy, Stanford University, Stanford, 2009.
[19] A. Borrmann, Y. Ji, I.C. Wu, M. Obergrießer, E. Rank, C. Klubert, W.A.
Guenthner, ForBAU – the virtual construction site project, in: A. Dikbas, E.
Ergen, H. Giritli (Eds.), Managing It in Construction/Managing Construction
for Tomorrow, vol. 26, CRC Press, Taylor & Francis Group, Istanbul, Turkey,
2009, pp. 528–534.
[20] A. Borrmann, E. Rank, Specification and implementation of directional
operators in a 3D spatial query language for building information models,
Advanced Engineering Informatics 23 (1) (2009) 32–44.
[21] F. Bosché, Automated recognition of 3D CAD model objects in laser scans and
calculation of as-built dimensions for dimensional compliance control in
construction, Advanced Engineering Informatics 24 (1) (2010) 107–118.
[22] T. Cerovsek, On AEC query formulation techniques, in: A.S.R. Zarli (Ed.),
ECPPM, Taylor & Francis Group, Sophia Antipolis, France, 2008, pp. 269–
278.
[23] T. Cerovsek, P. Katranuschkov, Active process reuse model for collaboration,
ITcon – Journal of Information Technology in Construction 11 (2006) 467–
488 (Special Issue: Process Modelling, Process Management and
Collaboration).
[24] T. Cerovsek, I. Kovacic, Z. Turk, Computer integrated construction at the
services level – first experiences, in: Z.S.R.J. Turk (Ed.), ECPPM, Balkema,
Portoroz, Slovenia, 2002, pp. 593–602.
[25] T. Cerovšek, Building information modelling and standardization:
development and use of ISO STEP, CIS2 and IFC, Gradbeni Vestnik (54)
(2005) 190–208.
[26] T. Cerovšek, T. Zupančič-Strojan, V. Kilar, Framework for model-based
competency management for design in physical and virtual worlds, ITcon –
Journal of Information Technology in Construction 15 (1) (2010) 1–22.
[27] H.-S. Chang, S.-C. Kang, P.-H. Chen, Systematic procedure of determining an
ideal color scheme on 4D models, Advanced Engineering Informatics 23 (4)
(2009) 463–473.
[28] X. Ci-Jun, Integration technology for complex product development process,
in: L. Ai-ping, L. Xue-mei (Eds.), International Conference on Measuring
Technology and Mechatronics Automation, vol. 3, IEEE Computer Society,
Zhangjiajie, Hunan, China, 2009, pp. 781–784.
[29] S. Dehlin, T. Olofsson, An evaluation model for ICT investments in
construction projects, Journal of Information Technology in Construction 13
(2008) 343–361.
[30] P. Demian, R. Fruchter, Methodology for usability evaluation of corporate
memory design reuse systems, Journal of Computing in Civil Engineering 20
(6) (2006) 377–389.
[31] S. Easterbrook, E. Yu, J. Aranda, Y. Fan, J. Horkoff, M. Leica, R.A. Qadir, Do
viewpoints lead to better conceptual models? An exploratory case study, in:
Proceedings of the 13th IEEE International Conference on Requirements
Engineering, IEEE Computer Society, 2005, pp. 199–208.
[32] C.M. Eastman, Building Product Models: Computer Environments, Supporting
Design and Construction, CRC, Boca Raton, Florida, USA, 1999.
[33] C.M. Eastman, Modeling of buildings: evolution and concepts, Automation in
Construction 1 (2) (1992) 99–109.
[34] C.M. Eastman, A.H. Bond, S.C. Chase, A formal approach for product model
information, Research in Engineering Design 2 (2) (1991) 65–80.
[35] C.M. Eastman, P. Teicholz, R. Sacks, K. Liston, BIM Handbook, first ed., Wiley,
Hoboken, NJ, USA, 2008.
[36] C.M. Eastman, F. Wang, S.J. You, D. Yang, Deployment of an AEC industry
sector product model, Computer-Aided Design 37 (12) (2005) 1214–1228.
[37] EC, Communication from the Commission to the Council, the European
Parliament and the European Economic and Social Committee – Towards an
Increased Contribution from Standardisation to Innovation in Europe,
European Commission, Brussels, Belgium, 2008, p. 19.
[38] EC, European Interoperability Framework 2.0, in: IDABC (Ed.), European
Interoperability Framework for Pan-European eGoverment Services,
European Commission, Brussels, Belgium, 2008, p. 85.
[39] S. El-Omari, O. Moselhi, Integrating 3D laser scanning and photogrammetry
for progress measurement of construction work, Automation in Construction
18 (1) (2008) 1–9.
[40] G. Fliedl, C. Kop, H.C. Mayr, From textual scenarios to a conceptual schema,
Data and Knowledge Engineering 55 (1) (2005) 20–37.
[41] M.P. Gallaher, A.C. O’Connor, J.L. Dettbarn Jr., L.T. Gilday, Cost Analysis of
Inadequate Interoperability in the U.S. Capital Facilities Industry, National
Institute of Standards and Technology, Gaithersburg, MD, USA, 2004. p. 194.
[42] W. Gielingh, A theory for the modelling of complex and dynamic systems,
ITcon 13 (27) (2008) 34.
[43] W. Gielingh, An assessment of the current state of product data technologies,
Computer-Aided Design 40 (7) (2008) 750–759.
[44] W. Gielingh, General AEC reference model (GARM) an aid for the integration
of application specific product definition models, in: P. Christiansson, H.
Karlsson (Eds.), Conceptual Modelling of Buildings, CIB W74+W78 Seminar,
CIB Proceedings 126, Lund University and the Swedish Building Centre, 1988,
pp. 165–178.
[45] B.L.M. Goldstein, S.J. Kemmerer, C.H. Parks, A Brief History of Early Product
Data Exchange Standard, NIST, 1998. p. 17.
[46] Graphisoft, IFC 2x3 Reference Guide for ArchiCAD 13, IFC Support, Budapest,
Hungary, 2009, p. 30.
[47] A. Grilo, R. Jardim-Goncalves, A. Steiger-Garcao, A methodology using domain
ontology and SOA for better interoperability in AEC mass customization, in:
D. Rebolj (Ed.), CIB W78, University of Maribor, Maribor, 2007, pp. 171–
177.
[48] H.U. Gökçe, D. Browne, K.U. Gökçe, K. Menzel, Dynamic system architecture
for energy efficient building operation, in: A. Dikbas, E. Ergen, H. Giritli (Eds.),
Managing It in Construction/Managing Construction for Tomorrow, vol. 26,
CRC Press, Taylor & Francis Group, Istanbul, Turkey, 2009, pp. 101–110.
[49] S.E. Haagenrud, L. Bjorkhaug, J. Wix, W. Trinius, EU-project STAND-INN-
integration of standards for sustainable construction into business process
using BIM/IFC, in: A.S.R. Zarli (Ed.), ECPPM, Taylor & Francis Group, Sophia
Antipolis, France, 2008, pp. 487–493.
[50] J.M. Haake, B. Wilson, Supporting collaborative writing of hyperdocuments in
SEPIA, in: Proceedings of the 1992 ACM Conference on Computer-Supported
Cooperative Work, ACM, Toronto, Ontario, Canada, 1992, pp. 138–146.
[51] M. Hakkarainen, C. Woodward, K. Rainio, Software architecture for mobile
mixed reality and 4D BIM interaction, in: A. Dikbas, E. Ergen, H. Giritli (Eds.),
Managing It in Construction/Managing Construction for Tomorrow, vol. 26,
CRC Press, Taylor & Francis Group, Istanbul, Turkey, 2009, pp. 45–51.
[52] R. Harrison, S.J. Counsell, R.V. Nithi, An evaluation of the MOOD set of object-
oriented software metrics, IEEE Transactions on Software Engineering 24 (6)
(1998) 491–496.
[53] T. Hartmann, M. Fischer, J. Haymaker, Implementing information systems
with project teams using ethnographic-action research, Advanced
Engineering Informatics 23 (1) (2009) 57–67.
[54] U. Hartmann, P. von Both, A declarative approach to cross-domain model
analysis, in: A. Dikbas, E. Ergen, H. Giritli (Eds.), Managing It in Construction/
Managing Construction for Tomorrow, vol. 26, CRC Press, Taylor & Francis
Group, Istanbul, Turkey, 2009, pp. 45–51.
[55] F. Heylighen, Basic concepts of the systems approach, in: C.J.a.V.T.F.
Heylighen (Ed.), Principia Cybernetica Web, Principia Cybernetica, Brussels,
1998.
[56] J. Hietanen, IFC Model View Definition Format, IAI, Helsinki, 2006. p. 25.
[57] R. Howard, B.-C. Björk, Building information modelling – experts’ views on
standardisation and industry deployment, Advanced Engineering Informatics
22 (2) (2008) 271–280.
[58] IEEE-SA, IEEE Standards Development Online Home, IEEE Standards
Association, <http://www.ieee.org/publications_standards>, 2009.
[59] ISO, ISO 10303-11:1994, Industrial Automation Systems and Integration –
Product Data Representation and Exchange – Part 11: Description Methods:
The EXPRESS Language Reference Manual, ISO, Geneva, Switzerland, 1994, p.
208.
[60] ISO, ISO 10303-21:2002, Industrial Automation Systems and Integration –
Product Data Representation and Exchange – Part 21: Implementation
Methods: Clear Text Encoding of the Exchange Structure, ISO, Geneva,
Switzerland, 2002, p. 72.
[61] ISO, ISO 24517-1:2008, Document Management – Engineering Document
Format Using PDF – Part 1: Use of PDF 1.6 (PDF/E-1), ISO, Geneva,
Switzerland, 2008, p. 26.
[62] ISO, ISO – Standards Development, International Standardization
Organization, Switzerland, Geneva, <http://www.iso.org/iso/standards_
development.htm>, 2009.
[63] M.C. Jackson, Systems Thinking: Creative Holism for Managers, Wiley,
Chichester (etc.), 2003.
[64] Y.E. Kalay, Architecture’s New Media: Principles, Theories, and Methods of
Computer-Aided Design, The MIT Press, Boston, MA, USA, 2004.
[65] Y.E. Kalay, The impact of information technology on design methods,
products and practices, Design Studies 27 (3) (2006) 357–380.
[66] D.J. Kasik, W. Buxton, D.R. Ferguson, Ten CAD Challenges, IEEE Computer
Graphics and Applications, vol. 25, IEEE Computer Society, 2005, pp. 81–91.
 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244
[67] H.M. Khoury, V.R. Kamat, High-precision identification of contextual
information in location-aware engineering applications, Advanced
Engineering Informatics 23 (4) (2009) 483–496.
[68] A. Kiviniemi, IFC certification process and data exchange process, in: A. Zarli,
R. Scherer (Eds.), ECCPM 2008, Taylor & Francis Group, Sophia Antipolis,
France, 2008, p. 8.
[69] A. Kiviniemi, M. Fischer, V. Bazjanac, Multi-model environment: links
between objects in different building models, in: R.J. Scherer, P.
Katranuschkov, S.-E. Schapke (Eds.), CIB W78’s 22nd International
Conference on Information Technology in Construction, TU Dresden,
Dresden, Germany, 2005, pp. 277–284.
[70] A. Kiviniemi, V. Tarandi, J. Karlshöj, Bell, Håvard, O.J. Karud, Review of the
Development and Implementation of IFC Compatible BIM, Erabuild, 2007. p.
128.
[71] D. Kyoung, Y. Leee, K. Jung, Immersive Viewer System for 3D User Interface,
Human–Computer Interaction. Interaction Platforms and Techniques, 2007,
pp. 624–633.
[72] G. Lee, C.M. Eastman, R. Sacks, S.B. Navathe, Grammatical rules for specifying
information for automated product data modeling, Advanced Engineering
Informatics 20 (2) (2006) 155–170.
[73] G. Lee, R. Sacks, C.M. Eastman, Product data modeling using GTPPM – a case
study, Automation in Construction 16 (3) (2007) 392–407.
[74] T. Liebich, Model Implementation Guide, Building SMART International, 2009,
p. 178.
[75] R. Lipman, Details of the mappings between the CIS/2 and IFC product data
models for structural steel, ITcon – Journal of Information Technology in
Construction 14 (1) (2009) 1–13.
[76] K. Liston, M. Fischer, T. Winograd, Focused sharing of information for
multidisciplinary decision making by project teams, ITcon – Journal of
Information Technology in Construction 6 (1) (2001) 69–82.
[77] O. Lopez-Ortega, M. Ramírez-Hernández, A formal framework to integrate
express data models in an extended enterprise context, Journal of Intelligent
Manufacturing 18 (3) (2007) 371–381.
[78] J. Lucas, W. Thabet, D. Bowman, Analyzing capacity of BIM tools to support
data use across project lifecycle, in: A. Dikbas, E. Ergen, H. Giritli (Eds.),
Managing It in Construction/Managing Construction for Tomorrow, vol. 26,
CRC Press, Taylor & Francis Group, Istanbul, Turkey, 2009, pp. 11–18.
[79] F. Maier, M. Stumptner, Enhancements and Ontological Use of ISO-10303
(STEP) to Support the Exchange of Parameterised Product Data Models,
Intelligent Systems Design and Applications, ISDA 2007, Seventh
International Conference on, 2007, pp. 433–440.
[80] M.W. Maier, Research Challenges for Systems-of-Systems, Systems, Man and
Cybernetics, 2005 IEEE International Conference on, vol. 4, 2005, pp. 3149–
3154.
[81] R.J. Mayer, M.K. Painter, P.S. deWitte, IDEF family of Methods for Concurrent
Engineering and Business Re-engineering Applications, vol. 2008, Knowledge
based systems, College Station, TX, USA, 1992.
[82] Merriam-Webster, Merriam-Webster Dictionary, Merriam-Webster Online
Dictionary copyrightÓ 2009 by Merriam-Webster, Incorporated, Merriam-
Webster, Incorporated, Springfield, 2009.
[83] S. Mihindu, Y. Arayici, Digital construction through BIM systems will drive the
re-engineering of construction business practices, in: 12th international
conference of Information Visualisation, IEEE Computer Society, London, UK,
2008, pp. 29-36.
[84] A. Moum, C. Koch, T.I. Haugen, What did you learn from practice today?
exploring experiences from a Danish R&D effort in digital construction,
Advanced Engineering Informatics 23 (3) (2009) 229–242.
[85] MSG, Technical specifications, in: T. Liebich (Ed.), IAI Technical Specifications,
vol. 2010, International Alliance for Interoperability, International Council
(IAI), Munich, Germany, 2007.
[86] Nemetschek, Nemetschek IFC 2x3 Guideline, IFC support, Munich, Germany,
2007, p. 36.
[87] C.M. Neuwirth, R. Chandh, D. Charney, P. Wojahn, L. Kim, Distributed
collaborative writing: a comparison of spoken and written modalities for
reviewing and revising documents, in: Conference Companion on Human
Factors in Computing Systems, ACM, Boston, Massachusetts, United States,
1994.
[88] NIBS, National BIM Standard, Part 1: Overview, Principles, and
Methodologies, National Institute for Building Sciences (NIBS), Washington,
DC, USA, 2007, p. 182.
[89] J. Nytun, A. Prinz, M. Tveit, Automatic Generation of Modelling Tools, Model
Driven Architecture – Foundations and Applications, Springer Berlin/
Heidelberg, Bilbao, Spain, 2006. pp. 268–283.
[90] T. Olofsson, G. Lee, C. Eastmann, Editorial – case studies of BIM in use, Journal
of Information Technology in Construction 13 (2008) 244–245 (Case studies
of BIM US).
[91] OMG, MDA Guide Version 1.0.1, in: J. Miller, J. Mukerji (Eds.), Model Driven
Architecture, Object Management Group, Needham, MA, USA, 2003, p. 62.
[92] Onuma, Kimon, Onuma, vol. 2009, ONUMA, Inc., Pasadena, 2009.
[93] S. Pu, G. Vosselman, Knowledge based reconstruction of building models from
terrestrial laser scanning data, ISPRS Journal of Photogrammetry and Remote
Sensing 64 (6) (2009) 575–584.
[94] T. Racz, T. Olofsson, Interoperability challenges of an engineering software
provider, in: A. Dikbas, E. Ergen, H. Giritli (Eds.), Managing It in Construction/
Managing Construction for Tomorrow, vol. 26, CRC Press, Taylor & Francis
Group, Istanbul, Turkey, 2009, pp. 75–83.
243
[95] D. Rebolj, N.C. Babic, A. Magdic, P. Podbreznik, M. Psunder, Automated
construction activity monitoring system, Advanced Engineering Informatics
22 (4) (2008) 493–503.
[96] V. Red’ko, I. Red’ko, Descriptological foundations of information technologies,
Cybernetics and Systems Analysis 43 (5) (2007) 629–640.
[97] K. Reiner, R. Fruchter, Project Memory Capture in Globally Distributed Facility
Design, vol. 279, ASCE, Stanford, California, USA, 2000, pp. 107–107.
[98] Y. Rezgui, C.J. Hopfe, C. Vorakulpipat, Generations of knowledge
management in the architecture, engineering and construction industry: an
evolutionary perspective, Advanced Engineering Informatics 24 (2) (2010)
219–228.
[99] M. Roseman, S. Greenberg, Team rooms: network places for collaboration, in:
Proceedings of the 1996 ACM Conference on Computer Supported
Cooperative Work, ACM, Boston, Massachusetts, United States, 1996, pp.
325–333.
[100] M. Rosemann, P. Green, Developing a meta model for the Bunge–Wand–
Weber ontological constructs, Information Systems 27 (2) (2002) 75–91.
[101] B. Rubenstein-Montano, J. Liebowitz, J. Buchwalter, D. McCaw, B. Newman, K.
Rebeck, A systems thinking framework for knowledge management, Decision
Support Systems 31 (1) (2001) 5–16.
[102] O. Samuelson, The IT-barometer – a decade’s development of IT use in the
Swedish construction sector, ITcon – Journal of Information Technology in
Construction 13 (1) (2008) 1–19.
[103] C.E. Shannon, A mathematical theory of communication, Bell System
Technical Journal 27 (1948) 379–423.
[104] J. Song, C.T. Haas, C.H. Caldas, A proximity-based method for locating RFID
tagged objects, Advanced Engineering Informatics 21 (4) (2007) 367–376.
[105] SoSECE, The system of systems engineering center of excellence (SoSECE),
vol. 2008, Office of the Under Secretary of Defense for Acquisition,
Technology, & Logistics, Defense Systems, Systems and Mission Integration,
Joint Force Integration (USD-AT&L), Johnstown, USA, 2008.
[106] A. Streilein, Towards automation in architectural photogrammetry: CAD-
based 3D-feature extraction, ISPRS Journal of Photogrammetry and Remote
Sensing 49 (5) (1994) 4–15.
[107] B. Strug, G. Slusarczyk, Reasoning about designs through frequent patterns
mining, Advanced Engineering Informatics 23 (4) (2009) 361–369.
[108] B. Succar, Building information modelling framework: a research and
delivery foundation for industry stakeholders, Automation in Construction
18 (3) (2009) 357–375.
[109] P.I.R. Suermann, Evaluating industry perceptions of building information
modelling (BIM) impact on construction, International Journal of IT in
Construction 14 (2009) 574–594.
[110] I.E. Sutherland, SKETCHPAD: A Man-machine Graphical Communication
System, Lincoln Laboratory, Massachusetts Institute of Technology, 1963.
[111] B. Systems, IFC White Paper, Bentley Systems, Incorporated, Exton, PA, United
States, 2009.
[112] D. Tang, R. Zhu, J. Tang, R. Xu, R. He, Product design knowledge management
based on design structure matrix, Advanced Engineering Informatics 24 (2)
(2010) 159–166.
[113] F.P. Tolman, Product modeling standards for the building and construction
industry: past, present and future, Automation in Construction 8 (3) (1999)
227–235.
[114] B.W. Tuckman, Developmental sequence in small groups, Psychological
Bulletin 63 (6) (1965) 384–399.
[115] Z. Turk, T. Cerovsek, CONNET Software Center: A Section of the Construction
Technology Park, vol. 279, ASCE, Stanford, California, USA, 2000, pp. 42–42.
[116] UNIDO, Role of Standards – A Guide for Small to Medium-sized Enterprises,
United Nations Industrial Development Organization, Vienna, Austria, 2006,
p. 56.
[117] W.M.P. van der Aalst, M. Song, Mining social networks: uncovering
interaction patterns in business processes, in: J. Desel, B. Pernici, M. Weske
(Eds.), Business Process Management, Second International Conference, BPM
2004, Springer Berlin/Heidelberg, Potsdam, Germany, 2004, pp. 244–260.
[118] M. Velmans, Intersubjective science, Journal of Consciousness Studies 6
(1999) 299–306.
[119] H. Verheij, G. Augenbroe, Collaborative planning of AEC projects and
partnerships, Automation in Construction 15 (4) (2006) 428–437.
[120] W3C, Efficient XML Interchange Evaluation, in: C. Bournez (Ed.), Efficient
XML Interchange Working Group, W3C, 2008.
[121] H. Wang, T. Payne, N. Gibbins, A. Saleh, Formal Specification of OWL-S with
Object-Z: The Dynamic Aspect, Web Information Systems Engineering –
WISE 2007, 2007, pp. 237–248.
[122] G.M. Weinberg, An Introduction to General Systems Thinking, 2001 ed.,
Dorset House, New York, NY, USA, 1975.
[123] M. Weise, T. Liebich, J. Tulke, P. Bonsma, IFC support for model-based
scheduling, in: A. Dikbas, E. Ergen, H. Giritli (Eds.), Managing It in
Construction/Managing Construction for Tomorrow, vol. 26, CRC Press,
Taylor & Francis Group, Istanbul, Turkey, 2009, pp. 75–83.
[124] O. Wikforss, A. Lofgren, Rethinking communication in construction, ITcon –
Journal of Information Technology in Construction 12 (23) (2007) 337–346.
Glossary
AAM: Application Activity Model
ABM: Active BIM Models
244 T. Cerovsek / Advanced Engineering Informatics 25 (2011) 224–244

AIM: Application Interpreted Model MVD: Model View Definitions

APM: Active Process/Product Model OO: Object Oriented
ARM: Application Reference Model OCL: Object Constrain Language
BPML: Business Process Modelling Language OWL: Web Ontology Language
BWW: Bunge–Wand–Weber PAC: Presentation–Abstraction-Control
CASE: Computer Aided Software Engineering SaaS: Software as a Service
CRUD: Create Read Update Delete SBA: Space-Based Architecture
CVS: Concurrent Versioning System SCI: Steel Construction Institute
DEP: Design Exchange Protocols SOA: Space Oriented Architecture
EEML: Extended Environments Markup Language SoS: Systems-Of-Systems
FEM: Final Element Analyses Method SPF: Step Physical File
IAI: International Alliance for Inter-operability
ICOM: Input, Control, Output, Mechanism Tomo Cerovsek, has a Ph.D. in Engineering from University of Ljubljana, Slovenia.
IDEF: Integration DEFinition He lectures in engineering communication, descriptive geometry, process model-
IDM: Information Delivery Manual ling, CAD, and BIM. His professional research interests include engineering com-
IFC: Industry Foundation Classes munication, multi-media systems, information systems, BIM, collaboration,
IFD: International Framework for Dictionaries integrated practices, systems-thinking theory, information seeking behaviour, and
IPR: Intellectual Property Rights engineering information retrieval. In the last 10 years he participated in several EU
MOOD: Metrics for Object Oriented Design projects as lead researcher and technical coordinator. He developed multi-media
MSG: Model Support Group systems for learning, collaboration, and engineering IR systems. He is a member of
MVC: Model-View-Control IEEE, CIB and technical committee for standardisation.