Automatic Rule-Based Checking of Building Designs

Automation in Construction 18 (2009) 10111033
Contents lists available at ScienceDirect
Automation in Construction
j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / a u t c o n
Review
Automatic rule-based checking of building designs

C. Eastman , Jae-min Lee, Yeon-suk Jeong, Jin-kook Lee
College of Architecture, Georgia Institute of Technology, United States
a r t i c l e
i n f o
Article history:
Accepted 30 July 2009
Keywords:
BIM
Design assessment
Building codes
Design guides
a b s t r a c t
This paper surveys rule checking systems that assess building designs according to various criteria. We
examine ve major industrial efforts in detail, all relying on IFC building models as input. The functional
capabilities of a rule checking system are organized into four stages; these functional criteria provide a
framework for comparisons of the ve systems. The review assesses both the technology and structure of
building design rule checking, as an assessment of this new emerging eld. The development of rule
checking systems for building is very young and only limited user experience is presented. The survey lays
out a framework for considering research needed for this area to mature.
2009 Elsevier B.V. All rights reserved.
Contents
1.
2.
3.
4.
5.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .
History of rule checking research . . . . . . . . . . . . . . . .
The rule checking process . . . . . . . . . . . . . . . . . . .
3.1.
Rule interpretation . . . . . . . . . . . . . . . . . . .
3.1.1.
Logic-based interpretation . . . . . . . . . . .
3.1.2.
Ontology of names and properties . . . . . . . .
3.1.3.
Implementation method . . . . . . . . . . . .
3.1.4.
Language driven . . . . . . . . . . . . . . . .
3.2.
Building model preparation . . . . . . . . . . . . . . .
3.2.1.
Model views . . . . . . . . . . . . . . . . . .
3.2.2.
Derive implicit properties using enhanced objects
3.2.3.
Derive new models . . . . . . . . . . . . . . .
3.2.4.
Performance-based model and integrated analysis
3.2.5.
Visibility of layout rule parameters . . . . . . .
3.3.
Rule execution . . . . . . . . . . . . . . . . . . . . .
3.3.1.
Model view syntactic pre-checking . . . . . . .
3.3.2.
Management of view submissions . . . . . . . .
3.4.
Rule check reporting . . . . . . . . . . . . . . . . . .
3.4.1.
Rule instance graphical reporting . . . . . . . .
3.4.2.
Reference to source rule . . . . . . . . . . . .
3.5.
Summary . . . . . . . . . . . . . . . . . . . . . . . .
Rule-based platforms . . . . . . . . . . . . . . . . . . . . .
Survey of rule-based building model checkers . . . . . . . . . .
5.1.
CORENET-Singapore . . . . . . . . . . . . . . . . . . .
5.1.1.
Rule interpretation . . . . . . . . . . . . . . .
5.1.2.
Building model preparation . . . . . . . . . . .
5.1.3.
Rule execution . . . . . . . . . . . . . . . . .
5.1.4.
Rule reporting . . . . . . . . . . . . . . . . .
5.1.5.
CORENET summary . . . . . . . . . . . . . . .
Corresponding author.
E-mail address: chuck.eastman@arch.gatech.edu (C. Eastman).
0926-5805/$ see front matter 2009 Elsevier B.V. All rights reserved.
doi:10.1016/j.autcon.2009.07.002
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1012
1013
1013
1013
1013
1014
1014
1014
1014
1014
1014
1015
1015
1015
1015
1015
1015
1015
1015
1015
1016
1016
1017
1017
1017
1017
1017
1017
1017
1012
C. Eastman et al. / Automation in Construction 18 (2009) 10111033
5.2.
Norwegian Statsbygg's design rule checking efforts . . . . . . . . . . . . . . .

5.2.1.
Spatial requirement checking . . . . . . . . . . . . . . . . . . . . .
5.2.2.
Rule checking for accessible design . . . . . . . . . . . . . . . . . .
5.2.3.
Building model preparation . . . . . . . . . . . . . . . . . . . . . .
5.2.4.
Rule execution . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5.
Rule reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.6.
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.
Design check by cooperative research centre for construction innovation in the Australia
5.3.1.
Rule interpretation . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2.
5.3.3.
Rule execution . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4.
Rule reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5.
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.
International Code Council (ICC) . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1.
Rule interpretation . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.2.
Rule reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.3.
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.
General services administration design rule checking . . . . . . . . . . . . . .
5.5.1.
Spatial program validation . . . . . . . . . . . . . . . . . . . . . . .
5.5.2.
Design guide checking . . . . . . . . . . . . . . . . . . . . . . . .
5.5.3.
Rule preparation . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.4.
5.5.5.
Rule execution . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.6.
Rule reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.7.
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.
User experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.
Major issues in building rule checking systems . . . . . . . . . . . . . . . . . . . .
7.1.
Verication of code checking . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.
Rule checking system as a design development supporting system . . . . . . . .
7.3.
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1. Introduction
New criteria continuously emerge in architecture, ranging from
building codes and safety, to the techniques of fabrication and
assembly. Until recently, the only means to deal with this complex
and growing body of knowledge were human cognition and
organizational review processes. Some criteria involve computerized analyses (e.g. structures), but still, the details of safety factors
and interpretation of the results have been a manual, peoplecentered undertaking. The advent of computer applications supporting the 3D object modeling of buildings, called Building
Information Modeling (BIM), allow both automatic parametric
generation of designs that respond to various criteria and the
prospect of computer-interpretable models and automated checking
of designs after they are generated [1].
Automated rule checking here is dened as software that does not
modify a building design, but rather assesses a design on the basis of the
conguration of objects, their relations or attributes. Rule-based systems
apply rules, constraints or conditions to a proposed design, with results
such as pass, fail or warning, or unknown for cases where the
needed data is incomplete or missing.
While some rules can be embedded in parametric design generating systems, automated rule checking of candidate designs are
appropriate where the rules:
1. Apply across different building and spatial systems, because the
objects and rules of generation cannot be dened beforehand.
Spatial congurations are an example.
2. Are those of public agencies, organizations or clients that need to
review designs that are generated by an open-ended set of design
tools.
3. Where the conditions being assessed are global ones, such as rules
associated with safety, structural integrity, energy usage and costs.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1018
1019
1020
1021
1021
1022
1023
1023
1023
1023
1024
1024
1024
1024
1025
1026
1026
1027
1027
1027
1027
1028
1028
1030
1030
1031
1031
1032
1032
1032
1032
1032
Almost all efforts in automating rule checking to date have been

applied to building code and accessibility criteria. These types of rule
checking are required of all buildings constructed within a
jurisdiction. Since code plan checking is often a costly bottleneck
in the building delivery process, automated code reviews have the
potential to save signicant time and cost. In this review, we
approach rule checking systems from a perspective of broader
potential applicability. We expect rule-based systems to become a
class of application that will have wide deployment in the AEC
industries:
1. For all buildingsgeneral conditions such as building codes, at the
national, regional or municipality level of organization.
2. For particular building typesdesign guides of best practices for a
building type; this type of rule-base may be dened by the client
organization, or alternatively, as best practices within a design or
engineering rm.
3. For a specic building project: programmatic requirements for a
building instance, such as its space requirements, circulation issues,
ergonomic layout and special site considerations; these may be
developed by the client or design rm, and the specic rules dened
as part of the program and review criteria during project design and
construction.
We expect to see application of rule checking systems to move
beyond code checking to the other two levels of specicity and eventually to become a standard tool used throughout the building lifecycle.
A rule-based assessment tool can be implemented for various
platforms, for example: (1) as an application closely tied to a design
tool, such as a plug-in, allowing checking whenever the designer
wishes. (2) or as a stand-alone application running on desktops, in
parallel to a design generating tool; (3) as a web-based application
that can accept design from a variety of sources. Each approach is
desirable for some uses. Current efforts have focused on the web-
based approach but we look forward to the development of simple-todevelop rule-based systems that encourage implementation of the
other types.
The only neutral model representation for describing a building for
rule checking is Industry Foundation Classes (IFC) [2]. This is a design
tool independent and neutral data model representation supported by
most BIM design tools, and is being used as the building model
representation in all the efforts reviewed here. Rule checking using
native application data models will probably also emerge.
There has been a long historical interest in structuring building
codes into a form amenable for machine interpretation and application. Efforts to implement production rule-based systems came later,
as supporting hardware and web-access matured. The initial effort was
led by Singapore, who started considering code checking on 2D
drawings in 1995. It then switched and started the CORENET System
working with IFC building models in 1998 [3]. More recent efforts have
been initiated in Norway [4] and Australia [5]. A U.S. effort also has
been initiated called SmartCODES [6]. There are also several research
implementations of rules to assess accessibility for special populations
[7] and for re codes [8]. The GSA and US Courts has recently supported
development of design rules checking of federal courthouses, which
is an early example of rule checking applied for automating design
guides [9].
This paper reviews these ve efforts to automate rule checking in
buildings, focusing primarily on building code reviews. These are
CORENET, the HITOS project by Norwegian Statsbygg, the effort by the
Australian Building Codes Board, the International Code Council in the
US. We also review the General Services Administration effort
involving building type design rule checking, which has supported
the efforts of the authors.
Many other systems applications have limited purpose targeted
rule checking capabilities: such as for checking room areas or for
spatial conict checking. We exclude these, focusing on systems with
potentially general rule checking capabilities.
We start by reviewing early research in the area, then outline a
general functional architecture of services that all rule checking
systems need to provide. Using this structure, we then review the
main institutional efforts being carried out in several parts of the
world. Last, we summarize the current status of efforts and identify
areas where additional research is needed.
2. History of rule checking research
Rules and regulations are written by people and for a long time, were
only read and applied by people. As a result, they were sometimes
incomplete (particular conditions were not covered) or contradictory.
Their structure was often arbitrarily complex. Improving the logical
structure of regulatory codes was an area of early research. Fenves
undertook initial work to structure regulatory codes in decision
tables [10]. Later, decision trees were applied to structural steel design
[11]. Software tools were developed to support the management of
regulations [12] in different jurisdictions. Fenves' students followed by
structuring regulations in a predicate logic structure [13,14]. Other
software was developed, called the SASE system (Standards Analysis,
Synthesis and Expression) [15], to provide a comprehensive structure
for families of related codes (as exists across the many US jurisdictions).
An important review and critique of these early efforts is provided in
[16]. Given the predicate logic structure, Kerrigan developed the
REGNET application to determine for given building conditions the
applicability for various codes, based on a question-and-answer user
interface [17]. These early efforts laid out the logical structure of codes,
from a rule-based and organizational perspective. They did not address
in a signicant way automated application of rules to a digital building
representation.
In parallel, various efforts were undertaken to apply rule checking
to building representations, using specially coded drawing structures
1013
or textual descriptions. These were applied to re escape and evacuation [18], other forms of prescriptive requirements and performance-based standards [19]. Development of rule-based systems for
building models began exploration in the late 1980s [20]. In the 1990s,
the development of the Industry Foundation Classes led to early
research for using this building model schema for building code
checking. Han and others laid out general opportunities and a client
server approach [21,22]. Han identied the need for multiple object
views for different types of rule checking [23]. They later developed a
simulation approach of ADA wheelchair accessibility checking [24,25].
These efforts set the stage for larger, more industrial-based efforts.
3. The rule checking process
From the early efforts and our review of current work, we have
extracted a necessary structure for implementing a functionally complete
rule checking and reporting system. Rule checking can be broadly
structured into four stages: (1) rule interpretation and logical structuring
of rules for their application; (2) building model preparation, where the
necessary information required for checking is prepared; (3) the rule
execution phase, which carries out the checking, and (4) the reporting of
the checking results. Within each of these phases, we identify a set of more
detailed functional issues.
Within the rst three phases, shared conventions must exist
regarding the coded rules so they match with the properties and structures that are embedded in the building model. Information availability
for rule checking can be addressed in some mixture of three strategies:
1. Requiring the designer to explicitly provide information in the
building model needed for checking. While this is natural for some
aspects (door and window locations and sizes), others are derived
from more basic information and rely on fallible human judgment
that are current causes of error (minimum headroom in stairway,
wheelchair navigation in a restroom).
2. Having the computer derive new data or generate model views
that explicitly derive the lacking data. Examples where computer
processing can extract implicit attributes include the examples of
headroom and wheelchair access in #1 above and re exit paths
and their lengths.
3. Some important design rules apply to properties that require
complex simulations or analyses, such as for structural integrity or
energy usage. These require the application of an analysis model to
derive the complex information, then to apply the rules to the
analytically derived data.
As can be seen, rule checking implementation approaches involve
many trade-offs between imposing documentation work on the
designer and imposing stronger inference capabilities within the rule
checking software. These issues arise continuously throughout the
design and implementation of rule checking systems.
3.1. Rule interpretation
Rules for building design are rst dened by people and represented
in human language formats, typically written text, tables and possibly
equations. In building codes, these rules have legal status. How can the
interpretation of these rules into a machine processable format be done,
in a manner that the implementation can be validated as consistent with
the written rule? In some rule checking implementations, the process
relies on the programmer's interpretation and translation of the written
rules into computer code. In other cases, the logic of the human language
statements is formally interpreted and then translated.
3.1.1. Logic-based interpretation
A common intermediate language for mapping rules from natural
language to processable form is rst order predicate logic. Predicate
logic is both formal and has been used for decades as a means to
1014
formalize rules dened by people [26]. In logic, a predicate is a welldened term (or function) that can be evaluated to TRUE or FALSE
(or undened, if terms are not dened). Predicate logic also deals
with quantication, whether a statement applies either to ALL instances where a condition arises, or that it applies at least to one of the
instancesthat the condition EXISTS. There are well developed general
techniques for translating logical assertions into executable statements,
most importantly the Prolog computer language [27]. The domain of
buildings and the interpretation of where rules apply and how many
instances of the rule need to be applied are major issues. In this domain,
rules are typically deeply nested, based on many contextual conditions,
for example based on type of construction, earthquake zone, and
construction details. Other rules are general and apply to all conditions
of an occurrence, which can occur in the thousands.
and electrical load requirements. Like all computer languages, the

backend implementation could be re-targeted to operate on different
building model representations, such as the native building models of
the different BIM tools, and thus not limited to IFC building models. In
a language, the rules written would be portable, in the same way that
java, C or SQL programs are portable to different platform environments. This allows running the same rules on a code checking server
and also embedded in a design tool. The other benet of a language is
that, if well-designed, it is able to depict an unlimited range of rules,
including unlimited nested conditions and branching of alternative
contexts within a specied domain. While examples exist for the rst
two types of rule representation, no language for building model rule
checking is known to have been proposed.
3.2. Building model preparation
3.1.2. Ontology of names and properties

Rule translation typically has two aspects: (1) the condition or
context where the rule applies, (2) the properties upon which the rule
applies. The rst step might identify potential re exit paths, for
example, and the second step would then check the width and length
of the identied paths. These steps rely on explicit space classications (circulation space), and dened methods for measuring length
and width. These classications and properties are now being rened
from earlier classications and expanded. Omniclass [28] is a North
American effort integrated with ISO and European efforts to develop
building classications in support of digital modeling and exchange. It
is providing the space, process, actors, building objects and other
general classes of information. Omniclass works in parallel with but is
distinct from the International Framework for Dictionaries (IFD) [29]
which provides explicit denitions of building components, their
properties for different uses, and in different languages. The rules that
carry out the object, attributes or relation assessment are the critical
processing end of rule interpretation and rely heavily on standards
from Omniclass and IFD.
3.1.3. Implementation method
The contextual conditions and tests can be implemented in
different ways:
1. Computer language encoded rules: The most straightforward
implementation structure for rules is computer code, using parameterization and branching. Rules encoded in computer language
require high-level of expertise to dene, write and maintain. While
rules written in computer code may be used in dedicated applications, they are not likely to support widespread use.
2. Parametric tables: Parameters and, branches and other logical
constructs can be written to dene a class of rules, instantiated by a
table of parameters. Dening the parameters provides an easy but
limited method for dening new rules. Quantication has been
included (ALL or EXISTS) in some parametric tables. Tables
facilitate easy denition of rules for different contexts by users
without the need for computer programming. They are limited by
the range of conditions they can represent. Parametric tables are an
intermediate step between ease of use and the generality and
power to dene and implement any relevant rule.
3.1.4. Language driven
A longer term implementation method of building rule checking is
their implementation in one or more rule denition languages. Two
different styles of language can be envisioned: (1) predicate logicbased, facilitating the conversion of human language rules into logical
propositions that can be executed, (2) domain-oriented, where the
terms in the language allow easy denition of context for rule
application and the conditions they test. It seems likely that a family of
related languages will be required for different domains within building, such as for structural analysis, room properties and accessibility,
In traditional computer drafting practice, the objective was is to lay

out 2D drawing representations that people could interpret for
building information. The primary requirement in this earlier process
was that the drawings must look visually correct and to contain the
varied information needed for rule checking. Today, with object-based
building models, the requirements have changed. Objects being
checked now have a type and properties. For example, an object that
looks like a set of appropriately spaced stair treads but dened as
small slabs will not be interpreted as a stair, unless it is converted to a
stair object, with stair properties such as riser, tread, run, etc. Thus the
requirements of a building model adequate for rule checking are
stricter than earlier drafting requirements. Architects and others
dening building models that will be used for rule checking must
prepare them so that the models provide the information needed in
well-dened agreed upon structures. The GSA BIM Guides [30]
provide initial examples of modeling requirements for simple rule
checking. This information must then be properly encoded in IFC by
the software developers to allow proper translation and testing.
If users are asked to explicitly enter complex derived properties,
for example volume of a space, the issue of erroneous data that is not
consistent with the building model arises. The preferred solution is to
automatically derive required rule checking data wherever possible,
either within the design program or the rule checking one.
3.2.1. Model views
Building models involve large datasets, even for only mediumscale buildings. And the models built to date do not typically include
the level of detail needed for building code or other types of rule
checking. Han et al. proposed [23] that separate model views be used
to both derive the needed data required for a specic type of rule
checking and to extract subsets of an overall building model to allow
more efcient processing. All efforts to date have followed this
approach, if only to partition the development effort. Denition of
such model views goes hand-in-hand with the preparation of rule
checking functions. Some rule checking involves implicit properties
such as the ratio of glazing to oor area in rooms, the narrowest width
in a passageway and accessibility for the handicapped in restrooms.
Rule checking can be built upon different types of model views in
response to these issues. Initial development of a model view for code
checking some sections of codes has been developed by the
contractors working with the International Code Council [31].
3.2.2. Derive implicit properties using enhanced objects
In response to these issues, some rule checking efforts have developed enhanced building objects implemented using object-oriented
programming principles. The expanded objects include methods
to derive new information and compute complex properties [32].
This approach works well for most cases. It may not be sufcient
for properties that are part of complex spatial congurations made
up of multiple nested and bounding objects, such as properties of
circulation space or use space. Some of these limitations would

disappear if fully and accurately dened space objects in buildings
could be derived, allowing a rich set of assessments of spaces to be
undertaken.
3.2.3. Derive new models
Other efforts automatically derive a new building model to facilitate
assessment of certain implicit properties or relations. An example
is the derivation of a graph of circulation paths from a building's
spatial layout to check accessibility for the handicapped and for
re exits [33]. The derived model can carry attributes designating
walking distances between spaces and other spatial properties
needed for circulation assessment. The derived views and attributes
allow checking of properties that would be very complex on a standard building model.
3.2.4. Performance-based model and integrated analysis
Some of the properties of a design being checked are performancebased, requiring analysis or simulations for their derivation. Structural
analyses are required for many buildings and energy analysis is
becoming more common. Performance-based rules generally require
a specially derived model view, with its own geometry, material or
other parameters properties and assumed loads, as input for executing the analysis/simulation. The analysis results are combined with
the modeling assumptions to determine the adequacy of the rules. We
are not aware of any system today that integrates these different steps
into an automated performance review.
3.2.5. Visibility of layout rule parameters
While it is possible to check every instance of some type of layout,
such as stud or oor joist spacing, current practice in drawing layout is
to denote the generation rule, e.g., 2 4 studs at 16" O.C. The layout
rule parameters on a drawing are assessed, not the graphical layout
itself, for these aspects. These denotations eliminate much possibly
redundant checking. Layout parameters are important in checking
wherever a simple rule has been dened for generating a layout. It is
easier to check the parameters in the layout rule than every instance
of its application. Such layout rules can be explicitly entered in the
building model as attributes; because the IFC is dened using the
EXPRESS 1.0 Language [34] and EXPRESS 1.0. cannot represent layout
generation rules, alternative conventions documenting the layout
rules is required.
3.3. Rule execution
The execution phase brings together the prepared building model
with the rules that apply to it. Execution issues largely deal with the
management of this the review process.
3.3.1. Model view syntactic pre-checking
Prior to applying rule checking, syntactic checking of the model is
needed, to determine that the building model carries the properties,
names, objects needed, either for the complete checking task or more
likely, for limited model views, for checking a part of the rule set. If new
model views are derived, then the pre-checking is carried out prior to
the derivation. Pre-checking needs to be undertaken to validate that the
data needed for checking is available from the model [35].
The actual rule execution becomes relatively straightforward when
(1) the rules have been interpreted into computable forms consistent
with functions, (2) the functions have been prepared that match the
capabilities and information available in the building model.
3.3.2. Management of view submissions
Modular rule checking systems that apply a set of related rules to a
model view are expected to be the common structure for code checking.
General rule checking then will require a management system to coor-
1015
dinate and oversee the application of the multiple rule modules and
their results. Management will have to address at least two issues:
Completeness of rule checking: If views are separately submitted to
assess different types of rules, then the selection of the appropriate
rule subset is required. As the different rule sets are checked, the
completeness of the entire rule checking process must be managed.
Model version consistency: Methods for model version consistency
also must be put in place that determine that all model views submitted for assessment form a single integrated design, not one that has
been varied inconsistently so as to pass each of the subset requirements. This issue is complicated if the assessment is iterated with
partial changes.
Because of incremental implementation and rollout, it is anticipated
that code reviews will be a mixture of automated and manual checking
for many years. The development of rule processing environments is in
its early stages of development and will deserve signicant attention as
the eld matures. These issues may not apply for design guide and
project-level rule checking.
3.4. Rule check reporting
The last step in rule checking reports the results. Design conditions
that are satisfactorythose that PASSneed to be reported as part of an
audit trial that validates the completeness of the check. One can envision
various situations where the identication of instance conditions that
pass a rule would provide valuable knowledge, for example a special
case earthquake zone structural test.
Rules are dened at the implementation level according to the object
class, group or conguration they apply to. For a particular building, a
single rule may apply to hundreds or even thousands of instances of the
object class within the building, e.g. all doors or windows. Each of these
instances needs to be discriminated in the testing and reporting. For
example, if a rule applies to all hospital rooms and the rooms vary, then
all hospital rooms will have to be tested and results reported.
3.4.1. Rule instance graphical reporting
While buildings have clear labels regarding oor levels and spaces,
many of the contexts that must be checked address conditions that
have no naming scheme. For example, the framing conditions on
some corner in the middle of the building may not satisfy some rule. A
simple and intuitive means to identify these is by reference to location
in project coordinates, and placing the viewing camera at a location
depicting the issue. This is typically done for spatial conict testing
[36,37]. Examples of this approach show that it is an effective way to
communicate problems to people submitting the building models for
review.
3.4.2. Reference to source rule
Associated with the error location must be the applicable rulethe
condition checked at the given location. This requires carrying out the
reverse mapping from the rule interpretation task, mapping back to
the original textual description of the rule. The local instance
parameters and the text dening the rule violated are the basics for
reporting. More elaborate reporting, with specic text explaining the
error will evolve, describing how the rule might fail, with parameters
for the relevant instance codes, or possible actions to correct the error.
Different assessment reports may be required for the testing
organization and the submitter. For example, the testing agency may
need to know assumptions of the testing for later possible audit
conditions that the design submitter may not be interested in.
At some point in the future, rule checking may have extended
reporting capabilities. For example, the reporting could be by xml
back to the host application and model, allowing quick correction.
Issue management systems can support tracking and acting on errors
to manage corrections. Also, rule systems implemented locally
could do the error reporting in the authoring tool, facilitating much
1016
reduction in the correction iteration cycles. These capabilities will not

be available until reliability of rule checking systems is achieved.
3.5. Summary
The four steps on rule checking and the associated processes and
issues identied within them are those encountered by the authors in
their own work and observed in the work of others. They outline the
software processes needed for a working rule-based checking system
and in some cases identify the options that can be taken. These four
classes of capabilities are diagrammed in Fig. 1, with the various aspects
of the four capabilities identied within the category boxes. As development expertise in rule checking systems grows, we expect new issues
to emerge. These functional steps are used in the succeeding sections to
review the current implementation efforts.
4. Rule-based platforms
Research development of rule-based systems for building models
began two decades ago [20]. During the intervening time, building
models and the methods for rule checking have been developed, but
effective rule checking systems are just beginning to become
available. The technology is still young and quickly evolving. Rule
checking systems are large applications and require signicant
software utilities to provide the functionality we have outlined. The
earliest efforts had to develop these capabilities from scratch, while
later efforts have been able to rely on intermediate platforms that
provide some of the needed functionally. We are aware of four
different software platforms that have been developed to support
implementation aspects of rule checking systems, all applying rules to
IFC building model data.
Solibri Model Checker: Three of the development efforts reported
here utilize the Solibri Model Checker (SMC) platform [36]. SMC is a
java-based desktop platform application that reads an IFC model and
maps it to an internal structure facilitating access and processing. It

includes a variety of built-in functions:
a library of capabilities for pre-checking a model, such as shape
overlaps, name and attribute conventions, object existence and
others, as a precursor of a more detailed check
automatic viewing of checking issues, for use in reporting
capabilities for accessibility checking, based on the ISO accessibility code [7];
space program checking against the actual spaces in a building
[38];
re code exit path distance checking [39];
a variety of means for reporting checking issues that include pdf,
xml, and xls formats, as well as proprietary SMC visualization and
reporting format suitable for design reviews using the free Solibri
Model Viewer.
Rules can be parametrically varied through table-set control parameters. However, entirely new rules are added in java using the
SMC application programming interface (API). The API interface is not
publicly available, restricting the rules to be checked to those supplied
by Solibri.
Jotne EDModelChecker: Several code checking efforts reported here
used the Jotne EDModelChecker [40] as part of their implementation.
EDM provides an object database and supports the open development
of rule checking using the EXPRESS language, which is the language in
which the IFC model schema is written. New model views can be
developed using EXPRESS and EXPRESS-X, which is a language for
mapping instance data from one EXPRESS schema to another and
supports extensive queries and reports [41,42]. These facilities make
EDM open to sophisticated user extensions. EDM also provides textual
reporting and server services. It is supported by EDM Model Server, an
object-based backend database server, that allows EDM to deal with
large building models and potentially several of them at a time [43].
EDM has been applied to several projects not reported here, including
Fig. 1. The four classes of functionality a rule checking system should support: Rule derivation, building model preparation, rule execution, and rule reporting, and their needed
internal capabilities.
several by Statsbygg and by the National Ofce of Building Technology

and Administration (BE) in Norway [39].
FORNAX: The rst large effort in building rules checking, the
Singapore CORENET effort developed its own platform, called
FORNAX, developed by novaCITYNETS Pte. Ltd on top of EDM Model
Checker [44]. FORNAXt is a C++ object library that derives new data
and generates extended views of IFC data. FORNAX objects carry rules
for assessing themselves, providing good object-based modularity.
FORNAX has been reviewed by a number of other building code efforts
as a possible platform [3] including the Norwegian Selvaag Group,
who applied it to re exit assessment [45,46].
SMARTcodes: A new platform for rule checking is being developed by
ICC, called SMARTcodes. It provides methods of translation from written
language rules to computer code, using a dictionary of domain-specic
terms and semi-formal mapping methods [6]. SMARTcodes also
provides methods to access the relevant data in an IFC model and
report on results. SMARTcodes has been developed by AEC3 and Digital
Alchemy.
We expect each of these platforms to grow in functionality, as each
of the efforts they support mature. A joint feasibility study that is
initiated by Standards Norway (SN), BE, and Statsbygg was carried out
in the rst half of 2009 by research organization SINTEF to assess and
recommend open platforms for describing rules from such sources as
standards, building regulations and client policy documents in an
unambiguous form suitable for computer code implementation [47].
The English version report will be issued late June 2009. The project is
focusing more on rule derivation and building model preparation than
on actual software, though a short survey of commercial rule checking
software may be included.
5. Survey of rule-based building model checkers
In this section, we summarize the implementation efforts undertaken to date on rule checking systems.
Much of the current work has been presented in working reports and
conference presentations. They have typically addressed only aspects of
their overall system. Also, almost all systems are still in development and
aspects of the work have not yet been made public (and possibly not yet
developed); the work is in-progress. Based on the available reporting,
and in some cases, personal communication, we have tried to interpret
the approach and details of the ve systems we are reporting on here.
We rely on the four steps and their details presented in the last section to
provide high-level characterization of the systems and to compare and
differentiate the various efforts. We are also interested in any new
concepts or developments not addressed in our basic denitions above.
Each of the ve systems is summarized in Table 1. The non-empty
cells are those for which we have information and report on them in
this section. All of the efforts are incomplete and thus our report
reects their status as of early 2009.
5.1. CORENET-Singapore
The Singapore CORENET project (http://www.corenet.gov.sg/)
(COnstruction and Real Estate NETwork) was the earliest production
code checking effort initiated in 1995 by Singapore's Ministry of National
Development. It is being implemented by the Singapore Building and
Construction Authority. It consists of three modules for the Design
Phase: CORENET e-Submission, CORENET e-PlanCheck and CORENET
e-Info. e-Submission tracks building permit actions and e-Info provides
advisory information for various construction-related departments. Our
interest here is e-PlanCheck. It initially undertook development to work
using electronic drawings, but switched in September 1998 to operate
on IFC building model data. This project aims to cover building code
checks on building plans (IBP) and code compliance for building services
(IBS). Plan checking currently includes rules on dealing with building
control, barrier free access, re code, environmental health, household,
1017
public housing and vehicle parking. The building service module

includes rules on electrical, re alarm system, re sprinkler system,
raising main and re hydrant system, ventilation, sanitary, plumbing
and drainage system, surface water drainage, gas pipe system and water
services. It is the most mature of the reviewed efforts.
5.1.1. Rule interpretation
Currently CORENET rules are hard coded in computer programming language. Mapping of the IFC schema for implementation of rule
checking is a big issue for automatic building code checking. CORENET
addressed this issue in their project presentation material [32] and
developed semantic objects in the FORNAX library that extend the IFC
Schema to capture needed building code information and to facilitate
the implementation process. FORNAX is object-based and both
involves IFC extensions and also the denitions of rules.
CORENET rule checking is performed in three phases:
(1) checking rules with current IFC information,
(2) checking rules with property set extensions to IFC and
(3) checking rules with derived information from IFC.
5.1.2. Building model preparation
In order to dene and check the extended properties for certain
entities, the CORENET system has the FORNAX interface and checking
module. The FORNAX schema contains objects which extend IFC information to provide that needed for checking certain building codes. Each
FORNAX object also has diverse functions to retrieve required properties from IFC data. Fig. 2 shows an example of FORNAX object and its
functionsExistStaircaseShaft.
By using the FORNAX objects, a programmer does not need to
develop algorithms for retrieving required information from IFC data.
Simply by adopting FORNAX objects and their member functions, a rule
written in natural language can be interpreted to programming
language methods and applied.
FORNAX objects are dened to capture specic rule semantics.
Thus the objects and their functions retrieve attributes from the
object, depending on the type of rules. For example, objects and
attributes for hospital design are different from those for airport
design; a different set of FORNAX objects and their functions are used
for retrieving attributes in different building types. FORNAX uses the
Open CASCADE [48] and ACIS solid kernels [49] as geometry engines
and services for retrieving and structuring required data from an IFC
building model. Fig. 3. diagrams the system architecture of CORENET
based on FORNAX which was developed by novaCITYNETS Pte. Ltd. for
the Singapore Building and Construction Authority [44].
5.1.3. Rule execution
CORENET implements rules by using properties and functions
dened in and accessed through FORNAX objects. No information was
obtained regarding model validation and pre-checking, dealing with
the execution completeness issues or combinatorics, view management and incremental testing.
5.1.4. Rule reporting
E-plan check has a capability to report checking results through a
website. It generates the checking report with reference to the source
rule it applied in checking. E-plan check supports diverse reporting
formats such as HTML in the web browser, Word or PDF format and
also a graphic format for the FORNAX viewer.
5.1.5. CORENET summary
The Singapore effort in building code checking was the earliest and is
currently the farthest along. It is being used productively today and offers
examples of how such efforts may be undertaken. CORENET states that
92% of rules in IBP and 77% of rules in IBS are currently covered by the
CORENET systemas of 2008. And more than 2500 rms, which include
1018
Table 1
Overview of rule checking systems.
SMC supports computation of additional geometry, such as door swing arcs, wheel chair turning circles, that can be used in checking rules.
architects, engineers, surveyors and other professionals, are reported to

be using CORENET for submitting plans to the Singapore government.
5.2. Norwegian Statsbygg's design rule checking efforts
European countries have explored multiple paths to take advantage
of BIM, and in automated design rule checking, using specic projects as
tests. The Singapore CORENET e-PlanCheck check system was tested in
both the Selvaag Group's Munkerud housing projectfor checking the
building distance/height/utilization, and the Akershus University
Hospital (AHUS) project for evacuation related rules [39,46]. These
were early Norwegian efforts on Norwegian IFC-based BIM projects. In
order to support various design rules for the projects, multiple platforms
have been experimentally adopted: e-PlanCheck, SMC, dRofus, EDM
Model Server and Checker, etc. Because Norwegian design rule checking
systems have been realized based on actual building projects using
multiple platforms, in this section we review their efforts based on a
representative Norwegian BIM project for Statsbygg named HITOS
(localized acronym for Troms University College), rather than a single
platform [39,50]. We found two salient design rule checking features in

the HITOS project: (1) for evaluating spatial program requirements with
dRofus, and (2) checking building accessibility using SMC.
The HITOS project is managed by the Statsbygg governmental
agency. It is one of the biggest clients of the AEC/FM industry in Norway
and undertakes research and development projects to enhance
efciencies for planning, constructing and managing its real estate
portfolio. Its folio includes 1500 buildings in Norway and abroad
(embassies, etc.) [51]. Troms University College and Statsbygg have
been managing the HITOS project since late 2005, when the program
phase was concluded. Several software packages were used in this
project: ArchiCAD for design, ADT for structural, DDS for MEP, Octaga for
model viewing, NOIS G-PROG for cost estimating, Granlund Riuska for
energy simulation, Powel Gemini 3D Terrain for terrain modeling, as
well as dRofus and SMC. All are integrated and managed by the EDM
Model Server. The project covers around 53,800 SF of new buildings and
extensions on a 129,000 SF site. One of Statsbygg's objectives for the
project was Contribute to increasing the chances of theme-related
analyses (e.g. within LCC, energy, the environment, re, acoustics,
1019
Fig. 2. An example of FORNAX objectExistStaircaseShaft adopted from the Singapore Civil Defense Fire Code [67].
universal layout, service lifetime etc) based on increased awareness/

value in building information as described in its report [52]. Fig. 4
illustrates the overview of spatial program requirement validation,
building accessibility checking, and other processes centered on IFCbased interoperability.
Fig. 3. System architecture of CORENET project (With permission of novaCITYNETS).
5.2.1. Spatial requirement checking

In the earlier part of this paper, we described three classes of rulebased systems: for all buildings, for particular building types, and for a
specic building instance. In the HITOS Project, dRofus was used for
checking spatial program requirements for individual building
specic rules for several of their college buildings. The project covers
multiple facilities managed by different teams within a centralized
repository. dRofus supports web-based collaboration for each project
populated in the model server. dRofus is thus a database system for
managing architectural programs, technical/functional requirements,
and equipment from early stage planning and throughout the whole
building project. It addresses structured room requirements, room
data sheets and equipment planning [53]. dRofus has an interface for
managing spatial data in a hierarchical tree structure and it compares
planned data with the actual area from IFC model in the same
interface. It receives non-graphical data from different building
models as they progress but does not deal with visualization or
manipulation of building geometry itself. For example, rooms could be
added or removed through standardized but editable room templates.
Detailed attributes, properties and associated values can be manipulated and exported through the dRofus interface. It has an interface
for managing spatial data in a hierarchical tree structure, and it
compares planned data with the actual area from an IFC building
model in the same interface. dRofus does not require rule interpretation in the general case, as it is a dedicated application that manages
1020
Fig. 4. Process overview of the rule checking in the HITOS Project.
one type of rule (spatial areas). dRofus supports IfcZone, IfcSpace

entity data and several associated attributes (Fig. 5).
dRofus supports exploring the resulting spatial data using
commonly used document formats with more than 60 different
report layouts. Most reporting aspects in the spatial program review
are not specic rules but rather a report that shows the comparison
and discrepancies between requirements and actual space area
values. Therefore, the Norwegian Statsbygg's column of Table 1 only
deals with accessibility rule checking system as described in the

following section.
5.2.2. Rule checking for accessible design
The other module in the HITOS Project addresses accessibility
checking. Some of the requirements for universal design were initially
dened in the dRofus database. Solibri involvement in the HITOS
Project is to provide a universal design assessment application
Fig. 5. dRofus handles detailed spatial data in tabular structure, and exports them with a dummy space geometry [38].
1021
Fig. 6. Examples of accessibility rule checking and their visualization in SMC on building instance examples: 1) accessible corridors using buffered boundaries, 2) overlapped door
swing arcs, 3) not enough area for wheelchair turning in a bathroom.
running in Solibri Model Checker. SMC's accessibility rules are derived

from the following standards:
International ISO/CD 21542 (draft). [54]
International Code Council ICC/ANSI A117.1. [55]
SMC supports various parameterized rules derived from these
standards, including wheel chair turning circle, stair, ramp, and door
dimensions and clearance. The rule examples in natural sentences are
as follows:
The minimum clear passage width of a doorway shall be not less
than 800 mm.
An end landing shall be provided at the foot and at the head of a ramp.
The rise and tread of steps within ights shall be uniform.
The surface width of a stair shall be not less than 1200 mm.
Head clearance height above the stair shall be greater than
2100 mm.
Surface materials shall be rigid with a plane and slip resistance
surface, in both wet and dry conditions.
The process of accessibility checking in the HITOS project provides
a good overview of SMC functionality. That is, some general features of
SMC are also applied in other SMC-based case studies reviewed here.
The accessibility rules are translated into a parametric table structure:
Accessibility ruleset, and Solibri incorporates all required checking
functionality for executing the tests.
Fig. 6 shows an actual model of HITOS in SMC and some specic
checking examples. For accessibility checking, SMC supports processes with not only geometric data of a single building object but also
other associated objects and their properties, such as surface material.
The accessibility rules basically involve building objects such as
spaces, doors, stairs, ramps, and windows. The majority of rules deal
with the relation between these objects. Some rules dene relations
between the sub-objects composing them. For example, for checking
clear width of corridors as shown under the criteria circulation in
Table 2, several input parameters are required not only for its oor
width but also for other associated objects such as columns, doors,
washbowls, etc. Fig. 7 depicts some input parameters for these
relations between different objects. Most of them are geometry
related issues, but some other rules deal with an object's properties
such as surface materials and glare percentages as shown in Table 2. A
space name based ontology supports the accessibility checking. That
is, some specic spaces or objects are associated with certain kind of
accessibility rules, such as a washroom, kitchen or storage. Therefore
SMC supports restrictions on which objects are accessed for given
attributes by space names or locations.
When a given IFC model is prepared, SMC retrieves all the ruleassociated building objects and their geometric data. From the
parameterized rules, the system receives the mapping between
building objects and required values coded within checking equations. Also the values for rules can be adjusted instead of using the
default values taken from ISO/CD 21542 [54]. This is needed when
national or other codes vary from the ISO standard. Different rule sets
can be called up to apply to a model. Currently, however, SMC expects
the user to manage model views, to submit them to the computer or
server. No information is carried across multiple rule checking
sessions for example any changed defaults for conditions in Fig. 8.
When a given IFC model is prepared, SMC retrieves all the ruleassociated building objects and their geometric data. From the parameterized rules, the system receives the mapping between building
objects and required values coded within checking equations. The
values for rules can be adjusted instead of using the default values
taken from ISO/CD 21542 [54]. This is needed when national or other
codes vary from the ISO standard. Different rule sets can be called up
to apply to a model.
SMC has extensive pre-checking capabilities, as reported earlier. Different rule sets can be called up to apply to a model. Currently, it expects
the user to manage model views, to submit them to the computer or
server.
Table 2
Overview of the accessibility rule checking in SMC: criteria, building objects, and
checking features.
Criteria
Objects
Requirements for
Door
accessible circulation
Corridor
Stair
Rules for specic

spaces
Windows
requirements
Surfaces
requirements
Ramp
Washroom
Kitchen
Storage
Window sills
Checking features
Door dimensions and their swing
operation
Clear widths and wheelchair
turning diameters
Various requirements for risers, treads,
steps, etc.
Slope, length, clear widths, etc.
Washroom door requirements,
wheelchair turning
Wheelchair turning diameter checking
Wheelchair turning diameter checking
Maximum sill height
Required oor coverings and related

property sets
Stair, ramp surfaces Non-skid materials on surfaces
Floor, wall coverings
1022
Fig. 7. Input parameter window of required properties for any accessible stair (courtesy SMC).

SMC supports textual and graphical reporting in several document
le formats. It can also provides the severity of rule violations in three
levels: Critical, Moderate and Low. SMC has functionality to save check-
ing results in its own le format, but IFC export isby designnot
supported; SMC is not intended to be a model authoring application.
However hotlinks to common BIM/CAD applications like Graphisoft's
ArchiCad and Autodesk's Architecture DeskTop (ADT) are provided,
Fig. 8. The input parameters window for accessible oor (left) and door object (right) (courtesy SMC).
highlighting SMC results/issues in the BIM/CAD application. Also SMC

has no tracking functionality for reporting conditions that pass the
applied rules. This makes it difcult to review the instances of rule
processing applied to a given model.
5.2.6. Summary
The dRofus spatial checking database addresses the role of space
planning and facility management within an institution managing large
amounts of space. It relies on IFC spatial data and commercial applications linked together within the HITOS project. The accessible design
checking in the HITOS project is Solibri-based and relies on functionality,
found in SMC-based installations. Some rules were developed specifically for this project, and co-funded by Skanska Finland and Statsbygg
Norway. The ISO-based accessibility rule checking has been amended
and incorporated as one of the default rulesets in the latest release of
SMC as of 2009 [7]. Statsbygg found that the IFC-based universal design
checking implemented by Solibri could reduce by 6070% the common
design failures or deciencies [50].
5.3. Design check by cooperative research centre for construction innovation
in the Australia
The Cooperative Research Centre for Construction Innovation in
Australia funded a project that included the Commonwealth Scientic and
Industrial Research Organization (CSIRO), University of Sydney, Building
Commission Victoria, Australian Building Codes Board (ABCB) and Woods
Bagot. The Australian Building Codes Board (ABCB) on behalf of the
Australian Government and State and Territory Government maintains
and updates the Building Code of Australia (BCA).
In the rst stage of the project, Express Data Manager (EDM) [43] and
Solibri Model Checker (SMC) [36] were reviewed in relation to the base
1023
functionalities required for automated code checking. The code requirements for accessibility, which are dened in the BCA D3, Australian
Standard (AS) 1428.1 Design for access and mobility, were used for an
initial feasibility assessment [56]. Because the SMC capabilities are
reviewed elsewhere, this review focuses on the EDM capabilities, which
was the platform the assessment later recommended. The EDM platform
was then used in the second stage of the project in which all of the nonadministrative clauses in AS 1428.1 and BCA D3 were encoded [5].
The ABCB EDM implementation relies on object-oriented techniques
for its development approach. It utilizes the following pre-implementation specication structure: Description, Performance requirements,
Objects, Properties, Relationships, Domain-specic knowledge for interpretation (see Fig. 9). These descriptions provide written statements
of building codes interpretation. Then the statements are translated
(by people) into the performance requirements in computer code. The
performance requirements facilitate translation into objects and
relations. In order to handle the requirements, objects and object properties are extracted from the building information and accessed to
assess the performance requirements.
EDModelChecker uses the EXPRESS language to dene the rule
schema [41]. The pseudo code which is relevant for interpretation of
domain-specic knowledge (example shown in Fig. 9) is encoded into
functions and rules in the EXPRESS language. Since the objects, object
properties and object relations utilized by the rules are all represented
by the IFC model schema, this rule schema can be clearly dened.
While this structure works well for many aspects of code checking it
is difcult to dene checks for handling some conguration criteria.
Fig. 9. Encoding example of a building code according to IFC object-based interpretation [56].
1024
Fig. 10. An illustration of the adjacency graph, where F means false and T means true [68].
Since AS 1428 requires access to the determined rather than calculating path distances, a graph approach was taken (see Fig. 10).
Starting at an external entrance that was accessible, the containing
space was dened as accessible. All adjoining spaces which had
accessible openings into this previously checked space where then
dened as accessible. This can be applied recursively across the
building model until all accessible spaces are tagged. This can then be
checked against the need to be accessible.
The ABCB system in organized into rule sets. It runs the chosen rule
set against the model initially as a pre-check to identify areas with
insufcient information.
The project used EDM functions to generate text-based reports for
checking results. The reports are saved into XML and HTML documents.
As shown in Figs. 1113, references of non-compliant codes give
detailed description of violations and building elements. An interactive
report system is also provided to show analysis results for each clause or
object type selected. As shown in Fig. 11, the report panel key gives brief
information for analysis results according to each clause. Interactive
page reporting allows end-users to select the report type that they wish
to view and update the building model (see Fig. 12). A print-friendly
version of the report (see Fig. 13) is linked to the interactive report page
of Fig. 12. The Design Checking system currently supports graphical
reporting without geometric shape of building objects, but provides
warning for designers.
5.3.5. Summary
The Australian code checking effort was developed in two phases.
The CRC for Construction Innovation undertook the rst phase in
order to assess the capabilities of current rule checking systems and
for nding out the best approach for supporting computerization of
Australian Standards. Two major checking systems were compared by
applying the same building codes within the two systems. The EDM
prototype was found to offer a more exible and open development
environment, because the EDM system provides a publicly accessible
denition language to represent building codes. However, working
knowledge of the rule writing capabilities of the EXPRESS language
is limited to only the small group of people who learn it on their
own (in relation to C++ or java). After completing the feasibility
study, Design Check system was developed in Phase Two [5]. The
development method which was adopted by the feasibility study in
Phase one was applied. A graph was developed for inferring adjacent
accessible spaces for accessibility checking. The report system has a
direct interface to the database of the building model and provides
both an interactive report page and print-friendly report page. 3D
graphic view will be integrated with rule checking system in future.
5.4. International Code Council (ICC)
The International Code Council (ICC) develops the master building
code used by jurisdictions in North America. It is used to construct
codes for residential and commercial buildings and most institutional
buildings. In 2006, it began supporting development of SMARTcodes;
the development being carried out by AEC3 and Digital Alchemy.
Fig. 11. Graphic display of the check results [68].
1025
Fig. 12. The interactive report page [68].
SMARTcodes provides for the mapping of written building codes into

interoperable computer-interpretable code sets. The project for
developing SMARTcodes focuses on automating and simplifying
code compliance checking against the ICC codes and federal, state,
and locally adopted versions of the codes.
Currently, International Energy Conservation Code [57] has been
implemented. The SMARTcodes uses an IECC dictionary for denitions
of terms for objects and properties that are critical for model checking.
It provides SMARTcodes builder, which is Web-based software to
facilitate creation of SMARTcodes. This software reduces errors which
occur during the interpretation of original building codes into
SMARTcodes/it supports this by having user identify key phrases
and their logical role, then formalizes the phrase using terms from the
dictionary (see Fig. 14). Written rule statements, regulations and
specications are interpreted by the SMARTcodes builder, using the
IECC dictionary that describes properties associated with each term,
the enumeration of properties, data types and units associated with
each property. The dictionary is used not only for rule interpretation,
but also for communication between SMARTcodes model checking
system and the IFC building model. IFC object properties dened in
the dictionary provide model views for rule checking. The model
views are classied by terms and properties of the dictionary.
ICC allows end-users to try out the model checking system through a
web site [58]. Currently, SMARTcodes for Solibri Model Checker,
developed by Digital Alchemy (DA), and AEC3 XABIO, developed by
AEC3 [59], support the rule-based building code compliance checking.
The Web services require input values such as a building model, building
location, code to be checked and model checking system. Currently,
building models are limited to several pre-congured test models
provided on the web server that satisfy modeling requirements needed
for checking. They include a prototypical ofce building, Lawrence
Berkeley National Laboratory, the National Association of Realtor
Headquarters building, and four building models provided by the U.S.
Coast Guard. In the future, SMARTcodes will support submission of enduser's building models. Only selected portions of the 2006 IECC is
available for demonstration.
1026
Fig. 13. The print-friendly report page [68].
Fig. 14 provides an overview of the SMARTcode system. Manual

Code Search provides ltered code text and reference standards. The
code text provides sections and paragraphs for feedback within a code
report. An example of code markup relevant to the rule checking
result report is shown in Fig. 15. Since the checking systems are
available on the web, the rule text written in XML and accessed
through the web browser. The cross-linked regulations can be directly
accessed through hyperlink functions.
Reporting is supported through the Model Checking Software
(MCS) module in SMARTcodes. The software provides end-user
checking results in several alternative document le formats, such
as HTML, PDF, RTF, XLS and XML. Analysis results include table-based
summaries and graphics-based reports. The table-based summary
briey reports whether a building model violates codes for compliance checking or not. An example error report is shown in summary
comments of Fig. 16. Also, detailed description of violated rules is
provided with graphical images about elements of the building model

(see Fig. 17).
The analysis results of code compliance checking provide information regarding the building elements violated. SMC provides the MCS
with identier, location, property and geometric shape of a building
element on the browser. As shown in bottom left of Fig. 16(b), the
reason for non-compliance is stated. In this case the wall (Wall.3.1
is identied in SMC window) thermal resistance of design is 0.0R,
but the code requires 13.0R or greater. Location information relevant
to the wall is automatically visualized on the graphic browser of
SMC. This information with a textual reference of code criteria is also
specied in the report.
AEC3 XABIO also provides a trace back report giving a logical step
explanation for failure.
5.4.3. Summary
The ICC SMARTcodes is a new approach for rule checking system
development, taking a fairly comprehensive approach to the overall
Fig. 14. Framework of model checking system based on SMARTcodes.
1027
Fig. 15. Textual reference to source rule text (with permission of Digital Alchemy).
checking and reporting tasks. Building codes are created from

SMARTcodes builder in a rigorous and formal way that facilitates
semi-automatic creation of computer-processible codes. Currently
the SMARTcodes model checking system focuses on available or easily
derived properties rather than deriving auxiliary model views or
analytical models for complex simulation for various kinds of analyses.
5.5. General services administration design rule checking
Within General Services Administration (GSA), the Public Building
Service (PBS) manages workspaces for the federal government and is
the largest owner of commercial space in the United States. The (GSA)
initiated the National 3D4D-BIM Program through its PBS Ofce of
Chief Architect (OCA) in 2003 [60]. They have initiated six BIM
demonstration projects; two programs are associated with development of assessment tools. Assessment tools for Spatial Program
Validation and Automated Design Guide Checking, both developed as
part of their 3D4D Building Information Modeling program.
5.5.1. Spatial program validation
New building design for GSA follows a fairly traditional development
process, with multiple stages of concept design, design development
and construction documents. The tool for spatial program validation
allows GSA project teams to automatically assess whether or not the A/E
late concept design conforms to the GSA approved spatial program, in
relation to the spatial requirements set forth by the Congressionally
approved housing plan and PBS Business Assignment Guide [61]. These
requirements include area measurements (e.g., net or usable) and
building efciency measurements (e.g., fenestration ratio). Starting
in 2007, all GSA projects involving new construction are required
to submit BIM data allowing spatial validation review in the nal concept phase. Submitted BIM data is quickly analyzed (see Fig. 18) and
reviewed by the GSA project team.
As shown in Fig. 18, various kinds of area calculation are dened by
PBS Business Assignment Guide and ANSI/BOMA area calculation
guide [62]. These area values are automatically derived from the
building model according to fairly intricate conditions specied by
the ANSI/BOMA space denition method. Since this assessment tool
is available in the SMC browser, these area values are exported to a
reporting document as a basic function. This assessment is similar to
the dRofus assessment by Statsbygg, but uses a different method of
area calculation and reporting.
5.5.2. Design guide checking
GSA has also funded development of a rule checking system for
circulation and security validation of U.S. courthouses, called Design
Assessment Tool (DAT) and was developed by Georgia Institute of
Technology. For the development of DAT, circulation and security rules
were extracted from U.S, Courts Design Guide (CDG) [63]. CDG denes
the criteria for federal courthouse design, based on best practices gained
through the US Courts' experience from designing then occupying
courthouses over roughly the last 100 years.
5.5.3. Rule preparation
The Courts Design Guide was parsed and scanned and encoded to
identify those statements dealing with circulation. 302 statements
were identied. These were analyzed and grouped according to
similar conditions, then translated into a set of computable parametric
rules in DAT, that could address all of the circulation issues that were
identied. Circulation rules are parameterized into four high-level
1028
Fig. 16. Table-based reporting. (a) Table-based reporting of SMC. (b) Table-based reporting of AEC3 XABIO (with permission of AEC3 UK Ltd.).
conditions: start space, intermediate space, destination space conditions and transition conditions. The space conditions have a space
name and also a security level (public, restricted or secure). As shown
in Fig. 19, transition conditions can represent security level, route
walking distance length, vertical accessibility, etc. These are specied
in a SMC parametric table. A circulation rule dened by the
combination of these parameters becomes computer-processible for
automatic checking using a SMC plug-in developed by Georgia Tech.
In the circulation validation module, a circulation data view is
extracted for validation. End-users can dene a building model using
a BIM authoring tool according to GSA Series Six BIM Guide for
Circulation and Security Validation [64]. The checking module relies
on standard space names used in courthouses which also determines
the security level of all assigned spaces, as dened in the CDG.
In the IFC models, a security zone is associated with each space in a
property set denition. Table 3 shows minimum modeling information requirements for circulation validation checking. These requirements are implemented as a pre-checking module using the SMC
technology where space names, security assignment and connectivity
of circulation paths are pre-checked.
Implementation of the circulation requirements involves the

derivation of a circulation graph of the complete building, identifying
all occupiable spaces and their interconnectivity, as dened by walls,
doors, stairs, ramps, elevators and boundaries between directly adjacent
spaces (without separating walls). Building model elements are
automatically mapped to graph nodes and edges. Two types of graph
are dened: (1) a topological graph represents connections between
spatial elements (see Fig. 20). This graph was used to check routing
paths dened in parameterized circulation rules. (2) The metric graph
represents distances reecting human movement paths within a space
[65]. This graph is used to check moving distance between two spaces
and to visualize circulation analysis results (see Fig. 21).
Through the graph structures, circulation validation checking
system can assess whether circulation paths between two spaces
of the assessed building model satisfy the given requirements. This
circulation assessment is an example of an assessment that deals with
issues not easily handled on the basis of a building model itself.
The pre-checker identies any modeling or name problems before
real checking is undertaken. The check involves a single module, not
requiring management of views or modular rules.
Fig. 17. Graphics-based reporting. (a) Graphics-based reporting from SMC (permission of Digital Alchemy). (b) Graphics-based reporting of AEC3 XABIO and Octaga.
1029
1030
Fig. 18. Spatial program validation results.
Fig. 19. Table parameters for describing circulation rules of a design guide.

Since the rule checking is performed on the basis of interpreted
parameters which are derived from the Courts Design Guide, the
original circulation rules written in a natural language are provided in
the checking results for end-users' conrmation. The circulation rule
checking system developed for GSA provides a back-reference
number to the section, page and line of the Court Design Guide.
Table 3
Minimum modeling requirements for circulation checking.
Modeling
element
Description
Space
Space names should be dened on the basis of Space naming

conventions of GSA BIM Guide.
Security zone should be one of public, restricted, and secure.
This information can be dened as property denition for each
space.
Is part of wall. Door adjacencies to two spaces used for accessibility
checking.
Use of IfcStair and IfcRelContainedInSpatialStructure.
A stair should be contained in a space.
Stair may have components such as slab (landing) and ight
A ramp should be contained in a space like stairs.
Ramp may have components such as ight and slab (landing)
Currently, elevator objects are dened through space name. For
example, judges elevator, prisoner elevator.
There is no special requirement. Just needed for space boundary.
Security zone
Door
Stair
Ramp
Elevator
Wall
Violated circulation routes are visualized showing the graph traversal

structure as a route between starting space and destination space. That is,
if the building model does not satisfy a circulation rule, one violated route
from all possible routes is visualized. The shortest failing route is selected,
as shown in Fig. 21. The circulation rule states that USDC courtroom
should be accessible from USDC judge chamber through restricted zone.
But since secure zone is located between the start and destination space
in the example, this model does not satisfy the circulation rule. These
images are also exported into the reporting document.
In the circulation checking system, oor level, space name and
number of start and destination space are provided so that the textual
description may allow architects (end-users) to recognize the violated
circulation rules. For example, the description of rule checking error
shown in the E5 is There is no path that uses following transition
conditions starting from USDC Judge Chamber (9) of Floor 1 (Floor
level) and ending to USDC COURTROOM and Transition conditions
are Security Level: restricted, Usage: circulation, Vertical Access:
allowed. Thus, the detailed error message gives end-users a clear
description of the violated building elements and circulation rules.
Since this circulation validation checking system of GSA was
developed on the SMC platform, basic functions for analysis reporting
are similar to other rule checking systems.
5.5.7. Summary
The spatial program validation application is now applied to all
GSA new construction projects. The design guide checking application, which has only addressed circulation and security thus far, relies
1031
Fig. 20. Reporting.
on a derived graph based on the room connectivity, space names and

security zone within oors. Each oor is connected through vertical
circulation, which also has security classes. The application uses the
Solibri platform, extending the family rules SMC supports. DAT has
been applied to multiple US Courthouse projects. Its operation is
about 90% automated.
6. User experience
User experience with rule-based systems is limited. Only the
Singapore e-PlanCheck system is operational but the authors were
not able to gain feedback from its users. The ICC checking system has
a demonstration site, at: http://www2.iccsafe.org/io/smartcodes/. It
has a section of the energy code that can be applied the any of the
pre-prepared entries in the menu of buildings. Example reports
are generated, including a model viewer allowing visual inspection.
These work well, although some buildings take multiple minutes to
analyze.
Solibri seems to have the largest user base (not all using the
advanced applications reported here). It supports a wide range of types
of rule checking. Contact with some users suggests it is most used for
clash detection, space program validation, and checking models for their
structure and completeness, for interfacing with other applications. In

some ofces it is used regularly for these purposes.
The main user issues encountered in current systems are the demanding model structure requirements. Space layout, for example,
typically requires that all interior space on a slab be assigned a designation, without overlaps. Space and attribute names must match those
required. When the geometry of composed assemblies is required,
the composition requirements are often quite prescriptive, often
requiring specially-tailored model views. These types of requirement
impose signicant effort on the user. In the future, when these rule
denitions become more robust, the modeling requirements will
slacken.
7. Major issues in building rule checking systems
While rule checking system development has been going for about
ten years, the platforms are all currently limited in what they support.
As a platform, Solibri SMC has been used widely, with the functional
capabilities laid out in Section 4. It has a wide range of checking
capabilities, including clash detection, spatial validation, plus others
described in Section 4. It lacks two capabilities that are offered by the
Jotne EDM platform: an open environment for writing rules and a
Fig. 21. Visualization of violated circulation route.
1032
database backend management system. EDM has provided server

capabilities for most of the efforts reviewed here. It supports EXPRESS
and EXPRESS-X model view and rule writing capabilities. The FORNAX
software library requires full computer programming capabilities
to tailor a rule writing system to a particular need. The SMARTcodes
Builder software capabilities developed by AEC3 and Digital Alchmey
presents another important aspect of the overall environment, supporting the rigorous semi-automatic translation of written human
rules into programmable rules. Lacking is an overall systems environment that provides some level of response to all the functionality
presented here, in an open form allowing developers to dene new
rules within a domain that can be checked and results reported.
A general approach for development of rule checking systems can
be discerned from this review; to provide a method for mapping
the terms in written statements into the logic of testing conditions,
then to dene enriched data objects and methods capable of deriving
properties and relations needed to respond to rule queries. Such
efforts should be based on development of an ontology of objects
and properties for the relevant building domains. While some of the
objects are enriched versions of IFC objects, others require the derivation of new composite objects, dealing for example with accurate
models of building space or circulation networks. The development
of enriched objects for rule checking has been largely proprietary and
un-available for public review and assessment. A more public
approach seems needed, so that the effort of dening these enriched
objects can be shared and carried out in parallel. Once such object and
method denitions exist, it becomes practical to dene user-oriented
rule denition languages and checking that can move these capabilities from the software lab to a user desktop. Rule denition
languages can be created for different environments, from servers to
embedding in BIM authoring applications. Then a ruleset can be dened
in the language portably, and executable on any environment supporting the language. Only then will wide application of rule checking
technology become broadly used.
An important aspect of the overall rule checking capability must
deal with modeling requirements of the building model. The building
model to be checked has to be consistent with the rules to be checked,
possessing the needed IFC entities and properties prior to derivation
of extended information and checking. Requirements for a welldened building model should be clearly dened from the users and
software developers' standpoint, based on clearly dened model view
denitions. The ICC effort has begun to dene ICC model views based
on the National BIM Standard methods [66], as has the GSA [64].
Until now, the primary example of deriving a separate model view
for rule checking has been for pedestrian circulation assessment. Other
derived models for air ows, energy and structural analysis,
earthquake safety, terrorist attacks and other special conditions will
eventually be developed, capturing best practice knowledge in different
technical domains.
7.1. Verication of code checking
A critical issue of automatic code checking is verication of the
checking algorithms and results. Verication can be compromised by
both rule checking algorithm errors and by building model denition
errors. Known verication errors occurring from coding errors include
inexact treatment of highly nested quantication rules and their
execution, for example that every occupiable space must have at least
one exit route that meets emergency exit requirements. Another
challenge is to identify false positives. False negative tests are observable because reported errors require review. False positives are not
necessarily reviewed and thus can easily allow rule violations to be
overlooked.
It is good that many parameters representing properties of building elements such as the number and height of steps in a stair are
dened explicitly in IFC or other schema and can be used directly for
code checking. Explicit parameters of building elements are one of the

merits of a building model and resolve difculties in interpreting
geometric aspects of a design. Other errors can occur when space
areas on a slab are unallocated, leading to a miscount of interior space.
Methods of validation of both the coded rules and the validity and
consistency of building model data will be required in the longer term,
as rule checking applications become relied upon for production use.
7.2. Rule checking system as a design development supporting system
The work presented here deals with post facto application of rules
to a design. However, rule checking evaluation can also be applied
during and supporting design development. By tracking checking
results as design changes are made, the specic aspects of the design
that create problems are more easily identied and corrected. For
example, checking after every design move would allow immediate
identication of the action violating a rule and facilitate making
corrections. If the corrections are not made when an error rst occurs,
then this association of the design action and the rule violations
should be saved for later management and correction. There are many
details to be resolved to provide effective capture of rule errors
associated with design actions for later review.
7.3. Summary
Rule checking at the scale of all sections of a building code is a huge
undertaking. Complete automated code checks are many years away.
Rule-based applications for building model checking can be envisioned for a very broad range of use in architectural design, detailing
and building renovation. They could be used to dene and then check
a design against the building program, similar to the spatial validation,
already being applied by Statsbygg and GSA. Circulation, adjacencies,
space detailing, will in the future all be supported by rule checking, if
the tools for this activity are made simple and direct. They will have
use in code enforcement at the public jurisdiction level, by professional associations for best practices, as exampled by the US Courts
activities, by large franchises and owners that develop best practice
capabilities for their organizations, and possibly by sophisticated
users so they can encode and then gain automatic reports on an openended set of design issues. The eld of rule checking in building is just
emerging.
Acknowledgements
We wish to thank Fred Miller, Peggy Ho, and Charles Matta of GSA
for support in preparing this review. We also thank Pasi Paasiala and
Jonathan Widney (Solibri, Inc.), Richard See (Digital Alchemy),
Nicholas Nisbet (AEC 3 Ltd.), Lan Ding (CSIRO), and Robin Drogemuller (CSIRO) for review of earlier draft sections of this paper. For
reviewing the Norwegian part, we are indebted to the people from
Statsbygg, and Nosyko Inc. We thank to Frode Mohus, Diderik Haug,
Mai Anh Thi L, Ole Kristian Kvarsvik, Bjrne Grimsrud of the BIM
team from the Statsbygg, and smund Kveim Lie from Nosyko Inc.
References
[1] C.M. Eastman, P. Teicholz, R. Sacks, K. Liston, BIM Handbook: A Guide to Building
Information Modeling for Owners, Managers, Architects, Engineers, Contractors,
and Fabricators, John Wiley and Sons, Hoboken, NJ, 2008.
[2] T. Liebich, Y. Adachi, J. Forester, J. Hyvarinen, K. Karstila, J. Wix, Industry
Foundation Classes IFC23, International Alliance for Interoperability, 2006.
[3] K. Khemlani, CORENET e-PlanCheck: Singapore's automated code checking
system, AECBytes, 2005, http://www.aecbytes.com/buildingthefuture/2005/
CORENETePlanCheck.html.
[4] M.A.T. L, F. Mohus, O.K. Kvarsvik, M. Lie, The HITOS projecta full scale IFC test,
ECPPM, 2006.
[5] L. Ding, R. Drogemuller, M. Rosenman, D. Marchant, J. Gero, Automating code
checking for building designs, in: K. Brown, K. Hampson, P. Brandon (Eds.), Clients
Driving Construction Innovation: Moving Ideas into Practice, CRC for Construction
Innovation, Brisbane, Australia, 2006, pp. 113126.

[6] D. Conover, Development and Implementation of Automated Code Compliance
Checking in the U.S., International Code Council, 2007.
[7] SMC 2009A: automated code checking for accessibility, Solibri, http://www.
solibri.com/press-releases/solibri-model-checker-v.4.2-accessibility.html.
[8] E.A. Delis, A. Delis, Automatic re-code checking using expert-system technology,
Journal of Computing in Civil Engineering, ASCE 9 (2) (1995) 141156.
[9] C.M. Eastman, J. Lee, Y.-S. Jeong, J.-K. Lee, Implementation of automatic circulation
checking module, Georgia Tech. (project report), 2008.
[10] S.J. Fenves, Tabular decision logic for structural design, Journal of Structural
Engineering 92 (ST6) (1966) 473490.
[11] D.J. Nyman, S.J. Fenves, R.N. Wright, Restructuring study of the AISC specication,
Civil Engineering Standards, SRS 393, Department of Civil Engineering, University
of Illinois at Urbana-Champaign, Urbana-Champaign, IL, 1973.
[12] S.J. Fenves, R.N. Wright, The representation and use of design specications,
Technical Note 940, NBS, Washington, DC, 1977.
[13] D. Jain, K.H. Law, H. Karwinkler, On processing standards with predicate calculus,
Proceedings of the Sixth Conference on Computing in Civil Engineering, ASCE,
Atlanta, Georgia, 1989.
[14] W.J. Rasdorf, S. Lakmazaheri, Logic-based approach for modeling organization of
design standards, Journal of Computing in Civil Engineering 4 (2) (1990) 102123.
[15] S.J. Fenves, R.N. Wright, F.I. Stahl, K.A. Reed, Introduction to SASE: Standards
Analysis, Synthesis, and Expression, Report NBSIR 87-3513 U.S, Department of
Commerce, National Bureau of Standards, 1987.
[16] S.J. Fenves, J.H. Garrett, K.H., K.A. Reed, Computer representations of design
standards and building codes: U.S. perspective, The International Journal of
Construction Information Technology, University of Salford, U.K, 1995.
[17] S. Kerrigan, K. Law, Logic-based regulation compliance-assistance, Proceedings of
the Ninth International Conference on Articial Intelligence and Law (ICAIL 2003),
Edinburgh, Scotland, UK, June 2428 2003.
[18] F. Oxel, Life safety issues in hotel/casino occupancies, Proceedings of the 2nd
International Fire Research and Engineering Conference, Center for Fire Research,
Spring 1998.
[19] J. Wix, K. Espedokken, Building code and code checking developments in the UK
and Norway, IAI International, 2004.
[20] J.H. Garrett Jr., S.J. Fenves, A knowledge-based standards processor for structural
component design, Engineering with Computers 2 (2) (1987) 219238.
[21] C. Han, J. Kunz, K. Law, Making automated building code checking a reality, Facility
Management Journal (September/October, 1997) 2228.
[22] S. Vassileva, An approach of constructing integrated client/server framework for
operative checking of building code, Construction Information Technology 2000,
Taking the Construction Industry into the 21st Century, Reykjavik, Iceland, ISBN:
9979-9174-3-1, June 2830 2000.
[23] C. Han, J. Kunz, K. Law, Client/server framework for on-line building code
checking, Journal on Computing in Civil Engineering, ASCE 12 (4) (1998) 181194.
[24] C. Han, J. Kunz, K. Law, Building design services in a distributed architecture,
Journal of Computing in Civil Engineering, ASCE 13 (1) (1999) 1222.
[25] C. Han, J. Kunz, K. Law, Compliance Analysis for Disabled Access, Advances in
Digital Government Technology, Human Factors, and Policy, in: WilliamJ. McIver
Jr., AhmedK. Elmagarmid (Eds.), Kluwer, Boston, MA, 2002, pp. 149163.
[26] J. Robbin, Mathematical Logic: A First Course (Dover Books on Mathematics),
Dover Publicaitons, 2006.
[27] M. Bramer, Logic Programming with Prolog, Springer, NY, 2005.
[28] Omniclass, OCCS, http://www.omniclass.org.
[29] IFD: 2009 International Framework Dictionary, The Construction Specications
Institute, http://www.csinet.org/s_csi/sec.asp?CID=2446&DID=15842.
[30] GSA, BIM Guide for Spatial Program ValidationGSA BIM Guide Series 02, http://
www.gsa.gov/bim/, 2007.
[31] ICC MVD, http://www.blis-project.org/IAI-MVD/.
[32] W. Solihin, Lessons learned from experience of code-checking implementation
in Singapore, 2004 http://www.buildingsmart.com/les/u1/ned_20from_
20experience_20of_20code_checking.pdf.
[33] M. Kannala, escape route analysis based on building information models: design,
and implementation, M.S. thesis of Department of Computer Science and
Engineering,Helsinki University of Technology, 2005.
[34] D. Schenk, et al., EXPRESS Language 1.0 Reference Manual: External Representation
of Product Denition Data, ISO TC184/SC4/WG5, Document N14 19, April 1991.
[35] V. Bazjanac, Model based cost and energy performance estimation during
schematic design, CIB-W78, 22nd Conference on Information Technology in
Construction, vol. 304, July 1921 2005, pp. 677688.
1033
[36] SMC: Solibri Model Checker, Solibri, http://www.solibri.com.

[37] J. Plume, J. Mitchell, Collaborative design using a shared IFC building model
learning from experience, Automation in Construction 16 (1) (2007) 2836.
[38] .K. Lie, Use of dRofus in the HITOS project, Project report, 2008.
[39] J. Sjgren, BuildingSMARTa smart way for implementation of standards,
buildingSMART presentation slides, European technical data event, 2007.
[40] EDM ModelChecker: http://www.epmtech.jotne.com/index.php?id=512200.
[41] ISO TC184/SC4, Industrial automation systems and integrationProduct data
representation and exchangeISO 10303-11: Description Methods: The EXPRESS
Language Reference Manual, ISO Central Secretariat, 1997.
[42] ISO TC184/SC4, Industrial automation systems and integrationProduct data
representation and exchangeISO 10303-14: Description Methods: The EXPRESS-X
Language Reference Manual, ISO Central Secretariat, 1999.
[43] EDM: EXPRESS Data Manager, EPM Technology, http://www.epmtech.jotne.com.
[44] novaCITYNETS Implementing IFC-Automatic code checking(e-plancheck) Pte,
http://www.novacitynets.com.
[45] Selvaag Group: http://www.selvaag.no/en/aboutselvaag/Sider/default.aspx.
[46] J. Sjgren, Governmental and industry experience in Norway, buildingSMART
Norwegian Experiences presentation slides, 2005.
[47] SINTEF 2009: http://www.sintef.no/Home/About-us/.
[48] Open CASCADE S.A.S, Open CASCADE Reference Documentation, http://www.
opencascade.org., 2006.
[49] J. Corney, T. Lim, 3D Modeling with ACIS, Saxe-Coburg Publications1-874672-14-8,
2001.
[50] K. Lindberg, M.A.T.L, Development of a new ICT-system for registration and
assessment of accessibility to public buildings, Property Management, Statsbygg,
BAS Conference, November 17 2006.
[51] Norwegian Statsbygg: http://www.statsbygg.no/English/.
[52] E. Eberg, T. Heieraas, J. Olsen, S.H. Eidissen, S. Eriksen, K.H. Kristensen, O.
Christoffersen, M.A.T. L, F. Mohus, Experiences in development and use of a
digital Building Information Model (BIM) according to IFC standards from the
building project of Troms University College (HITOS) after completed full
conceptual design phase, Report by Statsbygg, 2006.
[53] Nosyko AS's dRofus User Manual, dRofus. http://www.drofus.no.
[54] ISO/CD21542, Building constructionAccessibility and usability of built environment, ISO, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.
htm?csnumber=50498.
[55] ICC/ANSI A117.1-2003, Accessible and Useable Buildings and Facilities, ANSI,
http://webstore.ansi.org/RecordDetail.aspx?sku=ICC%2FANSI+A117.1-2003.
[56] L. Ding, R. Drogemuller, J. Jupp, M. Rosenman, J. Gero, Automated Code Checking,
Clients Driving Innovation International Conference, CRC for Construction
Innovation, Australia, 2004.
[57] IECC, 2003 ICC International Electrical Conservation Code, ICC, 2003.
[58] ICC: International Code Council, http://www2.iccsafe.org/io/smartcodes/demo.cfm.
[59] AEC3, International Code Council, http://www.aec3.com/5/5_013_ICC.htm.
[60] GSA BIM Program: http://www.gsa.gov/bim.
[61] GSA, PBS Business Assignment Guide, 2005.
[62] ANSI/BOMA Z65.1-1996: Standard Method for Measuring Floor Area in Ofce
Buildings, BOMA: Building Owners and Managers Association International, 1996.
[63] U.S. Courts Design Guide, Administrative Ofce of the U.S. Courts, Space and Facilities
Division, http://www.gsa.gov/Portal/gsa/ep/contentView.do?P=PME&contentId=
15102&contentType=GSA_DOCUMENT, 2007.
[64] GSA, BIM Guide for Circulation and Security ValidationGSA Series 06 (draft),
2009.
[65] J.-K. Lee, C.M. Eastman, J. Lee, M. Kannala, Computing walking distances within
buildings based on the universal circulation Network, Environment and Planning
B. in press.
[66] NIBS, United States National Building Information Modeling Standard Version 1
Part 1: Overview, Principles, and Methodologies, 2007.
[67] Singapore Civil Defense Fire Code 2002 Handbook Volume 5 Chapter 2 Diagram
2.3.5(c) http://www.scdf.gov.sg/Building_Professionals/Publications/re_code_
2002handbooks.html.
[68] L. Ding, R. Drogemuller, M. Rosenman, D. Marchant, J. Gero, Automating code
checking for building designs, in: K. Brown, K. Hampson, P. Brandon (Eds.), Clients
Driving Construction Innovation: Moving Ideas into Practice, CRC for Construction
Innovation, Brisbane, Australia, 2006, pp. 113126.

Automatic Rule-Based Checking of Building Designs

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Automatic Rule-Based Checking of Building Designs

Uploaded by

Copyright:

Available Formats

Automation in Construction 18 (2009) 10111033

Contents lists available at ScienceDirect

Automatic rule-based checking of building designs

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

Norwegian Statsbygg's design rule checking efforts . . . . . . . . . . . . . . .

Almost all efforts in automating rule checking to date have been

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

and electrical load requirements. Like all computer languages, the

3.1.2. Ontology of names and properties

In traditional computer drafting practice, the objective was is to lay

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

circulation space or use space. Some of these limitations would

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

reduction in the correction iteration cycles. These capabilities will not

maps it to an internal structure facilitating access and processing. It

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

several by Statsbygg and by the National Ofce of Building Technology

public housing and vehicle parking. The building service module

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

architects, engineers, surveyors and other professionals, are reported to

platform [39,50]. We found two salient design rule checking features in

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

universal layout, service lifetime etc) based on increased awareness/

Fig. 3. System architecture of CORENET project (With permission of novaCITYNETS).

5.2.1. Spatial requirement checking

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

Fig. 4. Process overview of the rule checking in the HITOS Project.

one type of rule (spatial areas). dRofus supports IfcZone, IfcSpace

deals with accessibility rule checking system as described in the

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

running in Solibri Model Checker. SMC's accessibility rules are derived

Rules for specic

Required oor coverings and related

Floor, wall coverings

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

5.2.5. Rule reporting

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

highlighting SMC results/issues in the BIM/CAD application. Also SMC

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

Fig. 11. Graphic display of the check results [68].

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

Fig. 12. The interactive report page [68].

SMARTcodes provides for the mapping of written building codes into

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

Fig. 13. The print-friendly report page [68].

Fig. 14 provides an overview of the SMARTcode system. Manual

provided with graphical images about elements of the building model

Fig. 14. Framework of model checking system based on SMARTcodes.

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

checking and reporting tasks. Building codes are created from

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

Implementation of the circulation requirements involves the

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

Fig. 18. Spatial program validation results.

5.5.6. Rule reporting

Space names should be dened on the basis of Space naming

Violated circulation routes are visualized showing the graph traversal

C. Eastman et al. / Automation in Construction 18 (2009) 10111033

Fig. 20. Reporting.

on a derived graph based on the room connectivity, space names and

structure and completeness, for interfacing with other applications. In