-
3. The rule checking process . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . 1013. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 1013
s and pethod. . . .. . .
. . . .opertiesls . . .d modet rule pa
3.3.2. Management of view submissions . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1015
Automation in Construction 18 (2009) 10111033
Contents lists available at ScienceDirect
Automation in Construction3.4. Rule check reporting . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 10153.4.1. Rule instance graphical
reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 10153.4.2. Reference to source rule .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 1015
3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10164. Rule-based platforms . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . 10165. Survey of rule-based building model checkers . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 1017
5.1. CORENET-Singapore . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10175.1.1. Rule interpretation . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10175.1.2. Building model preparation . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1017
5.1.3. Rule execution . . . . .5.1.4. Rule reporting . . . .
.5.1.5. CORENET summary . . .
Corresponding author.E-mail address:
[email protected] (C.
0926-5805/$ see front matter 2009 Elsevier B.V.
Aldoi:10.1016/j.autcon.2009.07.002. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1015-checking . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 10153.3. Rule execution . . . . . .
. . .3.3.1. Model view syntactic pre3.1.3. Implementation m3.1.4.
Language driven
3.2. Building model preparation3.2.1. Model views . .3.2.2.
Derive implicit pr3.2.3. Derive new mode3.2.4.
Performance-base3.2.5. Visibility of layouroperties . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 1014. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 1014. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1014. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 1014. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1014using enhanced objects . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 1014. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1015l and integrated analysis . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 1015rameters . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10153.1.1. Logic-based interp3.1.2. Ontology of name. . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 1013
3.1. Rule interpretation . . . . . . . . . . . . . . . . . . .
.
retation1. Introduction . . . . . . . . . . . . . . . . . . . .
. . . . . . .2. History of rule checking research . . . . . . . . .
. . . . . . . .Review
Automatic rule-based checking of building designs
C. Eastman , Jae-min Lee, Yeon-suk Jeong, Jin-kook LeeCollege of
Architecture, Georgia Institute of Technology, United States
a b s t r a c ta r t i c l e i n f o
Article history:Accepted 30 July 2009
Keywords:BIMDesign assessmentBuilding codesDesign guides
This paper surveys rule checking systems that assess building
designs according to various criteria. Weexamine ve major
industrial efforts in detail, all relying on IFC building models as
input. The functionalcapabilities of a rule checking system are
organized into four stages; these functional criteria provide
aframework for comparisons of the ve systems. The review assesses
both the technology and structure ofbuilding design rule checking,
as an assessment of this new emerging eld. The development of
rulechecking systems for building is very young and only limited
user experience is presented. The survey laysout a framework for
considering research needed for this area to mature.
2009 Elsevier B.V. All rights reserved.
Contents
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . 1012
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . 1013
j ourna l homepage: www.e lsev ie r.com/ locate /autcon. . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 1017
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 1017
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 1017
Eastman).
l rights reserved.
-
..
.
.
.
.
.ati....................tem...
1. Introduction Almost all efforts in automating rule checking
to date have been
1012 C. Eastman et al. / Automation in Construction 18 (2009)
10111033New criteria continuously emerge in architecture, ranging
frombuilding codes and safety, to the techniques of fabrication
andassembly. Until recently, the only means to deal with this
complexand growing body of knowledge were human cognition
andorganizational review processes. Some criteria involve
computer-ized analyses (e.g. structures), but still, the details of
safety factorsand interpretation of the results have been a manual,
people-centered undertaking. The advent of computer applications
sup-porting the 3D object modeling of buildings, called
BuildingInformation Modeling (BIM), allow both automatic
parametricgeneration of designs that respond to various criteria
and theprospect of computer-interpretable models and automated
checkingof designs after they are generated [1].
Automated rule checking here is dened as software that does
notmodify a building design, but rather assesses a design on the
basis of theconguration of objects, their relations or attributes.
Rule-based systemsapply rules, constraints or conditions to a
proposed design, with resultssuch as pass, fail or warning, or
unknown for cases where theneeded data is incomplete or
missing.
While some rules can be embedded in parametric design
gen-erating systems, automated rule checking of candidate designs
areappropriate where the rules:
1. Apply across different building and spatial systems, because
theobjects and rules of generation cannot be dened
beforehand.Spatial congurations are an example.
2. Are those of public agencies, organizations or clients that
need toreview designs that are generated by an open-ended set of
designtools.
3. Where the conditions being assessed are global ones, such as
rules
applied to building code and accessibility criteria. These types
of rulechecking are required of all buildings constructed within
ajurisdiction. Since code plan checking is often a costly
bottleneckin the building delivery process, automated code reviews
have thepotential to save signicant time and cost. In this review,
weapproach rule checking systems from a perspective of
broaderpotential applicability. We expect rule-based systems to
become aclass of application that will have wide deployment in the
AECindustries:
1. For all buildingsgeneral conditions such as building codes,
at thenational, regional or municipality level of organization.
2. For particular building typesdesign guides of best practices
for abuilding type; this type of rule-base may be dened by the
clientorganization, or alternatively, as best practices within a
design orengineering rm.
3. For a specic building project: programmatic requirements for
abuilding instance, such as its space requirements, circulation
issues,ergonomic layout and special site considerations; these may
bedeveloped by the client or design rm, and the specic rules
denedas part of the program and review criteria during project
design andconstruction.
We expect to see application of rule checking systems to
movebeyond code checking to the other two levels of specicity and
even-tually to become a standard tool used throughout the building
lifecycle.
A rule-based assessment tool can be implemented for
variousplatforms, for example: (1) as an application closely tied
to a designtool, such as a plug-in, allowing checking whenever the
designerwishes. (2) or as a stand-alone application running on
desktops, inparallel to a design generating tool; (3) as a
web-based applicationthat can accept design from a variety of
sources. Each approach is5.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 innov5.3.1. Rule interpretation . . . . . . . . . . .
. . . . .5.3.2. Building model preparation . . . . . . . . . . .
.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. Building model
preparation . . . . . . . . . . . .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
sys7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . .
.
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .
. .References . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . .associated with safety, structural integrity, energy usage and
costs.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 1018
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1019
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1020
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1021
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1021
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1022
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1023on in the Australia . . . . . . . . . . . . . . . . . . . . .
. . . 1023. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . 1023. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 1023. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 1024. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 1024. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 1024. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 1024. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 1025. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 1026. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 1026. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 1027. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 1027. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 1027. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 1027. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 1028. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 1028. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 1030. . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 1030. . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 1031. . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 1031. . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 1032. . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 1032
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1032
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1032
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1032desirable for some uses. Current efforts have focused on the
web-
-
1013C. Eastman et al. / Automation in Construction 18 (2009)
10111033based approach but we look forward to the development of
simple-to-develop rule-based systems that encourage implementation
of theother types.
The only neutral model representation for describing a building
forrule checking is Industry Foundation Classes (IFC) [2]. This is
a designtool independent and neutral datamodel representation
supported bymost BIM design tools, and is being used as the
building modelrepresentation in all the efforts reviewed here. Rule
checking usingnative application data models will probably also
emerge.
There has been a long historical interest in structuring
buildingcodes into a form amenable for machine interpretation and
applica-tion. Efforts to implement production rule-based systems
came later,as supportinghardware andweb-accessmatured. The initial
effortwasled by Singapore, who started considering code checking on
2Ddrawings in 1995. It then switched and started the CORENET
Systemworkingwith IFC buildingmodels in 1998 [3]. More recent
efforts havebeen initiated in Norway [4] and Australia [5]. A U.S.
effort also hasbeen initiated called SmartCODES [6]. There are also
several researchimplementations of rules to assess accessibility
for special populations[7] and forre codes [8]. TheGSA andUSCourts
has recently supporteddevelopment of design rules checking of
federal courthouses, whichis an early example of rule checking
applied for automating designguides [9].
This paper reviews these ve efforts to automate rule checking
inbuildings, focusing primarily on building code reviews. These
areCORENET, the HITOS project by Norwegian Statsbygg, the effort by
theAustralian Building Codes Board, the International Code Council
in theUS. We also review the General Services Administration
effortinvolving building type design rule checking, which has
supportedthe efforts of the authors.
Many other systems applications have limited purpose
targetedrule checking capabilities: such as for checking room areas
or forspatial conict checking. We exclude these, focusing on
systems withpotentially general rule checking capabilities.
We start by reviewing early research in the area, then outline
ageneral functional architecture of services that all rule
checkingsystems need to provide. Using this structure, we then
review themain institutional efforts being carried out in several
parts of theworld. Last, we summarize the current status of efforts
and identifyareas where additional research is needed.
2. History of rule checking research
Rules and regulations arewritten bypeople and for a long
time,wereonly read and applied by people. As a result, they were
sometimesincomplete (particular conditions were not covered) or
contradictory.Their structure was often arbitrarily complex.
Improving the logicalstructure of regulatory codes was an area of
early research. Fenvesundertook initial work to structure
regulatory codes in decisiontables [10]. Later, decision trees were
applied to structural steel design[11]. Software tools were
developed to support the management ofregulations [12] in different
jurisdictions. Fenves' students followed bystructuring regulations
in a predicate logic structure [13,14]. Othersoftware was
developed, called the SASE system (Standards Analysis,Synthesis and
Expression) [15], to provide a comprehensive structurefor families
of related codes (as exists across themanyUS jurisdictions).An
important review and critique of these early efforts is provided
in[16]. Given the predicate logic structure, Kerrigan developed
theREGNET application to determine for given building conditions
theapplicability for various codes, based on a question-and-answer
userinterface [17]. These early efforts laid out the logical
structure of codes,from a rule-based and organizational
perspective. They did not addressin a signicant way automated
application of rules to a digital buildingrepresentation.
In parallel, various efforts were undertaken to apply rule
checking
to building representations, using specially coded drawing
structuresor textual descriptions. These were applied to re escape
and eva-cuation [18], other forms of prescriptive requirements and
perfor-mance-based standards [19]. Development of rule-based
systems forbuildingmodels began exploration in the late 1980s [20].
In the 1990s,the development of the Industry Foundation Classes led
to earlyresearch for using this building model schema for building
codechecking. Han and others laid out general opportunities and a
clientserver approach [21,22]. Han identied the need for multiple
objectviews for different types of rule checking [23]. They later
developed asimulation approach of ADAwheelchair 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
haveextracted a necessary structure for implementing a functionally
completerule checking and reporting system. Rule checking can be
broadlystructured into four stages: (1) rule interpretation and
logical structuringof rules for their application; (2) building
model preparation, where thenecessary information required for
checking is prepared; (3) the ruleexecution phase, which carries
out the checking, and (4) the reporting ofthe checking
results.Withineachof thesephases,we identify a setofmoredetailed
functional issues.
Within the rst three phases, shared conventions must
existregarding the coded rules so they match with the properties
and struc-tures that are embedded in the buildingmodel. Information
availabilityfor rule checking can be addressed in somemixture of
three strategies:
1. Requiring the designer to explicitly provide information in
thebuilding model needed for checking. While this is natural for
someaspects (door and window locations and sizes), others are
derivedfrom more basic information and rely on fallible human
judgmentthat are current causes of error (minimum headroom in
stairway,wheelchair navigation in a restroom).
2. Having the computer derive new data or generate model
viewsthat explicitly derive the lacking data. Examples where
computerprocessing can extract implicit attributes include the
examples ofheadroom and wheelchair access in #1 above and re exit
pathsand their lengths.
3. Some important design rules apply to properties that
requirecomplex simulations or analyses, such as for structural
integrity orenergy usage. These require the application of an
analysis model toderive the complex information, then to apply the
rules to theanalytically derived data.
As can be seen, rule checking implementation approaches
involvemany trade-offs between imposing documentation work on
thedesigner and imposing stronger inference capabilities within the
rulechecking software. These issues arise continuously throughout
thedesign and implementation of rule checking systems.
3.1. Rule interpretation
Rules for building design are rst dened by people and
representedin human language formats, typically written text,
tables and possiblyequations. In building codes, these rules have
legal status. How can theinterpretation of these rules into
amachine processable format be done,in amanner that the
implementation canbevalidated as consistentwiththe written rule? In
some rule checking implementations, the processrelies on the
programmer's interpretation and translation of thewrittenrules into
computer code. In other cases, the logic of thehuman
languagestatements is formally interpreted and then translated.
3.1.1. Logic-based interpretationA 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 C. Eastman et al. / Automation in Construction 18 (2009)
10111033formalize rules dened by people [26]. In logic, a predicate
is a well-dened term (or function) that can be evaluated to TRUE or
FALSE(or undened, if terms are not dened). Predicate logic also
dealswith quantication, whether a statement applies either to ALL
in-stances where a condition arises, or that it applies at least to
one of theinstancesthat the condition EXISTS. There are well
developed generaltechniques for translating logical assertions into
executable statements,most importantly the Prolog computer language
[27]. The domain ofbuildings and the interpretation of where rules
apply and how manyinstances of the rule need to be applied aremajor
issues. In this domain,rules are typically deeply nested, based on
many contextual conditions,for example based on type of
construction, earthquake zone, andconstruction details. Other rules
are general and apply to all conditionsof an occurrence, which can
occur in the thousands.
3.1.2. Ontology of names and propertiesRule translation
typically has two aspects: (1) the condition or
context where the rule applies, (2) the properties uponwhich the
ruleapplies. The rst step might identify potential re exit paths,
forexample, and the second step would then check the width and
lengthof the identied paths. These steps rely on explicit space
classica-tions (circulation space), and dened methods for measuring
lengthand width. These classications and properties are now being
renedfrom earlier classications and expanded. Omniclass [28] is a
NorthAmerican effort integrated with ISO and European efforts to
developbuilding classications in support of digital modeling and
exchange. Itis providing the space, process, actors, building
objects and othergeneral classes of information. Omniclass works in
parallel with but isdistinct from the International Framework for
Dictionaries (IFD) [29]which provides explicit denitions of
building components, theirproperties for different uses, and in
different languages. The rules thatcarry out the object, attributes
or relation assessment are the criticalprocessing end of rule
interpretation and rely heavily on standardsfrom Omniclass and
IFD.
3.1.3. Implementation methodThe contextual conditions and tests
can be implemented in
different ways:
1. Computer language encoded rules: The most
straightforwardimplementation structure for rules is computer code,
using param-eterization and branching. Rules encoded in computer
languagerequire high-level of expertise to dene, write andmaintain.
Whilerules written in computer code may be used in dedicated
appli-cations, they are not likely to support widespread use.
2. Parametric tables: Parameters and, branches and other
logicalconstructs can be written to dene a class of rules,
instantiated by atable of parameters. Dening the parameters
provides an easy butlimited method for dening new rules.
Quantication has beenincluded (ALL or EXISTS) in some parametric
tables. Tablesfacilitate easy denition of rules for different
contexts by userswithout the need for computer programming. They
are limited bythe range of conditions they can represent.
Parametric tables are anintermediate step between ease of use and
the generality andpower to dene and implement any relevant
rule.
3.1.4. Language drivenA longer term implementation method of
building rule checking is
their implementation in one or more rule denition languages.
Twodifferent styles of language can be envisioned: (1) predicate
logic-based, facilitating the conversion of human language rules
into logicalpropositions that can be executed, (2) domain-oriented,
where theterms in the language allow easy denition of context for
ruleapplication and the conditions they test. It seems likely that
a family ofrelated languages will be required for different domains
within build-
ing, such as for structural analysis, room properties and
accessibility,and electrical load requirements. Like all computer
languages, thebackend implementation could be re-targeted to
operate on differentbuilding model representations, such as the
native building models ofthe different BIM tools, and thus not
limited to IFC building models. Ina language, the rules written
would be portable, in the same way thatjava, C or SQL programs are
portable to different platform environ-ments. This allows running
the same rules on a code checking serverand also embedded in a
design tool. The other benet of a language isthat, if
well-designed, it is able to depict an unlimited range of
rules,including unlimited nested conditions and branching of
alternativecontexts within a specied domain. While examples exist
for the rsttwo types of rule representation, no language for
building model rulechecking is known to have been proposed.
3.2. Building model preparation
In traditional computer drafting practice, the objectivewas is
to layout 2D drawing representations that people could interpret
forbuilding information. The primary requirement in this earlier
processwas that the drawings must look visually correct and to
contain thevaried information needed for rule checking. Today, with
object-basedbuilding models, the requirements have changed. Objects
beingchecked now have a type and properties. For example, an object
thatlooks like a set of appropriately spaced stair treads but dened
assmall slabs will not be interpreted as a stair, unless it is
converted to astair object, with stair properties such as riser,
tread, run, etc. Thus therequirements of a building model adequate
for rule checking arestricter than earlier drafting requirements.
Architects and othersdening building models that will be used for
rule checking mustprepare them so that the models provide the
information needed inwell-dened agreed upon structures. The GSA BIM
Guides [30]provide initial examples of modeling requirements for
simple rulechecking. This information must then be properly encoded
in IFC bythe 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 notconsistent with the building model arises. The
preferred solution is toautomatically derive required rule checking
data wherever possible,either within the design program or the rule
checking one.
3.2.1. Model viewsBuilding models involve large datasets, even
for only medium-
scale buildings. And the models built to date do not typically
includethe level of detail needed for building code or other types
of rulechecking. Han et al. proposed [23] that separate model views
be usedto both derive the needed data required for a specic type of
rulechecking and to extract subsets of an overall building model to
allowmore efcient processing. All efforts to date have followed
thisapproach, if only to partition the development effort. Denition
ofsuch model views goes hand-in-hand with the preparation of
rulechecking functions. Some rule checking involves implicit
propertiessuch as the ratio of glazing to oor area in rooms, the
narrowest widthin a passageway and accessibility for the
handicapped in restrooms.Rule checking can be built upon different
types of model views inresponse to these issues. Initial
development of a model view for codechecking some sections of codes
has been developed by thecontractors working with the International
Code Council [31].
3.2.2. Derive implicit properties using enhanced objectsIn
response to these issues, some rule checking efforts have
devel-
oped enhanced building objects implemented using
object-orientedprogramming principles. The expanded objects include
methodsto derive new information and compute complex properties
[32].This approach works well for most cases. It may not be
sufcientfor properties that are part of complex spatial
congurations made
up of multiple nested and bounding objects, such as properties
of
-
1015C. Eastman et al. / Automation in Construction 18 (2009)
10111033circulation space or use space. Some of these limitations
woulddisappear if fully and accurately dened space objects in
buildingscould be derived, allowing a rich set of assessments of
spaces to beundertaken.
3.2.3. Derive new modelsOther efforts automatically derive a new
building model to facilitate
assessment of certain implicit properties or relations. An
exampleis the derivation of a graph of circulation paths from a
building'sspatial layout to check accessibility for the handicapped
and forre exits [33]. The derived model can carry attributes
designatingwalking distances between spaces and other spatial
propertiesneeded for circulation assessment. The derived views and
attributesallow checking of properties that would be very complex
on a stan-dard building model.
3.2.4. Performance-based model and integrated analysisSome of
the properties of a design being checked are performance-
based, requiring analysis or simulations for their derivation.
Structuralanalyses are required for many buildings and energy
analysis isbecoming more common. Performance-based rules generally
requirea specially derived model view, with its own geometry,
material orother parameters properties and assumed loads, as input
for execut-ing the analysis/simulation. The analysis results are
combined withthemodeling assumptions to determine the adequacy of
the rules.Weare not aware of any system today that integrates these
different stepsinto an automated performance review.
3.2.5. Visibility of layout rule parametersWhile it is possible
to check every instance of some type of layout,
such as stud or oor joist spacing, current practice in drawing
layout isto denote the generation rule, e.g., 24 studs at 16" O.C.
The layoutrule parameters on a drawing are assessed, not the
graphical layoutitself, for these aspects. These denotations
eliminate much possiblyredundant checking. Layout parameters are
important in checkingwherever a simple rule has been dened for
generating a layout. It iseasier to check the parameters in the
layout rule than every instanceof its application. Such layout
rules can be explicitly entered in thebuilding model as attributes;
because the IFC is dened using theEXPRESS 1.0 Language [34] and
EXPRESS 1.0. cannot represent layoutgeneration rules, alternative
conventions documenting the layoutrules is required.
3.3. Rule execution
The execution phase brings together the prepared building
modelwith the rules that apply to it. Execution issues largely deal
with themanagement of this the review process.
3.3.1. Model view syntactic pre-checkingPrior 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 morelikely, for limited model views, for checking a part of
the rule set. If newmodel views are derived, then the pre-checking
is carried out prior tothe derivation. Pre-checking needs to be
undertaken to validate that thedata 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
consistentwith functions, (2) the functions have been prepared that
match thecapabilities and information available in the building
model.
3.3.2. Management of view submissionsModular 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-dinate and oversee the application of the multiple rule
modules andtheir results. Management will have to address at least
two issues:
Completeness of rule checking: If views are separately submitted
toassess different types of rules, then the selection of the
appropriaterule subset is required. As the different rule sets are
checked, thecompleteness of the entire rule checking process must
be managed.
Model version consistency: Methods for model version
consistencyalso must be put in place that determine that all model
views submit-ted for assessment form a single integrated design,
not one that hasbeen varied inconsistently so as to pass each of
the subset require-ments. This issue is complicated if the
assessment is iterated withpartial changes.
Because of incremental implementation and rollout, it is
anticipatedthat code reviews will be a mixture of automated and
manual checkingfor many years. The development of rule processing
environments is inits early stages of development and will deserve
signicant attention asthe eld matures. These issues may not apply
for design guide andproject-level rule checking.
3.4. Rule check reporting
The last step in rule checking reports the results. Design
conditionsthat are satisfactorythose that PASSneed to be reported
as part of anaudit trial that validates the completenessof the
check. One can envisionvarious situations where the identication of
instance conditions thatpass a rule would provide valuable
knowledge, for example a specialcase earthquake zone structural
test.
Rules are dened at the implementation level according to the
objectclass, group or conguration they apply to. For a particular
building, asingle rulemay apply to hundreds or even thousands of
instances of theobject class within the building, e.g. all doors or
windows. Each of theseinstances needs to be discriminated in the
testing and reporting. Forexample, if a rule applies to all
hospital rooms and the rooms vary, thenall hospital rooms will have
to be tested and results reported.
3.4.1. Rule instance graphical reportingWhile buildings have
clear labels regarding oor levels and spaces,
many of the contexts that must be checked address conditions
thathave no naming scheme. For example, the framing conditions
onsome corner in the middle of the buildingmay not satisfy some
rule. Asimple and intuitive means to identify these is by reference
to locationin project coordinates, and placing the viewing camera
at a locationdepicting the issue. This is typically done for
spatial conict testing[36,37]. Examples of this approach show that
it is an effective way tocommunicate problems to people submitting
the building models forreview.
3.4.2. Reference to source ruleAssociated with the error
location must be the applicable rulethe
condition checked at the given location. This requires carrying
out thereverse mapping from the rule interpretation task, mapping
back tothe original textual description of the rule. The local
instanceparameters and the text dening the rule violated are the
basics forreporting. More elaborate reporting, with specic text
explaining theerror will evolve, describing how the rule might
fail, with parametersfor the relevant instance codes, or possible
actions to correct the error.
Different assessment reports may be required for the
testingorganization and the submitter. For example, the testing
agency mayneed to know assumptions of the testing for later
possible auditconditions that the design submitter may not be
interested in.
At some point in the future, rule checking may have
extendedreporting capabilities. For example, the reporting could be
by xmlback to the host application and model, allowing quick
correction.Issue management systems can support tracking and acting
on errorsto manage corrections. Also, rule systems implemented
locally
could do the error reporting in the authoring tool, facilitating
much
-
reduction in the correction iteration cycles. These capabilities
will notbe available until reliability of rule checking systems is
achieved.
3.5. Summary
The four steps on rule checking and the associated processes
andissues identied within them are those encountered by the authors
intheir own work and observed in the work of others. They outline
thesoftware processes needed for a working rule-based checking
systemand in some cases identify the options that can be taken.
These fourclasses of capabilities are diagrammed in Fig. 1, with
the various aspectsof the four capabilities identied within the
category boxes. As devel-opment expertise in rule checking systems
grows,we expect new issuesto emerge. These functional steps are
used in the succeeding sections toreview the current implementation
efforts.
4. Rule-based platforms
Research development of rule-based systems for building
modelsbegan two decades ago [20]. During the intervening time,
buildingmodels and the methods for rule checking have been
developed, buteffective rule checking systems are just beginning to
becomeavailable. The technology is still young and quickly
evolving. Rulechecking systems are large applications and require
signicantsoftware utilities to provide the functionality we have
outlined. Theearliest efforts had to develop these capabilities
from scratch, whilelater efforts have been able to rely on
intermediate platforms thatprovide some of the needed functionally.
We are aware of fourdifferent software platforms that have been
developed to supportimplementation aspects of rule checking
systems, all applying rules toIFC building model data.
maps it to an internal structure facilitating access and
processing. Itincludes a variety of built-in functions:
a library of capabilities for pre-checking a model, such as
shapeoverlaps, name and attribute conventions, object existence
andothers, 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
accessibil-ity 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 andreporting format suitable
for design reviews using the free SolibriModel Viewer.
Rules can be parametrically varied through table-set control
pa-rameters. However, entirely new rules are added in java using
theSMC application programming interface (API). The API interface
is notpublicly available, restricting the rules to be checked to
those suppliedby Solibri.
Jotne EDModelChecker: Several code checking efforts reported
hereused the Jotne EDModelChecker [40] as part of their
implementation.EDM provides an object database and supports the
open developmentof rule checking using the EXPRESS language, which
is the language inwhich the IFC model schema is written. New model
views can bedeveloped using EXPRESS and EXPRESS-X, which is a
language formapping instance data from one EXPRESS schema to
another andsupports extensive queries and reports [41,42]. These
facilities makeEDM open to sophisticated user extensions. EDM also
provides textualreporting and server services. It is supported by
EDMModel Server, an
riva
1016 C. Eastman et al. / Automation in Construction 18 (2009)
10111033Solibri Model Checker: Three of the development efforts
reportedhere utilize the Solibri Model Checker (SMC) platform [36].
SMC is ajava-based desktop platform application that reads an IFC
model and
Fig. 1. The four classes of functionality a rule checking system
should support: Rule de
internal capabilities.object-based backend database server, that
allows EDM to deal withlarge building models and potentially
several of them at a time [43].EDM has been applied to several
projects not reported here, including
tion, building model preparation, rule execution, and rule
reporting, and their needed
-
1017C. Eastman et al. / Automation in Construction 18 (2009)
10111033several by Statsbygg and by the National Ofce of Building
Technologyand Administration (BE) in Norway [39].
FORNAX: The rst large effort in building rules checking,
theSingapore CORENET effort developed its own platform,
calledFORNAX, developed by novaCITYNETS Pte. Ltd on top of EDM
ModelChecker [44]. FORNAXt is a C++ object library that derives new
dataand generates extended views of IFC data. FORNAX objects carry
rulesfor assessing themselves, providing good object-based
modularity.FORNAX has been reviewed by a number of other building
code effortsas a possible platform [3] including the Norwegian
Selvaag Group,who applied it to re exit assessment [45,46].
SMARTcodes: Anewplatform for rule checking is
beingdevelopedbyICC, called SMARTcodes. It providesmethods of
translation fromwrittenlanguage rules to computer code, using a
dictionary of domain-specicterms and semi-formal mapping methods
[6]. SMARTcodes alsoprovides methods to access the relevant data in
an IFC model andreport on results. SMARTcodes has been developed by
AEC3 and DigitalAlchemy.
We expect each of these platforms to grow in functionality, as
eachof the efforts they support mature. A joint feasibility study
that isinitiated by Standards Norway (SN), BE, and Statsbyggwas
carried outin the rst half of 2009 by research organization SINTEF
to assess andrecommend open platforms for describing rules from
such sources asstandards, building regulations and client policy
documents in anunambiguous form suitable for computer code
implementation [47].The English version report will be issued late
June 2009. The project isfocusingmore on rule derivation and
buildingmodel preparation thanon actual software, though a short
survey of commercial rule checkingsoftware may be included.
5. Survey of rule-based building model checkers
In this section, we summarize the implementation efforts
undertak-en to date on rule checking systems.
Much of the currentwork has been presented inworking reports
andconference presentations. They have typically addressed only
aspects oftheir overall system. Also, almost all systemsare still
in development andaspects of thework have not yet beenmade public
(and possibly not yetdeveloped); the work is in-progress. Based on
the available reporting,and in some cases, personal communication,
we have tried to interpretthe 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 toprovide high-level
characterization of the systems and to compare anddifferentiate the
various efforts. We are also interested in any newconcepts or
developments not addressed in our basic denitions above.
Each of the ve systems is summarized in Table 1. The
non-emptycells are those for which we have information and report
on them inthis section. All of the efforts are incomplete and thus
our reportreects 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 productioncodecheckingeffort initiated
in1995bySingapore'sMinistry ofNationalDevelopment. It is being
implemented by the Singapore Building andConstruction Authority. It
consists of three modules for the DesignPhase: CORENET
e-Submission, CORENET e-PlanCheck and CORENETe-Info. e-Submission
tracks building permit actions and e-Info providesadvisory
information for various construction-related departments.
Ourinterest here is e-PlanCheck. It initially undertook development
toworkusing electronic drawings, but switched in September 1998 to
operateon IFC building model data. This project aims to cover
building codechecks onbuildingplans (IBP) andcode compliance for
building services(IBS). Plan checking currently includes rules on
dealing with building
control, barrier free access, re code, environmental health,
household,public housing and vehicle parking. The building service
moduleincludes rules on electrical, re alarm system, re sprinkler
system,raising main and re hydrant system, ventilation, sanitary,
plumbingand drainage system, surfacewater drainage, gas pipe system
andwaterservices. It is the most mature of the reviewed
efforts.
5.1.1. Rule interpretationCurrently CORENET rules are hard coded
in computer program-
ming language. Mapping of the IFC schema for implementation of
rulechecking is a big issue for automatic building code checking.
CORENETaddressed this issue in their project presentation material
[32] anddeveloped semantic objects in the FORNAX library that
extend the IFCSchema to capture needed building code information
and to facilitatethe implementation process. FORNAX is object-based
and bothinvolves 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 preparationIn order to dene and check the
extended properties for certain
entities, the CORENET system has the FORNAX interface and
checkingmodule. The FORNAX schema contains objects which extend IFC
infor-mation to provide that needed for checking certain building
codes. EachFORNAX object also has diverse functions to retrieve
required proper-ties from IFC data. Fig. 2 shows an example of
FORNAX object and itsfunctionsExistStaircaseShaft.
By using the FORNAX objects, a programmer does not need
todevelop algorithms for retrieving required information from IFC
data.Simply by adopting FORNAX objects and their member functions,
a rulewritten in natural language can be interpreted to
programminglanguage methods and applied.
FORNAX objects are dened to capture specic rule semantics.Thus
the objects and their functions retrieve attributes from theobject,
depending on the type of rules. For example, objects andattributes
for hospital design are different from those for airportdesign; a
different set of FORNAX objects and their functions are usedfor
retrieving attributes in different building types. FORNAX uses
theOpen CASCADE [48] and ACIS solid kernels [49] as geometry
enginesand services for retrieving and structuring required data
from an IFCbuilding model. Fig. 3. diagrams the system architecture
of CORENETbased on FORNAXwhichwas developed by novaCITYNETS Pte.
Ltd. forthe Singapore Building and Construction Authority [44].
5.1.3. Rule executionCORENET implements rules by using
properties and functions
dened in and accessed through FORNAX objects. No information
wasobtained regarding model validation and pre-checking, dealing
withthe execution completeness issues or combinatorics, view
manage-ment and incremental testing.
5.1.4. Rule reportingE-plan check has a capability to report
checking results through a
website. It generates the checking report with reference to the
sourcerule it applied in checking. E-plan check supports diverse
reportingformats such as HTML in the web browser, Word or PDF
format andalso a graphic format for the FORNAX viewer.
5.1.5. CORENET summaryThe Singapore effort in building code
checkingwas the earliest and is
currently the farthest along. It is beingusedproductively
todayandoffersexamples of how such efforts may be undertaken.
CORENET states that92% of rules in IBP and 77% of rules in IBS are
currently covered by the
CORENET systemas of 2008. Andmore than 2500 rms, which
include
-
1018 C. Eastman et al. / Automation in Construction 18 (2009)
10111033Table 1Overview of rule checking systems.architects,
engineers, surveyors and other professionals, are reported tobe
using CORENET for submitting plans to the Singapore government.
5.2. Norwegian Statsbygg's design rule checking efforts
European countries have exploredmultiple paths to take
advantageof BIM, and in automated design rule checking, using
specic projects astests. The Singapore CORENET e-PlanCheck check
system was tested inboth the SelvaagGroup's Munkerudhousing
projectfor checking thebuilding distance/height/utilization, and
the Akershus UniversityHospital (AHUS) project for evacuation
related rules [39,46]. Thesewere early Norwegian efforts on
Norwegian IFC-based BIM projects. Inorder to support variousdesign
rules for theprojects,multipleplatformshave been experimentally
adopted: e-PlanCheck, SMC, dRofus, EDMModel Server and Checker,
etc. BecauseNorwegian design rule checkingsystems have been
realized based on actual building projects usingmultiple platforms,
in this section we review their efforts based on arepresentative
Norwegian BIM project for Statsbygg named HITOS(localized acronym
for Troms University College), rather than a single
a SMC supports computation of additional geometry, such as door
swing arcs, wheel chairplatform [39,50]. We found two salient
design rule checking features intheHITOSproject: (1) for evaluating
spatial programrequirementswithdRofus, and (2) checking building
accessibility using SMC.
The HITOS project is managed by the Statsbygg
governmentalagency. It is one of the biggest clients of the AEC/FM
industry in Norwayand undertakes research and development projects
to enhanceefciencies for planning, constructing and managing its
real estateportfolio. Its folio includes 1500 buildings in Norway
and abroad(embassies, etc.) [51]. Troms University College and
Statsbygg havebeen managing the HITOS project since late 2005, when
the programphase was concluded. Several software packages were used
in thisproject: ArchiCAD for design, ADT for structural, DDS
forMEP, Octaga formodel viewing, NOIS G-PROG for cost estimating,
Granlund Riuska forenergy simulation, Powel Gemini 3D Terrain for
terrain modeling, aswell as dRofus and SMC. All are integrated and
managed by the EDMModel Server. The project covers around 53,800 SF
of newbuildings andextensions on a 129,000 SF site. One of
Statsbygg's objectives for theproject was Contribute to increasing
the chances of theme-relatedanalyses (e.g. within LCC, energy, the
environment, re, acoustics,
turning circles, that can be used in checking rules.
-
1019C. Eastman et al. / Automation in Construction 18 (2009)
10111033universal layout, service lifetime etc) based on increased
awareness/value in building information as described in its report
[52]. Fig. 4illustrates the overview of spatial program requirement
validation,building accessibility checking, and other processes
centered on IFC-based interoperability.
Fig. 2. An example of FORNAX objectExistStaircaseShaft ad
Fig. 3. System architecture of CORENET project (With permission
of novaCITYNETS).5.2.1. Spatial requirement checkingIn the earlier
part of this paper, we described three classes of rule-
based systems: for all buildings, for particular building types,
and for aspecic building instance. In the HITOS Project, dRofus was
used forchecking spatial program requirements for individual
buildingspecic rules for several of their college buildings. The
project coversmultiple facilities managed by different teams within
a centralizedrepository. dRofus supports web-based collaboration
for each projectpopulated in the model server. dRofus is thus a
database system formanaging architectural programs,
technical/functional requirements,and equipment from early stage
planning and throughout the wholebuilding project. It addresses
structured room requirements, roomdata sheets and equipment
planning [53]. dRofus has an interface formanaging spatial data in
a hierarchical tree structure and it comparesplanned data with the
actual area from IFC model in the sameinterface. It receives
non-graphical data from different buildingmodels as they progress
but does not deal with visualization ormanipulation of building
geometry itself. For example, rooms could beadded or removed
through standardized but editable room templates.Detailed
attributes, properties and associated values can be manip-ulated
and exported through the dRofus interface. It has an interfacefor
managing spatial data in a hierarchical tree structure, and
itcompares planned data with the actual area from an IFC
buildingmodel in the same interface. dRofus does not require rule
interpre-tation in the general case, as it is a dedicated
application that manages
opted from the Singapore Civil Defense Fire Code [67].
-
one type of rule (spatial areas). dRofus supports IfcZone,
IfcSpaceentity data and several associated attributes (Fig. 5).
dRofus supports exploring the resulting spatial data
usingcommonly used document formats with more than 60
differentreport layouts. Most reporting aspects in the spatial
program revieware not specic rules but rather a report that shows
the comparisonand discrepancies between requirements and actual
space areavalues. Therefore, the Norwegian Statsbygg's column of
Table 1 only
deals with accessibility rule checking system as described in
thefollowing section.
5.2.2. Rule checking for accessible designThe other module in
the HITOS Project addresses accessibility
checking. Some of the requirements for universal design were
initiallydened in the dRofus database. Solibri involvement in the
HITOSProject is to provide a universal design assessment
application
Fig. 4. Process overview of the rule checking in the HITOS
Project.
1020 C. Eastman et al. / Automation in Construction 18 (2009)
10111033Fig. 5. dRofus handles detailed spatial data in tabular
structure, and exports them with a dummy space geometry [38].
-
instance examples: 1) accessible corridors using buffered
boundaries, 2) overlapped door
1021C. Eastman et al. / Automation in Construction 18 (2009)
10111033running in Solibri Model Checker. SMC's accessibility rules
are derivedfrom the following standards:
International ISO/CD 21542 (draft). [54] International Code
Council ICC/ANSI A117.1. [55]
SMC supports various parameterized rules derived from
thesestandards, including wheel chair turning circle, stair, ramp,
and doordimensions and clearance. The rule examples in natural
sentences areas follows:
The minimum clear passage width of a doorway shall be not
lessthan 800 mm.
Anend 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 than2100 mm.
Surface materials shall be rigid with a plane and slip
resistancesurface, in both wet and dry conditions.
The process of accessibility checking in the HITOS project
providesa good overview of SMC functionality. That is, some general
features ofSMC 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 checkingfunctionality for executing the
tests.
Fig. 6 shows an actual model of HITOS in SMC and some specic
Fig. 6. Examples of accessibility rule checking and their
visualization in SMC on buildingswing arcs, 3) not enough area for
wheelchair turning in a bathroom.checking examples. For
accessibility checking, SMC supports process-es with not only
geometric data of a single building object but alsoother associated
objects and their properties, such as surface material.
The accessibility rules basically involve building objects such
asspaces, doors, stairs, ramps, and windows. The majority of rules
dealwith the relation between these objects. Some rules dene
relationsbetween the sub-objects composing them. For example, for
checkingclear width of corridors as shown under the criteria
circulation inTable 2, several input parameters are required not
only for its oorwidth but also for other associated objects such as
columns, doors,washbowls, etc. Fig. 7 depicts some input parameters
for theserelations between different objects. Most of them are
geometryrelated issues, but some other rules deal with an object's
propertiessuch as surface materials and glare percentages as shown
in Table 2. Aspace name based ontology supports the accessibility
checking. Thatis, some specic spaces or objects are associated with
certain kind ofaccessibility rules, such as a washroom, kitchen or
storage. ThereforeSMC supports restrictions on which objects are
accessed for givenattributes by space names or locations.When a
given IFC model is prepared, SMC retrieves all the rule-associated
building objects and their geometric data. From theparameterized
rules, the system receives the mapping betweenbuilding objects and
required values coded within checking equa-tions. Also the values
for rules can be adjusted instead of using thedefault values taken
from ISO/CD 21542 [54]. This is needed whennational or other codes
vary from the ISO standard. Different rule setscan be called up to
apply to a model. Currently, however, SMC expectsthe user to manage
model views, to submit them to the computer orserver. No
information is carried across multiple rule checkingsessions for
example any changed defaults for conditions in Fig. 8.
5.2.3. Building model preparationWhen a given IFC model is
prepared, SMC retrieves all the rule-
associated building objects and their geometric data. From the
param-eterized rules, the system receives the mapping between
buildingobjects and required values coded within checking
equations. Thevalues for rules can be adjusted instead of using the
default valuestaken from ISO/CD 21542 [54]. This is needed when
national or othercodes vary from the ISO standard. Different rule
sets can be called upto apply to a model.
5.2.4. Rule executionSMC has extensive pre-checking
capabilities, as reported earlier. Dif-
ferent rule sets can be called up to apply to amodel. Currently,
it expectsthe user to manage model views, to submit them to the
computer orserver.Table 2Overview of the accessibility rule
checking in SMC: criteria, building objects, andchecking
features.
Criteria Objects Checking features
Requirements foraccessible circulation
Door Door dimensions and their swingoperation
Corridor Clear widths and wheelchairturning diameters
Stair Various requirements for risers, treads,steps, etc.
Ramp Slope, length, clear widths, etc.Rules for specicspaces
Washroom Washroom door requirements,wheelchair turning
Kitchen Wheelchair turning diameter checkingStorage Wheelchair
turning diameter checking
Windowsrequirements
Window sills Maximum sill height
Surfacesrequirements
Floor, wall coverings Required oor coverings and relatedproperty
sets
Stair, ramp surfaces Non-skid materials on surfaces
-
5.2.5. Rule reportingSMC supports textual and graphical
reporting in several document
le formats. It can also provides the severity of rule violations
in threelevels: Critical, Moderate and Low. SMC has functionality
to save check-
ing results in its own le format, but IFC export isby
designnotsupported; SMC is not intended to be a model authoring
application.However hotlinks to common BIM/CAD applications like
Graphisoft'sArchiCad and Autodesk's Architecture DeskTop (ADT) are
provided,
Fig. 7. Input parameter window of required properties for any
accessible stair (courtesy SMC).
1022 C. Eastman et al. / Automation in Construction 18 (2009)
10111033Fig. 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
SMChas no tracking functionality for reporting conditions that pass
theapplied rules. This makes it difcult to review the instances of
ruleprocessing applied to a given model.
5.2.6. SummaryThe dRofus spatial checking database addresses the
role of space
planning and facilitymanagementwithin an institutionmanaging
largeamounts of space. It relies on IFC spatial data and commercial
appli-cations linked together within the HITOS project. The
accessible designchecking in theHITOSproject is Solibri-based and
relies on functionality,found in SMC-based installations. Some
rules were developed specif-ically for this project, and co-funded
by Skanska Finland and StatsbyggNorway. The ISO-based accessibility
rule checking has been amendedand incorporated as one of the
default rulesets in the latest release ofSMC as of 2009 [7].
Statsbygg found that the IFC-based universal designchecking
implemented by Solibri could reduce by 6070% the commondesign
failures or deciencies [50].
5.3. Design check by cooperative research centre for
construction innovationin the Australia
The Cooperative Research Centre for Construction Innovation
inAustralia fundedaproject that included theCommonwealthScientic
andIndustrial Research Organization (CSIRO), University of Sydney,
BuildingCommissionVictoria, Australian Building Codes Board (ABCB)
andWoodsBagot. The Australian Building Codes Board (ABCB) on behalf
of theAustralian Government and State and Territory Government
maintainsand updates the Building Code of Australia (BCA).
In the rst stage of the project, Express DataManager (EDM) [43]
andSolibri Model Checker (SMC) [36] were reviewed in relation to
the base
functionalities required for automated code checking. The code
require-ments for accessibility, which are dened in the BCA D3,
AustralianStandard (AS) 1428.1 Design for access and mobility, were
used for aninitial feasibility assessment [56]. Because the SMC
capabilities arereviewed elsewhere, this review focuses on the EDM
capabilities, whichwas the platform the assessment later
recommended. The EDM platformwas then used in the second stage of
the project in which all of the non-administrative clauses in AS
1428.1 and BCA D3 were encoded [5].
5.3.1. Rule interpretationTheABCBEDM implementation relies on
object-oriented techniques
for its development approach. It utilizes the following
pre-implemen-tation specication structure: Description, Performance
requirements,Objects, Properties, Relationships, Domain-specic
knowledge for inter-pretation (see Fig. 9). These descriptions
provide written statementsof building codes interpretation. Then
the statements are translated(by people) into the performance
requirements in computer code. Theperformance requirements
facilitate translation into objects andrelations. In order to
handle the requirements, objects and object pro-perties are
extracted from the building information and accessed toassess the
performance requirements.
EDModelChecker uses the EXPRESS language to dene the ruleschema
[41]. The pseudo code which is relevant for interpretation
ofdomain-specic knowledge (example shown in Fig. 9) is encoded
intofunctions and rules in the EXPRESS language. Since the objects,
objectproperties and object relations utilized by the rules are all
representedby the IFC model schema, this rule schema can be clearly
dened.
5.3.2. Building model preparationWhile this structure workswell
for many aspects of code checking it
is difcult to dene checks for handling some conguration
criteria.
1023C. Eastman et al. / Automation in Construction 18 (2009)
10111033Fig. 9. Encoding example of a building code according to
IFC object-based interpretation [56].
-
Fig. 10. An illustration of the adjacency graph, where F means
false and T means true [68].
1024 C. Eastman et al. / Automation in Construction 18 (2009)
10111033Since AS 1428 requires access to the determined rather than
cal-culating path distances, a graph approach was taken (see Fig.
10).Starting at an external entrance that was accessible, the
containingspace was dened as accessible. All adjoining spaces which
hadaccessible openings into this previously checked space where
thendened as accessible. This can be applied recursively across
thebuilding model until all accessible spaces are tagged. This can
then bechecked against the need to be accessible.
5.3.3. Rule executionThe ABCB system in organized into rule
sets. It runs the chosen rule
set against the model initially as a pre-check to identify areas
withinsufcient information.
5.3.4. Rule reportingThe 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
givedetailed description of violations and building elements. An
interactivereport system is also provided to showanalysis results
for each clause orobject type selected. As shown in Fig. 11, the
report panel key gives briefinformation for analysis results
according to each clause. Interactivepage reporting allows
end-users to select the report type that theywishto view and update
the building model (see Fig. 12). A print-friendlyversion of the
report (see Fig. 13) is linked to the interactive report pageof
Fig. 12. The Design Checking system currently supports
graphicalreporting without geometric shape of building objects, but
provideswarning for designers.Fig. 11. Graphic display of5.3.5.
SummaryThe Australian code checking effort was developed in two
phases.
The CRC for Construction Innovation undertook the rst phase
inorder to assess the capabilities of current rule checking systems
andfor nding out the best approach for supporting computerization
ofAustralian Standards. Twomajor checking systemswere compared
byapplying the same building codes within the two systems. The
EDMprototype was found to offer a more exible and open
developmentenvironment, because the EDM system provides a publicly
accessibledenition language to represent building codes. However,
workingknowledge of the rule writing capabilities of the EXPRESS
languageis limited to only the small group of people who learn it
on theirown (in relation to C++ or java). After completing the
feasibilitystudy, Design Check system was developed in Phase Two
[5]. Thedevelopment method which was adopted by the feasibility
study inPhase one was applied. A graph was developed for inferring
adjacentaccessible spaces for accessibility checking. The report
system has adirect interface to the database of the building model
and providesboth an interactive report page and print-friendly
report page. 3Dgraphic view will be integrated with rule checking
system in future.
5.4. International Code Council (ICC)
The International Code Council (ICC) develops the master
buildingcode used by jurisdictions in North America. It is used to
constructcodes for residential and commercial buildings and most
institutionalbuildings. In 2006, it began supporting development of
SMARTcodes;the development being carried out by AEC3 and Digital
Alchemy.the check results [68].
-
1025C. Eastman et al. / Automation in Construction 18 (2009)
10111033SMARTcodes provides for the mapping of written building
codes intointeroperable computer-interpretable code sets. The
project fordeveloping SMARTcodes focuses on automating and
simplifyingcode compliance checking against the ICC codes and
federal, state,and locally adopted versions of the codes.
5.4.1. Rule interpretationCurrently, International Energy
Conservation Code [57] has been
implemented. The SMARTcodes uses an IECC dictionary for
denitionsof terms for objects and properties that are critical for
model checking.It provides SMARTcodes builder, which is Web-based
software tofacilitate creation of SMARTcodes. This software reduces
errors whichoccur during the interpretation of original building
codes intoSMARTcodes/it supports this by having user identify key
phrasesand their logical role, then formalizes the phrase using
terms from thedictionary (see Fig. 14). Written rule statements,
regulations andspecications are interpreted by the SMARTcodes
builder, using theIECC dictionary that describes properties
associated with each term,the enumeration of properties, data types
and units associated with
Fig. 12. The interactiveeach property. The dictionary is used
not only for rule interpretation,but also for communication between
SMARTcodes model checkingsystem and the IFC building model. IFC
object properties dened inthe dictionary provide model views for
rule checking. The modelviews are classied by terms and properties
of the dictionary.
ICC allows end-users to try out themodel checking system through
aweb site [58]. Currently, SMARTcodes for Solibri Model
Checker,developed by Digital Alchemy (DA), and AEC3 XABIO,
developed byAEC3 [59], support the rule-based building code
compliance checking.TheWebservices require input values such asa
buildingmodel, buildinglocation, code to be checked and model
checking system. Currently,building models are limited to several
pre-congured test modelsprovided on theweb server that satisfy
modeling requirements neededfor checking. They include a
prototypical ofce building, LawrenceBerkeley National Laboratory,
the National Association of RealtorHeadquarters building, and four
building models provided by the U.S.Coast Guard. In the future,
SMARTcodeswill support submission of end-user's building models.
Only selected portions of the 2006 IECC isavailable for
demonstration.
report page [68].
-
end
1026 C. Eastman et al. / Automation in Construction 18 (2009)
10111033Fig. 14 provides an overview of the SMARTcode system.
ManualCode Search provides ltered code text and reference
standards. The
Fig. 13. The print-fricode text provides sections and paragraphs
for feedback within a codereport. An example of code markup
relevant to the rule checkingresult report is shown in Fig. 15.
Since the checking systems areavailable on the web, the rule text
written in XML and accessedthrough the web browser. The
cross-linked regulations can be directlyaccessed through hyperlink
functions.
5.4.2. Rule reportingReporting is supported through the Model
Checking Software
(MCS) module in SMARTcodes. The software provides
end-userchecking results in several alternative document le
formats, suchas HTML, PDF, RTF, XLS and XML. Analysis results
include table-basedsummaries and graphics-based reports. The
table-based summarybriey reports whether a building model violates
codes for compli-ance checking or not. An example error report is
shown in summarycomments of Fig. 16. Also, detailed description of
violated rules is
Fig. 14. Framework of model checkinprovided with graphical
images about elements of the building model(see Fig. 17).
ly report page [68].The analysis results of code compliance
checking provide informa-tion regarding the building elements
violated. SMC provides the MCSwith identier, location, property and
geometric shape of a buildingelement on the browser. As shown in
bottom left of Fig. 16(b), thereason for non-compliance is stated.
In this case the wall (Wall.3.1is identied in SMC window) thermal
resistance of design is 0.0R,but the code requires 13.0R or
greater. Location information relevantto the wall is automatically
visualized on the graphic browser ofSMC. This information with a
textual reference of code criteria is alsospecied in the
report.
AEC3 XABIO also provides a trace back report giving a logical
stepexplanation for failure.
5.4.3. SummaryThe ICC SMARTcodes is a new approach for rule
checking system
development, taking a fairly comprehensive approach to the
overall
g system based on SMARTcodes.
-
1027C. Eastman et al. / Automation in Construction 18 (2009)
10111033checking and reporting tasks. Building codes are created
fromSMARTcodes builder in a rigorous and formal way that
facilitatessemi-automatic creation of computer-processible codes.
Currentlythe SMARTcodes model checking system focuses on available
or easilyderived properties rather than deriving auxiliary model
views oranalytical models for complex simulation for various kinds
of analyses.
5.5. General services administration design rule checking
Within General Services Administration (GSA), the Public
BuildingService (PBS) manages workspaces for the federal government
and isthe largest owner of commercial space in the United States.
The (GSA)initiated the National 3D4D-BIM Program through its PBS
Ofce ofChief Architect (OCA) in 2003 [60]. They have initiated six
BIMdemonstration projects; two programs are associated with
develop-ment of assessment tools. Assessment tools for Spatial
ProgramValidation and Automated Design Guide Checking, both
developed aspart of their 3D4D Building Information Modeling
program.
5.5.1. Spatial program validationNewbuildingdesign for GSA
follows a fairly traditional development
process, with multiple stages of concept design, design
developmentand construction documents. The tool for spatial program
validationallowsGSAproject teams to automatically assesswhether or
not theA/Elate concept design conforms to the GSA approved spatial
program, inrelation to the spatial requirements set forth by the
Congressionallyapproved housing plan and PBS Business Assignment
Guide [61]. Theserequirements include area measurements (e.g., net
or usable) andbuilding efciency measurements (e.g., fenestration
ratio). Startingin 2007, all GSA projects involving new
construction are required
Fig. 15. Textual reference to source rule texto submit BIM data
allowing spatial validation review in the nal con-cept phase.
Submitted BIM data is quickly analyzed (see Fig. 18) andreviewed by
the GSA project team.
As shown in Fig. 18, various kinds of area calculation are dened
byPBS Business Assignment Guide and ANSI/BOMA area calculationguide
[62]. These area values are automatically derived from thebuilding
model according to fairly intricate conditions specied bythe
ANSI/BOMA space denition method. Since this assessment toolis
available in the SMC browser, these area values are exported to
areporting document as a basic function. This assessment is similar
tothe dRofus assessment by Statsbygg, but uses a different method
ofarea calculation and reporting.
5.5.2. Design guide checkingGSA has also funded development of a
rule checking system for
circulation and security validation of U.S. courthouses, called
DesignAssessment Tool (DAT) and was developed by Georgia Institute
ofTechnology. For the development of DAT, circulation and security
ruleswere extracted from U.S, Courts Design Guide (CDG) [63]. CDG
denesthe criteria for federal courthouse design, based on best
practices gainedthrough the US Courts' experience from designing
then occupyingcourthouses over roughly the last 100 years.
5.5.3. Rule preparationThe Courts Design Guide was parsed and
scanned and encoded to
identify those statements dealing with circulation. 302
statementswere identied. These were analyzed and grouped according
tosimilar conditions, then translated into a set of computable
parametricrules in DAT, that could address all of the circulation
issues that wereidentied. Circulation rules are parameterized into
four high-level
t (with permission of Digital Alchemy).
-
1028 C. Eastman et al. / Automation in Construction 18 (2009)
10111033conditions: start space, intermediate space, destination
space condi-tions and transition conditions. The space conditions
have a spacename and also a security level (public, restricted or
secure). As shownin Fig. 19, transition conditions can represent
security level, routewalking distance length, vertical
accessibility, etc. These are speciedin a SMC parametric table. A
circulation rule dened by thecombination of these parameters
becomes computer-processible forautomatic checking using a SMC
plug-in developed by Georgia Tech.
5.5.4. Building model preparationIn the circulation validation
module, a circulation data view is
extracted for validation. End-users can dene a building model
usinga BIM authoring tool according to GSA Series Six BIM Guide
forCirculation and Security Validation [64]. The checking module
relieson standard space names used in courthouses which also
determinesthe security level of all assigned spaces, as dened in
the CDG.In the IFC models, a security zone is associated with each
space in aproperty set denition. Table 3 shows minimum modeling
informa-tion requirements for circulation validation checking.
These require-ments are implemented as a pre-checking module using
the SMCtechnology where space names, security assignment and
connectivityof circulation paths are pre-checked.
Fig. 16. Table-based reporting. (a) Table-based reporting of
SMC. (b) TablImplementation of the circulation requirements
involves thederivation of a circulation graph of the complete
building, identifyingall occupiable spaces and their
interconnectivity, as dened by walls,doors, stairs, ramps,
elevators and boundaries betweendirectly adjacentspaces (without
separating walls). Building model elements areautomatically mapped
to graph nodes and edges. Two types of graphare dened: (1) a
topological graph represents connections betweenspatial elements
(see Fig. 20). This graph was used to check routingpaths dened in
parameterized circulation rules. (2) The metric graphrepresents
distances reecting human movement paths within a space[65]. This
graph is used to check moving distance between two spacesand to
visualize circulation analysis results (see Fig. 21).
Through the graph structures, circulation validation
checkingsystem can assess whether circulation paths between two
spacesof the assessed building model satisfy the given
requirements. Thiscirculation assessment is an example of an
assessment that deals withissues not easily handled on the basis of
a building model itself.
5.5.5. Rule executionThe pre-checker identies any modeling or
name problems before
real checking is undertaken. The check involves a single module,
notrequiring management of views or modular rules.
e-based reporting of AEC3 XABIO (with permission of AEC3 UK
Ltd.).
-
Fig. 17. Graphics-based reporting. (a) Graphics-based reporting
from SMC (permission of Digital Alchemy). (b) Graphics-based
reporting of AEC3 XABIO and Octaga.
1029C. Eastman et al. / Automation in Construction 18 (2009)
10111033
-
Fig. 18. Spatial program
1030 C. Eastman et al. / Automation in Construction 18 (2009)
101110335.5.6. Rule reportingSince the rule checking is performed
on the basis of interpreted
parameters which are derived from the Courts Design Guide,
theoriginal circulation rules written in a natural language are
provided inthe checking results for end-users' conrmation. The
circulation rulechecking system developed for GSA provides a
back-referencenumber to the section, page and line of the Court
Design Guide.
Fig. 19. Table parameters for describing
Table 3Minimum modeling requirements for circulation
checking.
Modelingelement
Description
Space Space names should be dened on the basis of Space
namingconventions of GSA BIM Guide.
Security zone Security zone should be one of public, restricted,
and secure.This information can be dened as property denition for
eachspace.
Door Is part of wall. Door adjacencies to two spaces used for
accessibilitychecking.
Stair Use of IfcStair and IfcRelContainedInSpatialStructure.A
stair should be contained in a space.Stair may have components such
as slab (landing) and ight
Ramp A ramp should be contained in a space like stairs.Ramp may
have components such as ight and slab (landing)
Elevator Currently, elevator objects are dened through space
name. Forexample, judges elevator, prisoner elevator.
Wall There is no special requirement. Just needed for space
boundary.validation results.Violated circulation routes are
visualized showing the graph traversalstructure as a route between
starting space anddestination space. That is,if the buildingmodel
does not satisfy a circulation rule, one violated routefromall
possible routes is visualized. The shortest failing route is
selected,as shown in Fig. 21. The circulation rule states that USDC
courtroomshould be accessible fromUSDC judge chamber through
restricted zone.But since secure zone is located between the start
and destination spacein the example, this model does not satisfy
the circulation rule. Theseimages are also exported into the
reporting document.
In the circulation checking system, oor level, space name
andnumber of start and destination space are provided so that the
textualdescriptionmay allow architects (end-users) to recognize the
violatedcirculation rules. For example, the description of rule
checking errorshown in the E5 is There is no path that uses
following transitionconditions starting from USDC Judge Chamber (9)
of Floor 1 (Floorlevel) and ending to USDC COURTROOM and Transition
conditionsare Security Level: restricted, Usage: circulation,
Vertical Access:allowed. Thus, the detailed error message gives
end-users a cleardescription of the violated building elements and
circulation rules.Since this circulation validation checking system
of GSA wasdeveloped on the SMC platform, basic functions for
analysis reportingare similar to other rule checking systems.
5.5.7. SummaryThe spatial program validation application is now
applied to all
GSA new construction projects. The design guide checking
applica-tion, which has only addressed circulation and security
thus far, relies
circulation rules of a design guide.
-
on a derived graph based on the room connectivity, space names
and structure and completeness, for interfacing with other
applications. In
Fig. 20. Reporting.
1031C. Eastman et al. / Automation in Construction 18 (2009)
10111033security zone within oors. Each oor is connected through
verticalcirculation, which also has security classes. The
application uses theSolibri platform, extending the family rules
SMC supports. DAT hasbeen applied to multiple US Courthouse
projects. Its operation isabout 90% automated.
6. User experience
User experience with rule-based systems is limited. Only
theSingapore e-PlanCheck system is operational but the authors
werenot able to gain feedback from its users. The ICC checking
system hasa demonstration site, at:
http://www2.iccsafe.org/io/smartcodes/. Ithas a section of the
energy code that can be applied the any of thepre-prepared entries
in the menu of buildings. Example reportsare generated, including a
model viewer allowing visual inspection.These work well, although
some buildings take multiple minutes toanalyze.
Solibri seems to have the largest user base (not all using
theadvanced applications reported here). It supports a wide range
of typesof rule checking. Contact with some users suggests it is
most used forclash detection, spaceprogramvalidation, and
checkingmodels for theirFig. 21. Visualization of viosome ofces it
is used regularly for these purposes.The main user issues
encountered in current systems are the de-
manding model structure requirements. Space layout, for
example,typically requires that all interior space on a slab be
assigned a desig-nation, without overlaps. Space and attribute
namesmustmatch thoserequired. When the geometry of composed
assemblies is required,the composition requirements are often quite
prescriptive, oftenrequiring specially-tailoredmodel views. These
types of requirementimpose signicant effort on the user. In the
future, when these ruledenitions become more robust, the modeling
requirements willslacken.
7. Major issues in building rule checking systems
While rule checking system development has been going for
aboutten years, the platforms are all currently limited in what
they support.As a platform, Solibri SMC has been used widely, with
the functionalcapabilities laid out in Section 4. It has a wide
range of checkingcapabilities, including clash detection, spatial
validation, plus othersdescribed in Section 4. It lacks two
capabilities that are offered by theJotne EDM platform: an open
environment for writing rules and alated circulation route.
-
1032 C. Eastman et al. / Automation in Construction 18 (2009)
10111033database backend management system. EDM has provided
servercapabilities for most of the efforts reviewed here. It
supports EXPRESSand EXPRESS-Xmodel view and rule writing
capabilities. The FORNAXsoftware library requires full computer
programming capabilitiesto tailor a rule writing system to a
particular need. The SMARTcodesBuilder software capabilities
developed by AEC3 and Digital Alchmeypresents another important
aspect of the overall environment, sup-porting the rigorous
semi-automatic translation of written humanrules into programmable
rules. Lacking is an overall systems envi-ronment that provides
some level of response to all the functionalitypresented here, in
an open form allowing developers to dene newrules within a domain
that can be checked and results reported.
A general approach for development of rule checking systems
canbe discerned from this review; to provide a method for
mappingthe terms in written statements into the logic of testing
conditions,then to dene enriched data objects and methods capable
of derivingproperties and relations needed to respond to rule
queries. Suchefforts should be based on development of an ontology
of objectsand properties for the relevant building domains. While
some of theobjects are enriched versions of IFC objects, others
require the deri-vation of new composite objects, dealing for
example with accuratemodels of building space or circulation
networks. The developmentof enriched objects for rule checking has
been largely proprietary andun-available for public review and
assessment. A more publicapproach seems needed, so that the effort
of dening these enrichedobjects can be shared and carried out in
parallel. Once such object andmethod denitions exist, it becomes
practical to dene user-orientedrule denition languages and checking
that can move these capa-bilities from the software lab to a user
desktop. Rule denitionlanguages can be created for different
environments, from servers toembedding in BIM authoring
applications. Then a ruleset can be denedin the language portably,
and executable on any environment support-ing the language. Only
then will wide application of rule checkingtechnology become
broadly used.
An important aspect of the overall rule checking capability
mustdeal with modeling requirements of the building model. The
buildingmodel to be checked has to be consistent with the rules to
be checked,possessing the needed IFC entities and properties prior
to derivationof extended information and checking. Requirements for
a well-dened building model should be clearly dened from the users
andsoftware developers' standpoint, based on clearly dened model
viewdenitions. The ICC effort has begun to dene ICC model views
basedon the National BIM Standard methods [66], as has the GSA
[64].
Until now, the primary example of deriving a separate model
viewfor rule checking has been for pedestrian circulation
assessment. Otherderived models for air ows, energy and structural
analysis,earthquake safety, terrorist attacks and other special
conditions willeventually be developed, capturing best practice
knowledge in differenttechnical domains.
7.1. Verication of code checking
A critical issue of automatic code checking is verication of
thechecking algorithms and results. Verication can be compromised
byboth rule checking algorithm errors and by building model
denitionerrors. Known verication errors occurring from coding
errors includeinexact treatment of highly nested quantication rules
and theirexecution, for example that every occupiable space must
have at leastone exit route that meets emergency exit requirements.
Anotherchallenge is to identify false positives. False negative
tests are observ-able because reported errors require review. False
positives are notnecessar