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: chuck.eastman@arch.gatech.edu (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