A Hybrid Prescriptive-/Performance-Based Approach to Automated Building Code Checking
Charles S. Han[1], John C. Kunz[2], Kincho H. Law[3]
Abstract
In design standards and building codes such as the Uniform Building Code (UBC) (ICBO94) or the Americans with Disabilities Act Accessibility Guidelines (ADAAG) (ADAAG97), introductory provisions state the design intent or performance issues of a section, and subsequent prescriptive statements (provisions) outlining the methods to satisfy the design intent. Currently, prescriptive provisions are necessary to explicitly define a standard method to measure the design intent of a section of a design standard. As the provision statement becomes more prescriptive, the design intent is often lost or not fully captured. Consequently, ambiguity and inconsistency arise, thus making the design standard difficult to parse not only by computers, but for humans as well.
This paper examines a design-intent approach to design standards processing to alleviate some of the difficulties and complexities of the code due to its prescriptive nature. By focusing on the design intent, it is possible to negate the problems of indeterminacy and conflicting provisions in a building code. There are two major aspects to our design intent approach to design standards processing. First, capture the design intent per each section of the code. Second, formulate and model an adequate performance test of the design intent. The approach is to model the building code’s prescriptive statements where there is no indeterminacy and conflict, whereas when such problems surface, a performance-based approach is adapted. This work focuses on disabled access building code issues.
Introduction
Currently, design and construction documents submitted to the appropriate government agency are checked manually against a continuously changing and increasingly complex set of building codes. The designer must assess which building codes are applicable to a given project as well as sort through potential ambiguity in the building code provisions. An inspector must go through a similar process. In addition, interpretation of a given section of the building code may differ from inspector to inspector. The design checking and approval process can be a critical activity that prolongs the construction and delays the operation of a facility. Automating this process has the potential to alleviate both the delays and inconsistencies associated with manual checking by giving the designer and the permit-issuing body a consistent framework in which to apply and check codes.
Design standards such as the Uniform Building Code (UBC) or the Americans with Disabilities Act Accessibility Guidelines (ADAAG) are typically organized hierarchically where the design intent or performance issues are categorized at the higher levels while prescriptive statements are appended at the lower levels as descriptions. Prescriptive statements are needed to formulate concrete tests of the performance provisions. However, using prescriptive provisions often lead to problems in the building code of conflicting statements, thus making the building code difficult to parse not only by computers, but for humans as well. Taking a design-intent approach to design standards processing can alleviate some of the difficulties and complexities of a building code. By focusing on the design intent, problems due to indeterminacy and conflicting provisions in the codes can be avoided. The first task is to capture the design intent of a section of the building code. The second is to formulate an adequate test of the design intent.
This research examines a hybrid approach combining prescriptive-based methods in which prescriptive statements are modeled where there is no indeterminacy and conflict, whereas when such problems surface, a performance-based approach is adapted. There are several motivations for this approach. First, prescriptive-based provisions capture the design intent of the building code most of the time so encoding these provisions partially addresses the goal of automated building code checking. Second, encoding these provisions and analyzing the building model is computationally inexpensive compared to using performance-based simulations. Therefore, where the prescriptive-based provisions are adequate, they should be used. In addition, performance-based simulations may be difficult to develop to match the design-intent of the higher-level statements in a code. However, performance-based simulations should be deployed when encoding the prescriptive-based provisions is inadequate and where conflict arises. Finally, certain prescriptive provisions are difficult to model using a prescriptive rule-based system. In these cases, using simulation is necessary to test these provisions. If a building design is found to be in violation of the building code based on the encoded prescriptive provisions, the design can be analyzed against available performance-based methods.
This paper examines the disabled access code-related issues focusing on wheelchair access. The design intent of the disabled access building code is clear: provide the same or equivalent access to a building for physically challenged individuals as non-physically challenged ones. For wheelchair access, this means that a person in a wheelchair must have the same or equivalent access to a building and its facilities as a person not restricted to a wheelchair.
A Case Example
A proof-of-concept prototype demonstrates the feasibility of an online code-checking methodology (note that this prototype only addresses the prescriptive-based provisions and not the performance-based analysis described in the hybrid framework). The program checks the accessibility of a building design via the World Wide Web (WWW) in a client-server environment. On the client side, the user develops a plan using an International Alliance of Interoperability (IAI) Industry Foundation Classes (IFC) (IAI97) compliant CAD package. The user can at any time send this design to a code-checking program that resides on a remote server.
The code-checking program examines the IFC design data and generates a web page that has three frames (see Figure 1). The code-checking program generates a model of the submitted building design (see Frame 1) and adds redline information if the design does not comply with the building code. These redlines have hyperlinks to associated comments (see Frame 2). Finally, these comments, when applicable, have hyperlinks to the actual building code document provisions (see Frame 3), in this case, the Americans with Disabilities Act Accessibility Guidelines (ADAAG97).
The prototype implements encoded provisions at the building component level and, to a limited extent, at the system level related to door accessibility. Each building component is analyzed against a set of rules that capture the intent of the building code provisions. In most cases, a rule is some form of geometrical interference test.
This section examines the building code-checking process analyzing a case example building design (see Figure 2). The enhanced CAD environment that has been developed in conjunction with the code-checking program has the capability to output an abbreviated version of the IFC Release 1.0 project model (a fully compliant IFC Release 1.0 should be readable by our prototype). The code-checking program receives the building model data, analyzes this data, and generates a web page.
Relevance
The code-checking program assumes that the designer accurately annotates the spaces that need to be accessible. Once the code-checking program determines the spaces that are relevant to the provisions for disabled access, it checks the building components within an accessible space for code compliance.
Specifically focusing on door analysis, the relevance of accessibility provisions for a door is contingent upon the door connecting two accessible spaces. In the first pass, the code-checking program marks all doors that connect two accessible spaces as relevant. Note that door D1 in Figure 2 is not required to comply with accessibility code provisions since one of the spaces it services (space X) is not required to be accessible.
Encoded Provisions
Once the code-checking program has generated a set of doors for which the accessibility code is potentially relevant, it tests each door against the encoded provisions that pertain to door accessibility. Specifically, these provisions pertain to opening width, and pull-side clearance and push-side clearance (side clearances are included in these provisions) of a door. Checking the building model components against the encoded disabled access provisions consists of simple geometric tests—in the case of clearances, simple interference tests.
Doors D2 and D3 in Figure 2 do not comply with one or more of the encoded provisions. The code-checking program must now determine whether any of these doors is required for the building design to be compliant with disabled access provisions.
Relevance Revisited
Finally, relevance dictates that only one door needs to be accessible in defining an accessible path. Since the cardinality requirement for doors is that there must be at least one door that connects two accessible spaces, the code-checking program makes a second pass through the relevant set of doors, in this case, the doors that serve the same two accessible spaces. If one door has met the requirements for accessibility, the code-checking program marks it as being the accessible door. The ones that did not comply are marked as not meeting the accessibility requirements but not needing to in this particular design. On the other hand, if no doors in the relevance set comply, all are marked as in violation with the code with a note that at least one needs to be accessible.
Results
Partial results of the web page generated by the code-checking program are shown in Figure 3. The Virtual Reality Modeling Language (VRML) model displays redlines showing areas with code violations; the redlines have hyperlinks to the appropriate comments. These comments, in turn have hyperlinks to the ADAAG document.
Example Summary
As noted in the beginning of this section, in order for the code-checking program to correctly analyze the building components in the design, the designer must explicitly annotate which spaces are required to be accessible. If this annotation is correctly done, the prototype can successfully analyze the building components in a design against local geometrically related disabled access provisions.
The prototype only takes into account encoded prescriptive-based provisions. Performance-based methods are needed to address the following shortcomings of the prototype. First, it is possible that a design that does not meet the prescriptive code is actually accessible by a person in a wheelchair. Second, the prototype cannot handle global or system issues such as determining if an access path exists.
The next sections discuss the necessary attributes of the building model and the code model. Finally, we discuss the design intent-based issues for developing performance-based methods and the techniques applied to develop these methods.
The Product Model: The Building Model
Clearly, for automated design analysis there is a need for a standard building model that provides more information than a collection of drawing primitives. There are several possibilities. De Waard elaborates upon the General AEC Reference Model (GARM) to describe a model for residential housing (de Waard92). Currently, there is an effort by the International Alliance of Interoperability (IAI), a consortium of CAD vendors and other AEC industry partners, to develop standards for a project model that enables interoperability between applications by different software vendors (IAI97). The IAI defines a set of objects called Industry Foundation Classes (IFCs) that conform to current object-oriented philosophy (see Figure 4 for a sample of the IFC hierarchy).
This research uses the IFC Release 1.0 project model as our point of departure for our building model. IFC Release 1.0 currently defines two standard formats for sharing project data: standard file format and software interfaces (IAI97). In the prototype, the code-checking program takes an IFC project model in EXPRESS file format and sends it to the code-checking program.
The Process Model: The Building Code Model
The representational model implemented for the prescriptive-based encoded provisions uses the same structure as the IFC project model hierarchy. For example, all encoded provisions concerning door accessibility would be instances of a door accessibility class. Therefore, an individual component can be checked against all the applicable instances of provisions for that class of building component. Since IFCs are grouped into similar functional units, by design, we can group similar code issues. For example, doors and windows have egress-related provisions.
By structuring the encoded provisions in this manner, we loosely categorize building component provisions by design intent since similar building components have similar behavior. One building code class can have several instances that correspond to related provisions in the building code. For example, there may be a class in the building code representation corresponding to the issue of door clearance of which there are several variations or instances. This relationship is analogous to a particular building design having several instances of a door class. The prototype code-checking program currently implements the encodable provisions that can be classified as prescriptive checks. Provisions that address issues such as door width and door clearances are provided as heuristics that test for disabled access. If a door complies with these provisions, then it fulfills the design intent for accessibility. Otherwise, the door may not fulfill this design intent.
A more flexible approach would be to directly capture the design intent of a set of provisions and develop performance-based building codes and performance-based analysis. Simulations developed to address wheelchair accessibility are discussed in the next section.
Examining and Capturing Design Intent
Understanding the design intent of a building code is the first step for developing performance-based methods to directly test the design intent as opposed to relying on the prescriptive-based provisions to check for compliance. In the case of disabled access, the design intent is clear: provide the same or equivalent access for disabled persons and non-disabled persons. Focusing on wheelchair access, persons in wheelchairs must be provided the same or equivalent access to a building and its facilities as persons who do not use wheelchairs. “Equivalent” access is somewhat ambiguous, but the intent is that a person in a wheelchair need not go through extreme methods to be able to have access to a building’s facilities. For example, if a person not using a wheelchair needs to travel a certain distance to get to a bathroom facility, then a person using a wheelchair should have to travel approximately the same distance to use either the same or a different bathroom facility.
From the above example, it is clear that the concept of access is a system issue related to the entire floor or building as well as a local issue confined within a defined space. The encoded provisions can be used to analyze local prescriptive issues such as clearances around building components. However, testing for compliance of global issues such as the existence of an accessible path can be more easily done using simulation techniques. In addition, simulation techniques can be used to replace encoded prescriptive-based provisions to examine local access issues. For example, the motivation for the various prescriptive-based clearance provisions for doors is to ensure disabled access through a given door. Though following these provisions may ensure accessibility, a building design that does not comply with these provisions is not necessarily inaccessible. Therefore, there is a need to develop performance-based methods to test for local accessibility.
Developing Performance-Based Methods
Simulation addresses provisions that are difficult to analyze statically such as the existence of an accessible path in a building design. These provisions examine global issues of a project as opposed to looking at localized phenomena. This research has concentrated on developing simulations to test for disabled access. Simulations for other code issues such as egress and fire are also required to analyze a building system’s behavior. As in disabled access, egress is not a local issue, but a building or project system issue. One difficulty in using simulation is to accurately model the behavior of the participants.
In examining the issues of disabled access, the design analysis program must consider accessible path. For example, if a door is on an accessible path, the program can check its necessary clearances. However, since these are local and static checks, the program cannot guarantee that in getting from one room to another, even if the individual doors meet the code, a disabled person can actually get to these doors. Figure 5 illustrates the original case example with the addition of a barrier (the shaded block) that would comply if only local checks were made. Note that in this case example, all doors on the delineated accessible path comply with width and clearance requirements, but the introduction of the barrier clearly blocks the path into the goal.
Simulation of a wheelchair moving through the space is a logical approach. Using motion planning, a research area in robotics, such a simulation is possible (Latombe91). Here, a wheelchair agent is the robot that searches for a possible path. The robot is constrained to move only forward—this constraint is consistent with satisfying design intent concerning reasonable motion; the turning radius, another physical constraint is predetermined.