• Author / Uploaded
• Ricardo Moço

Citation preview

Automation in Construction 18 (2009) 1011–1033

Contents lists available at ScienceDirect

Automation in Construction j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / a u t c o n

Review

Automatic rule-based checking of building designs C. Eastman ⁎, Jae-min Lee, Yeon-suk Jeong, Jin-kook Lee College of Architecture, Georgia Institute of Technology, United States

a r t i c l e

i n f o

Article history: Accepted 30 July 2009 Keywords: BIM Design assessment Building codes Design guides

a b s t r a c t This paper surveys rule checking systems that assess building designs according to various criteria. We examine five major industrial efforts in detail, all relying on IFC building models as input. The functional capabilities of a rule checking system are organized into four stages; these functional criteria provide a framework for comparisons of the five systems. The review assesses both the technology and structure of building design rule checking, as an assessment of this new emerging field. The development of rule checking systems for building is very young and only limited user experience is presented. The survey lays out a framework for considering research needed for this area to mature. © 2009 Elsevier B.V. All rights reserved.

Contents 1. 2. 3.

4. 5.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . History of rule checking research . . . . . . . . . . . . . . . . The rule checking process . . . . . . . . . . . . . . . . . . . 3.1. Rule interpretation . . . . . . . . . . . . . . . . . . . 3.1.1. Logic-based interpretation . . . . . . . . . . . 3.1.2. Ontology of names and properties . . . . . . . . 3.1.3. Implementation method . . . . . . . . . . . . 3.1.4. Language driven . . . . . . . . . . . . . . . . 3.2. Building model preparation . . . . . . . . . . . . . . . 3.2.1. Model views . . . . . . . . . . . . . . . . . . 3.2.2. Derive implicit properties using enhanced objects 3.2.3. Derive new models . . . . . . . . . . . . . . . 3.2.4. Performance-based model and integrated analysis 3.2.5. Visibility of layout rule parameters . . . . . . . 3.3. Rule execution . . . . . . . . . . . . . . . . . . . . . 3.3.1. Model view syntactic pre-checking . . . . . . . 3.3.2. Management of view submissions . . . . . . . . 3.4. Rule check reporting . . . . . . . . . . . . . . . . . . 3.4.1. Rule instance graphical reporting . . . . . . . . 3.4.2. Reference to source rule . . . . . . . . . . . . 3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . Rule-based platforms . . . . . . . . . . . . . . . . . . . . . Survey of rule-based building model checkers . . . . . . . . . . 5.1. CORENET-Singapore . . . . . . . . . . . . . . . . . . . 5.1.1. Rule interpretation . . . . . . . . . . . . . . . 5.1.2. Building model preparation . . . . . . . . . . . 5.1.3. Rule execution . . . . . . . . . . . . . . . . . 5.1.4. Rule reporting . . . . . . . . . . . . . . . . . 5.1.5. CORENET summary . . . . . . . . . . . . . . .

⁎ Corresponding author. E-mail address: [email protected] (C. Eastman). 0926-5805/$ – see front matter © 2009 Elsevier B.V. All rights reserved. doi:10.1016/j.autcon.2009.07.002

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1012 1013 1013 1013 1013 1014 1014 1014 1014 1014 1014 1015 1015 1015 1015 1015 1015 1015 1015 1015 1016 1016 1017 1017 1017 1017 1017 1017 1017

1012

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

5.2.

Norwegian Statsbygg's design rule checking efforts . . . . . . . . . . . . . . . 5.2.1. Spatial requirement checking . . . . . . . . . . . . . . . . . . . . . 5.2.2. Rule checking for accessible design . . . . . . . . . . . . . . . . . . 5.2.3. Building model preparation . . . . . . . . . . . . . . . . . . . . . . 5.2.4. Rule execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.5. Rule reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. Design check by cooperative research centre for construction innovation in the Australia 5.3.1. Rule interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2. 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. Verification of code checking . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. Rule checking system as a design development supporting system . . . . . . . . 7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1. Introduction New criteria continuously emerge in architecture, ranging from building codes and safety, to the techniques of fabrication and assembly. Until recently, the only means to deal with this complex and growing body of knowledge were human cognition and organizational review processes. Some criteria involve computerized analyses (e.g. structures), but still, the details of safety factors and interpretation of the results have been a manual, peoplecentered undertaking. The advent of computer applications supporting the 3D object modeling of buildings, called Building Information Modeling (BIM), allow both automatic parametric generation of designs that respond to various criteria and the prospect of computer-interpretable models and automated checking of designs after they are generated [1]. Automated rule checking here is defined as software that does not modify a building design, but rather assesses a design on the basis of the configuration of objects, their relations or attributes. Rule-based systems apply rules, constraints or conditions to a proposed design, with results such as “pass”, “fail” or “warning”, or ‘unknown’ for cases where the needed data is incomplete or missing. While some rules can be embedded in parametric design generating systems, automated rule checking of candidate designs are appropriate where the rules: 1. Apply across different building and spatial systems, because the objects and rules of generation cannot be defined beforehand. Spatial configurations are an example. 2. Are those of public agencies, organizations or clients that need to review designs that are generated by an open-ended set of design tools. 3. Where the conditions being assessed are global ones, such as rules associated with safety, structural integrity, energy usage and costs.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1018 1019 1020 1021 1021 1022 1023 1023 1023 1023 1024 1024 1024 1024 1025 1026 1026 1027 1027 1027 1027 1028 1028 1030 1030 1031 1031 1032 1032 1032 1032 1032

Almost all efforts in automating rule checking to date have been applied to building code and accessibility criteria. These types of rule checking are required of all buildings constructed within a jurisdiction. Since code plan checking is often a costly bottleneck in the building delivery process, automated code reviews have the potential to save significant time and cost. In this review, we approach rule checking systems from a perspective of broader potential applicability. We expect rule-based systems to become a class of application that will have wide deployment in the AEC industries: 1. For all buildings—general conditions such as building codes, at the national, regional or municipality level of organization. 2. For particular building types—design guides of best practices for a building type; this type of rule-base may be defined by the client organization, or alternatively, as best practices within a design or engineering firm. 3. For a specific building project: programmatic requirements for a building instance, such as its space requirements, circulation issues, ergonomic layout and special site considerations; these may be developed by the client or design firm, and the specific rules defined as part of the program and review criteria during project design and construction. We expect to see application of rule checking systems to move beyond code checking to the other two levels of specificity and eventually to become a standard tool used throughout the building lifecycle. A rule-based assessment tool can be implemented for various platforms, for example: (1) as an application closely tied to a design tool, such as a plug-in, allowing checking whenever the designer wishes. (2) or as a stand-alone application running on desktops, in parallel to a design generating tool; (3) as a web-based application that can accept design from a variety of sources. Each approach is desirable for some uses. Current efforts have focused on the web-

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

based approach but we look forward to the development of simple-todevelop rule-based systems that encourage implementation of the other types. The only neutral model representation for describing a building for rule checking is Industry Foundation Classes (IFC) [2]. This is a design tool independent and neutral data model representation supported by most BIM design tools, and is being used as the building model representation in all the efforts reviewed here. Rule checking using native application data models will probably also emerge. There has been a long historical interest in structuring building codes into a form amenable for machine interpretation and application. Efforts to implement production rule-based systems came later, as supporting hardware and web-access matured. The initial effort was led by Singapore, who started considering code checking on 2D drawings in 1995. It then switched and started the CORENET System working with IFC building models in 1998 [3]. More recent efforts have been initiated in Norway [4] and Australia [5]. A U.S. effort also has been initiated called SmartCODES [6]. There are also several research implementations of rules to assess accessibility for special populations [7] and for fire codes [8]. The GSA and US Courts has recently supported development of design rules checking of federal courthouses, which is an early example of rule checking applied for automating design guides [9]. This paper reviews these five efforts to automate rule checking in buildings, focusing primarily on building code reviews. These are CORENET, the HITOS project by Norwegian Statsbygg, the effort by the Australian Building Codes Board, the International Code Council in the US. We also review the General Services Administration effort involving building type design rule checking, which has supported the efforts of the authors. Many other systems applications have limited purpose targeted rule checking capabilities: such as for checking room areas or for spatial conflict checking. We exclude these, focusing on systems with potentially general rule checking capabilities. We start by reviewing early research in the area, then outline a general functional architecture of services that all rule checking systems need to provide. Using this structure, we then review the main institutional efforts being carried out in several parts of the world. Last, we summarize the current status of efforts and identify areas where additional research is needed. 2. History of rule checking research Rules and regulations are written by people and for a long time, were only read and applied by people. As a result, they were sometimes incomplete (particular conditions were not covered) or contradictory. Their structure was often arbitrarily complex. Improving the logical structure of regulatory codes was an area of early research. Fenves undertook initial work to structure regulatory codes in decision tables [10]. Later, decision trees were applied to structural steel design [11]. Software tools were developed to support the management of regulations [12] in different jurisdictions. Fenves' students followed by structuring regulations in a predicate logic structure [13,14]. Other software was developed, called the SASE system (Standards Analysis, Synthesis and Expression) [15], to provide a comprehensive structure for families of related codes (as exists across the many US jurisdictions). An important review and critique of these early efforts is provided in [16]. Given the predicate logic structure, Kerrigan developed the REGNET application to determine for given building conditions the applicability for various codes, based on a question-and-answer user interface [17]. These early efforts laid out the logical structure of codes, from a rule-based and organizational perspective. They did not address in a significant way automated application of rules to a digital building representation. In parallel, various efforts were undertaken to apply rule checking to building representations, using specially coded drawing structures

1013

or textual descriptions. These were applied to fire escape and evacuation [18], other forms of prescriptive requirements and performance-based standards [19]. Development of rule-based systems for building models began exploration in the late 1980s [20]. In the 1990s, the development of the Industry Foundation Classes led to early research for using this building model schema for building code checking. Han and others laid out general opportunities and a client– server approach [21,22]. Han identified the need for multiple object views for different types of rule checking [23]. They later developed a simulation approach of ADA wheelchair accessibility checking [24,25]. These efforts set the stage for larger, more industrial-based efforts. 3. The rule checking process From the early efforts and our review of current work, we have extracted a necessary structure for implementing a functionally complete rule checking and reporting system. Rule checking can be broadly structured into four stages: (1) rule interpretation and logical structuring of rules for their application; (2) building model preparation, where the necessary information required for checking is prepared; (3) the rule execution phase, which carries out the checking, and (4) the reporting of the checking results. Within each of these phases, we identify a set of more detailed functional issues. Within the first three phases, shared conventions must exist regarding the coded rules so they match with the properties and structures that are embedded in the building model. Information availability for rule checking can be addressed in some mixture of three strategies: 1. Requiring the designer to explicitly provide information in the building model needed for checking. While this is natural for some aspects (door and window locations and sizes), others are derived from more basic information and rely on fallible human judgment that are current causes of error (minimum headroom in stairway, wheelchair navigation in a restroom). 2. Having the computer derive new data or generate model views that explicitly derive the lacking data. Examples where computer processing can extract implicit attributes include the examples of headroom and wheelchair access in #1 above and fire exit paths and their lengths. 3. Some important design rules apply to properties that require complex simulations or analyses, such as for structural integrity or energy usage. These require the application of an analysis model to derive the complex information, then to apply the rules to the analytically derived data. As can be seen, rule checking implementation approaches involve many trade-offs between imposing documentation work on the designer and imposing stronger inference capabilities within the rule checking software. These issues arise continuously throughout the design and implementation of rule checking systems. 3.1. Rule interpretation Rules for building design are first defined by people and represented in human language formats, typically written text, tables and possibly equations. In building codes, these rules have legal status. How can the interpretation of these rules into a machine processable format be done, in a manner that the implementation can be validated as consistent with the written rule? In some rule checking implementations, the process relies on the programmer's interpretation and translation of the written rules into computer code. In other cases, the logic of the human language statements is formally interpreted and then translated. 3.1.1. Logic-based interpretation A common intermediate language for mapping rules from natural language to processable form is first 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) 1011–1033

formalize rules defined by people [26]. In logic, a predicate is a welldefined term (or function) that can be evaluated to TRUE or FALSE (or undefined, if terms are not defined). Predicate logic also deals with quantification, whether a statement applies either to ALL instances where a condition arises, or that it applies at least to one of the instances—that the condition EXISTS. There are well developed general techniques for translating logical assertions into executable statements, most importantly the Prolog computer language [27]. The domain of buildings and the interpretation of where rules apply and how many instances of the rule need to be applied are major issues. In this domain, rules are typically deeply nested, based on many contextual conditions, for example based on type of construction, earthquake zone, and construction details. Other rules are general and apply to all conditions of an occurrence, which can occur in the thousands.

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

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

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

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

circulation space or use space. Some of these limitations would disappear if fully and accurately defined space objects in buildings could be derived, allowing a rich set of assessments of spaces to be undertaken. 3.2.3. Derive new models Other efforts automatically derive a new building model to facilitate assessment of certain implicit properties or relations. An example is the derivation of a graph of circulation paths from a building's spatial layout to check accessibility for the handicapped and for fire exits [33]. The derived model can carry attributes designating walking distances between spaces and other spatial properties needed for circulation assessment. The derived views and attributes allow checking of properties that would be very complex on a standard building model. 3.2.4. Performance-based model and integrated analysis Some of the properties of a design being checked are performancebased, requiring analysis or simulations for their derivation. Structural analyses are required for many buildings and energy analysis is becoming more common. Performance-based rules generally require a specially derived model view, with its own geometry, material or other parameters properties and assumed loads, as input for executing the analysis/simulation. The analysis results are combined with the modeling assumptions to determine the adequacy of the rules. We are not aware of any system today that integrates these different steps into an automated performance review. 3.2.5. Visibility of layout rule parameters While it is possible to check every instance of some type of layout, such as stud or floor joist spacing, current practice in drawing layout is to denote the generation rule, e.g., “2 × 4 studs at 16" O.C.” The layout rule parameters on a drawing are assessed, not the graphical layout itself, for these aspects. These denotations eliminate much possibly redundant checking. Layout parameters are important in checking wherever a simple rule has been defined for generating a layout. It is easier to check the parameters in the layout rule than every instance of its application. Such layout rules can be explicitly entered in the building model as attributes; because the IFC is defined using the EXPRESS 1.0 Language [34] and EXPRESS 1.0. cannot represent layout generation rules, alternative conventions documenting the layout rules is required. 3.3. Rule execution The execution phase brings together the prepared building model with the rules that apply to it. Execution issues largely deal with the management of this the review process. 3.3.1. Model view syntactic pre-checking Prior to applying rule checking, syntactic checking of the model is needed, to determine that the building model carries the properties, names, objects needed, either for the complete checking task or more likely, for limited model views, for checking a part of the rule set. If new model views are derived, then the pre-checking is carried out prior to the derivation. Pre-checking needs to be undertaken to validate that the data needed for checking is available from the model [35]. The actual rule execution becomes relatively straightforward when (1) the rules have been interpreted into computable forms consistent with functions, (2) the functions have been prepared that match the capabilities and information available in the building model. 3.3.2. Management of view submissions Modular rule checking systems that apply a set of related rules to a model view are expected to be the common structure for code checking. General rule checking then will require a management system to coor-

1015

dinate and oversee the application of the multiple rule modules and their results. Management will have to address at least two issues: Completeness of rule checking: If views are separately submitted to assess different types of rules, then the selection of the appropriate rule subset is required. As the different rule sets are checked, the completeness of the entire rule checking process must be managed. Model version consistency: Methods for model version consistency also must be put in place that determine that all model views submitted for assessment form a single integrated design, not one that has been varied inconsistently so as to pass each of the subset requirements. This issue is complicated if the assessment is iterated with partial changes. Because of incremental implementation and rollout, it is anticipated that code reviews will be a mixture of automated and manual checking for many years. The development of rule processing environments is in its early stages of development and will deserve significant attention as the field matures. These issues may not apply for design guide and project-level rule checking. 3.4. Rule check reporting The last step in rule checking reports the results. Design conditions that are satisfactory—those that PASS—need to be reported as part of an audit trial that validates the completeness of the check. One can envision various situations where the identification of instance conditions that pass a rule would provide valuable knowledge, for example a special case earthquake zone structural test. Rules are defined at the implementation level according to the object class, group or configuration they apply to. For a particular building, a single rule may apply to hundreds or even thousands of instances of the object class within the building, e.g. all doors or windows. Each of these instances needs to be discriminated in the testing and reporting. For example, if a rule applies to all hospital rooms and the rooms vary, then all hospital rooms will have to be tested and results reported. 3.4.1. Rule instance graphical reporting While buildings have clear labels regarding floor levels and spaces, many of the contexts that must be checked address conditions that have no naming scheme. For example, the framing conditions on some corner in the middle of the building may not satisfy some rule. A simple and intuitive means to identify these is by reference to location in project coordinates, and placing the viewing camera at a location depicting the issue. This is typically done for spatial conflict testing [36,37]. Examples of this approach show that it is an effective way to communicate problems to people submitting the building models for review. 3.4.2. Reference to source rule Associated with the error location must be the applicable rule—the condition checked at the given location. This requires carrying out the reverse mapping from the rule interpretation task, mapping back to the original textual description of the rule. The local instance parameters and the text defining the rule violated are the basics for reporting. More elaborate reporting, with specific text explaining the error will evolve, describing how the rule might fail, with parameters for the relevant instance codes, or possible actions to correct the error. Different assessment reports may be required for the testing organization and the submitter. For example, the testing agency may need to know assumptions of the testing for later possible audit conditions that the design submitter may not be interested in. At some point in the future, rule checking may have extended reporting capabilities. For example, the reporting could be by xml back to the host application and model, allowing quick correction. Issue management systems can support tracking and acting on errors to manage corrections. Also, rule systems implemented locally could do the error reporting in the authoring tool, facilitating much

1016

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

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

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

Fig. 1. The four classes of functionality a rule checking system should support: Rule derivation, building model preparation, rule execution, and rule reporting, and their needed internal capabilities.

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

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

1017

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

1018

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

Table 1 Overview of rule checking systems.

a

SMC supports computation of additional geometry, such as door swing arcs, wheel chair turning circles, that can be used in checking rules.

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

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

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

1019

Fig. 2. An example of FORNAX object—ExistStaircaseShaft adopted from the Singapore Civil Defense Fire Code [67].

universal layout, service lifetime etc) based on increased awareness/ value in building information” as described in its report [52]. Fig. 4 illustrates the overview of spatial program requirement validation, building accessibility checking, and other processes centered on IFCbased interoperability.

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

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

1020

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

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

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

deals with accessibility rule checking system as described in the following section. 5.2.2. Rule checking for accessible design The other module in the HITOS Project addresses accessibility checking. Some of the requirements for universal design were initially defined in the dRofus database. Solibri involvement in the HITOS Project is to provide a universal design assessment application

Fig. 5. dRofus handles detailed spatial data in tabular structure, and exports them with a dummy space geometry [38].

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

1021

Fig. 6. Examples of accessibility rule checking and their visualization in SMC on building instance examples: 1) accessible corridors using buffered boundaries, 2) overlapped door swing arcs, 3) not enough area for wheelchair turning in a bathroom.

running in Solibri Model Checker. SMC's accessibility rules are derived from the following standards: ▪ International ISO/CD 21542 (draft). [54] ▪ International Code Council ICC/ANSI A117.1. [55] SMC supports various parameterized rules derived from these standards, including wheel chair turning circle, stair, ramp, and door dimensions and clearance. The rule examples in natural sentences are as follows: ▪ The minimum clear passage width of a doorway shall be not less than 800 mm. ▪ An end landing shall be provided at the foot and at the head of a ramp. ▪ The rise and tread of steps within flights shall be uniform. ▪ The surface width of a stair shall be not less than 1200 mm. ▪ Head clearance height above the stair shall be greater than 2100 mm. ▪ Surface materials shall be rigid with a plane and slip resistance surface, in both wet and dry conditions. The process of accessibility checking in the HITOS project provides a good overview of SMC functionality. That is, some general features of SMC are also applied in other SMC-based case studies reviewed here. The accessibility rules are translated into a parametric table structure: Accessibility ruleset, and Solibri incorporates all required checking functionality for executing the tests. Fig. 6 shows an actual model of HITOS in SMC and some specific checking examples. For accessibility checking, SMC supports processes with not only geometric data of a single building object but also other associated objects and their properties, such as surface material. The accessibility rules basically involve building objects such as spaces, doors, stairs, ramps, and windows. The majority of rules deal with the relation between these objects. Some rules define relations between the sub-objects composing them. For example, for checking clear width of corridors as shown under the criteria “circulation” in Table 2, several input parameters are required not only for its floor width but also for other associated objects such as columns, doors, washbowls, etc. Fig. 7 depicts some input parameters for these relations between different objects. Most of them are geometry related issues, but some other rules deal with an object's properties such as surface materials and glare percentages as shown in Table 2. A space name based ontology supports the accessibility checking. That is, some specific spaces or objects are associated with certain kind of accessibility rules, such as a washroom, kitchen or storage. Therefore SMC supports restrictions on which objects are accessed for given attributes by space names or locations.

When a given IFC model is prepared, SMC retrieves all the ruleassociated building objects and their geometric data. From the parameterized rules, the system receives the mapping between building objects and required values coded within checking equations. Also the values for rules can be adjusted instead of using the default values taken from ISO/CD 21542 [54]. This is needed when national or other codes vary from the ISO standard. Different rule sets can be called up to apply to a model. Currently, however, SMC expects the user to manage model views, to submit them to the computer or server. No information is carried across multiple rule checking sessions for example any changed defaults for conditions in Fig. 8. 5.2.3. Building model preparation When a given IFC model is prepared, SMC retrieves all the ruleassociated building objects and their geometric data. From the parameterized rules, the system receives the mapping between building objects and required values coded within checking equations. The values for rules can be adjusted instead of using the default values taken from ISO/CD 21542 [54]. This is needed when national or other codes vary from the ISO standard. Different rule sets can be called up to apply to a model. 5.2.4. Rule execution SMC has extensive pre-checking capabilities, as reported earlier. Different rule sets can be called up to apply to a model. Currently, it expects the user to manage model views, to submit them to the computer or server.

Table 2 Overview of the accessibility rule checking in SMC: criteria, building objects, and checking features. Criteria

Objects

Requirements for Door accessible circulation Corridor Stair

Rules for specific spaces

Windows requirements Surfaces requirements

Ramp Washroom Kitchen Storage Window sills

Checking features Door dimensions and their swing operation Clear widths and wheelchair turning diameters Various requirements for risers, treads, steps, etc. Slope, length, clear widths, etc. Washroom door requirements, wheelchair turning Wheelchair turning diameter checking Wheelchair turning diameter checking Maximum sill height

Required floor coverings and related property sets Stair, ramp surfaces Non-skid materials on surfaces

Floor, wall coverings

1022

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

Fig. 7. Input parameter window of required properties for any accessible stair (courtesy SMC).

5.2.5. Rule reporting SMC supports textual and graphical reporting in several document file formats. It can also provides the severity of rule violations in three levels: Critical, Moderate and Low. SMC has functionality to save check-

ing results in its own file format, but IFC export is—by design—not supported; SMC is not intended to be a model authoring application. However hotlinks to common BIM/CAD applications like Graphisoft's ArchiCad and Autodesk's Architecture DeskTop (ADT) are provided,

Fig. 8. The input parameters window for accessible floor (left) and door object (right) (courtesy SMC).

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

highlighting SMC results/issues in the BIM/CAD application. Also SMC has no tracking functionality for reporting conditions that pass the applied rules. This makes it difficult to review the instances of rule processing applied to a given model. 5.2.6. Summary The dRofus spatial checking database addresses the role of space planning and facility management within an institution managing large amounts of space. It relies on IFC spatial data and commercial applications linked together within the HITOS project. The accessible design checking in the HITOS project is Solibri-based and relies on functionality, found in SMC-based installations. Some rules were developed specifically for this project, and co-funded by Skanska Finland and Statsbygg Norway. The ISO-based accessibility rule checking has been amended and incorporated as one of the default rulesets in the latest release of SMC as of 2009 [7]. Statsbygg found that the IFC-based universal design checking implemented by Solibri could reduce by 60–70% the common design failures or deficiencies [50]. 5.3. Design check by cooperative research centre for construction innovation in the Australia The Cooperative Research Centre for Construction Innovation in Australia funded a project that included the Commonwealth Scientific and Industrial Research Organization (CSIRO), University of Sydney, Building Commission Victoria, Australian Building Codes Board (ABCB) and Woods Bagot. The Australian Building Codes Board (ABCB) on behalf of the Australian Government and State and Territory Government maintains and updates the Building Code of Australia (BCA). In the first stage of the project, Express Data Manager (EDM) [43] and Solibri Model Checker (SMC) [36] were reviewed in relation to the base

1023

functionalities required for automated code checking. The code requirements for accessibility, which are defined in the BCA D3, Australian Standard (AS) 1428.1 “Design for access and mobility”, were used for an initial feasibility assessment [56]. Because the SMC capabilities are reviewed elsewhere, this review focuses on the EDM capabilities, which was the platform the assessment later recommended. The EDM platform was then used in the second stage of the project in which all of the nonadministrative clauses in AS 1428.1 and BCA D3 were encoded [5]. 5.3.1. Rule interpretation The ABCB EDM implementation relies on object-oriented techniques for its development approach. It utilizes the following pre-implementation specification structure: Description, Performance requirements, Objects, Properties, Relationships, Domain-specific knowledge for interpretation (see Fig. 9). These descriptions provide written statements of building codes interpretation. Then the statements are translated (by people) into the performance requirements in computer code. The performance requirements facilitate translation into objects and relations. In order to handle the requirements, objects and object properties are extracted from the building information and accessed to assess the performance requirements. EDModelChecker uses the EXPRESS language to define the rule schema [41]. The pseudo code which is relevant for interpretation of domain-specific knowledge (example shown in Fig. 9) is encoded into functions and rules in the EXPRESS language. Since the objects, object properties and object relations utilized by the rules are all represented by the IFC model schema, this rule schema can be clearly defined. 5.3.2. Building model preparation While this structure works well for many aspects of code checking it is difficult to define checks for handling some configuration criteria.

Fig. 9. Encoding example of a building code according to IFC object-based interpretation [56].

1024

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

Fig. 10. An illustration of the adjacency graph, where F means false and T means true [68].

Since AS 1428 requires “access” to the determined rather than calculating path distances, a graph approach was taken (see Fig. 10). Starting at an external entrance that was “accessible”, the containing space was defined as “accessible”. All adjoining spaces which had “accessible” openings into this previously checked space where then defined as “accessible”. This can be applied recursively across the building model until all accessible spaces are tagged. This can then be checked against the need to be accessible. 5.3.3. Rule execution The ABCB system in organized into rule sets. It runs the chosen rule set against the model initially as a pre-check to identify areas with insufficient information. 5.3.4. Rule reporting The project used EDM functions to generate text-based reports for checking results. The reports are saved into XML and HTML documents. As shown in Figs. 11–13, references of non-compliant codes give detailed description of violations and building elements. An interactive report system is also provided to show analysis results for each clause or object type selected. As shown in Fig. 11, the report panel key gives brief information for analysis results according to each clause. Interactive page reporting allows end-users to select the report type that they wish to view and update the building model (see Fig. 12). A print-friendly version of the report (see Fig. 13) is linked to the interactive report page of Fig. 12. The Design Checking system currently supports graphical reporting without geometric shape of building objects, but provides warning for designers.

5.3.5. Summary The Australian code checking effort was developed in two phases. The CRC for Construction Innovation undertook the first phase in order to assess the capabilities of current rule checking systems and for finding out the best approach for supporting computerization of Australian Standards. Two major checking systems were compared by applying the same building codes within the two systems. The EDM prototype was found to offer a more flexible and open development environment, because the EDM system provides a publicly accessible definition language to represent building codes. However, working knowledge of the rule writing capabilities of the EXPRESS language is limited to only the small group of people who learn it on their own (in relation to C++ or java). After completing the feasibility study, Design Check system was developed in Phase Two [5]. The development method which was adopted by the feasibility study in Phase one was applied. A graph was developed for inferring adjacent accessible spaces for accessibility checking. The report system has a direct interface to the database of the building model and provides both an interactive report page and print-friendly report page. 3D graphic view will be integrated with rule checking system in future. 5.4. International Code Council (ICC) The International Code Council (ICC) develops the master building code used by jurisdictions in North America. It is used to construct codes for residential and commercial buildings and most institutional buildings. In 2006, it began supporting development of SMARTcodes; the development being carried out by AEC3 and Digital Alchemy.

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

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

1025

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

SMARTcodes provides for the mapping of written building codes into interoperable computer-interpretable code sets. The project for developing SMARTcodes focuses on automating and simplifying code compliance checking against the ICC codes and federal, state, and locally adopted versions of the codes. 5.4.1. Rule interpretation Currently, International Energy Conservation Code [57] has been implemented. The SMARTcodes uses an IECC dictionary for definitions of terms for objects and properties that are critical for model checking. It provides SMARTcodes builder, which is Web-based software to facilitate creation of SMARTcodes. This software reduces errors which occur during the interpretation of original building codes into SMARTcodes/it supports this by having user identify key phrases and their logical role, then formalizes the phrase using terms from the dictionary (see Fig. 14). Written rule statements, regulations and specifications are interpreted by the SMARTcodes builder, using the IECC dictionary that describes properties associated with each term, the enumeration of properties, data types and units associated with

each property. The dictionary is used not only for rule interpretation, but also for communication between SMARTcodes model checking system and the IFC building model. IFC object properties defined in the dictionary provide model views for rule checking. The model views are classified by terms and properties of the dictionary. ICC allows end-users to try out the model checking system through a web site [58]. Currently, SMARTcodes for Solibri Model Checker, developed by Digital Alchemy (DA), and AEC3 XABIO, developed by AEC3 [59], support the rule-based building code compliance checking. The Web services require input values such as a building model, building location, code to be checked and model checking system. Currently, building models are limited to several pre-configured test models provided on the web server that satisfy modeling requirements needed for checking. They include a prototypical office building, Lawrence Berkeley National Laboratory, the National Association of Realtor Headquarters building, and four building models provided by the U.S. Coast Guard. In the future, SMARTcodes will support submission of enduser's building models. Only selected portions of the 2006 IECC is available for demonstration.

1026

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

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

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

provided with graphical images about elements of the building model (see Fig. 17). The analysis results of code compliance checking provide information regarding the building elements violated. SMC provides the MCS with identifier, location, property and geometric shape of a building element on the browser. As shown in bottom left of Fig. 16(b), the reason for non-compliance is stated. In this case the wall (Wall.3.1 is identified in SMC window) thermal resistance of design is 0.0R, but the code requires 13.0R or greater. Location information relevant to the wall is automatically visualized on the graphic browser of SMC. This information with a textual reference of code criteria is also specified in the report. AEC3 XABIO also provides a trace back report giving a logical step explanation for failure. 5.4.3. Summary The ICC SMARTcodes is a new approach for rule checking system development, taking a fairly comprehensive approach to the overall

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

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

1027

Fig. 15. Textual reference to source rule text (with permission of Digital Alchemy).

checking and reporting tasks. Building codes are created from SMARTcodes builder in a rigorous and formal way that facilitates semi-automatic creation of computer-processible codes. Currently the SMARTcodes model checking system focuses on available or easily derived properties rather than deriving auxiliary model views or analytical models for complex simulation for various kinds of analyses. 5.5. General services administration design rule checking Within General Services Administration (GSA), the Public Building Service (PBS) manages workspaces for the federal government and is the largest owner of commercial space in the United States. The (GSA) initiated the National 3D–4D-BIM Program through its PBS Office of Chief Architect (OCA) in 2003 [60]. They have initiated six BIM demonstration projects; two programs are associated with development of assessment tools. Assessment tools for Spatial Program Validation and Automated Design Guide Checking, both developed as part of their 3D–4D Building Information Modeling program. 5.5.1. Spatial program validation New building design for GSA follows a fairly traditional development process, with multiple stages of concept design, design development and construction documents. The tool for spatial program validation allows GSA project teams to automatically assess whether or not the A/E late concept design conforms to the GSA approved spatial program, in relation to the spatial requirements set forth by the Congressionally approved housing plan and PBS Business Assignment Guide [61]. These requirements include area measurements (e.g., net or usable) and building efficiency measurements (e.g., fenestration ratio). Starting in 2007, all GSA projects involving new construction are required

to submit BIM data allowing spatial validation review in the final concept phase. Submitted BIM data is quickly analyzed (see Fig. 18) and reviewed by the GSA project team. As shown in Fig. 18, various kinds of area calculation are defined by PBS Business Assignment Guide and ANSI/BOMA area calculation guide [62]. These area values are automatically derived from the building model according to fairly intricate conditions specified by the ANSI/BOMA space definition method. Since this assessment tool is available in the SMC browser, these area values are exported to a reporting document as a basic function. This assessment is similar to the dRofus assessment by Statsbygg, but uses a different method of area calculation and reporting. 5.5.2. Design guide checking GSA has also funded development of a rule checking system for circulation and security validation of U.S. courthouses, called Design Assessment Tool (DAT) and was developed by Georgia Institute of Technology. For the development of DAT, circulation and security rules were extracted from U.S, Courts Design Guide (CDG) [63]. CDG defines the criteria for federal courthouse design, based on best practices gained through the US Courts' experience from designing then occupying courthouses over roughly the last 100 years. 5.5.3. Rule preparation The Courts Design Guide was parsed and scanned and encoded to identify those statements dealing with circulation. 302 statements were identified. These were analyzed and grouped according to similar conditions, then translated into a set of computable parametric rules in DAT, that could address all of the circulation issues that were identified. Circulation rules are parameterized into four high-level

1028

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

Fig. 16. Table-based reporting. (a) Table-based reporting of SMC. (b) Table-based reporting of AEC3 XABIO (with permission of AEC3 UK Ltd.).

conditions: start space, intermediate space, destination space conditions and transition conditions. The space conditions have a space name and also a security level (public, restricted or secure). As shown in Fig. 19, transition conditions can represent security level, route walking distance length, vertical accessibility, etc. These are specified in a SMC parametric table. A circulation rule defined by the combination of these parameters becomes computer-processible for automatic checking using a SMC plug-in developed by Georgia Tech. 5.5.4. Building model preparation In the circulation validation module, a circulation data view is extracted for validation. End-users can define a building model using a BIM authoring tool according to GSA Series Six BIM Guide for Circulation and Security Validation [64]. The checking module relies on standard space names used in courthouses which also determines the security level of all assigned spaces, as defined in the CDG. In the IFC models, a security zone is associated with each space in a property set definition. Table 3 shows minimum modeling information requirements for circulation validation checking. These requirements are implemented as a pre-checking module using the SMC technology where space names, security assignment and connectivity of circulation paths are pre-checked.

Implementation of the circulation requirements involves the derivation of a circulation graph of the complete building, identifying all occupiable spaces and their interconnectivity, as defined by walls, doors, stairs, ramps, elevators and boundaries between directly adjacent spaces (without separating walls). Building model elements are automatically mapped to graph nodes and edges. Two types of graph are defined: (1) a topological graph represents connections between spatial elements (see Fig. 20). This graph was used to check routing paths defined in parameterized circulation rules. (2) The metric graph represents distances reflecting human movement paths within a space [65]. This graph is used to check moving distance between two spaces and to visualize circulation analysis results (see Fig. 21). Through the graph structures, circulation validation checking system can assess whether circulation paths between two spaces of the assessed building model satisfy the given requirements. This circulation assessment is an example of an assessment that deals with issues not easily handled on the basis of a building model itself. 5.5.5. Rule execution The pre-checker identifies any modeling or name problems before real checking is undertaken. The check involves a single module, not requiring management of views or modular rules.

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

Fig. 17. Graphics-based reporting. (a) Graphics-based reporting from SMC (permission of Digital Alchemy). (b) Graphics-based reporting of AEC3 XABIO and Octaga.

1029

1030

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

Fig. 18. Spatial program validation results.

Fig. 19. Table parameters for describing circulation rules of a design guide.

5.5.6. Rule reporting Since the rule checking is performed on the basis of interpreted parameters which are derived from the Courts Design Guide, the original circulation rules written in a natural language are provided in the checking results for end-users' confirmation. The circulation rule checking system developed for GSA provides a back-reference number to the section, page and line of the Court Design Guide.

Table 3 Minimum modeling requirements for circulation checking. Modeling element

Description

Space

Space names should be defined on the basis of Space naming conventions of GSA BIM Guide. Security zone should be one of “public”, “restricted”, and “secure”. This information can be defined as property definition for each space. Is part of wall. Door adjacencies to two spaces used for accessibility checking. Use of IfcStair and IfcRelContainedInSpatialStructure. A stair should be contained in a space. Stair may have components such as slab (landing) and flight A ramp should be contained in a space like stairs. Ramp may have components such as flight and slab (landing) Currently, elevator objects are defined through space name. For example, “judges elevator”, “prisoner elevator”. There is no special requirement. Just needed for space boundary.

Security zone

Door Stair

Ramp Elevator Wall

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

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

1031

Fig. 20. Reporting.

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

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

Fig. 21. Visualization of violated circulation route.

1032

C. Eastman et al. / Automation in Construction 18 (2009) 1011–1033

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

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

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

1033

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