Integrating modeling into building design

Learning objectives  

• Learn how BIM, specifically Autodesk Revit, has evolved since its introduction. 
• Understand how Revit is currently being used to support virtual design and construction and design–bid–build procurement. 
• Review several general issues in the approach to creating detailed building models using AutoDesk Revit.  

The use of building information modeling in the design of buildings and building systems has become ubiquitous throughout the architecture and engineering industry and has transformed the way these firms work and the way construction projects are procured and buildings constructed.  

One of the key software platforms used by U.S. architecture and engineering firms in the generation of a model is Autodesk Revit, which has replaced Autodesk AutoCAD in its capacity as the tool for generating two-dimensional plan documentation. This change has taken place over the past 15 years, driven by the recognized value of using Revit to design buildings.  

AutoCAD had a similar impact on the industry when it was introduced in 1982, transforming the process of hand–drafting that required careful planning of how documents were created, updated and maintained, to a fully electronic format where the initial impact was that it that allowed for incorporating revisions without the loss of previously created work. AutoCAD’s capabilities expanded over time and ultimately included the use of pregenerated symbology (blocks) and details, standard layering formats that allowed filtering of the information exhibited on printed drawings, three-dimensional representation capabilities and more.  

The use of electronic documentation drove modifications in how that documentation was used. But in the end, AutoCAD is still only an electronic drafting tool that allows for the creation of line representation of objects, with limited intelligence to those objects. 

By contrast, Revit, which supports BIM, incorporates features that both advance collaboration and facilitate the design process. These features are a result of the database inherent in the software and include the ability for multiple individuals to work in the model simultaneously and visualize changes in real time, generation of material schedules right from the software, automatic creation of sections and three-dimensional views, generation of schematic systems diagrams from the model, automatic clash detection between elements and association of specific record data with any element in the model.  

As Revit use has further developed, users have added customized capabilities to generate building “fly throughs,” perform flow calculations and system sizing, output to automated quantity surveying/estimating software, coordinate the Revit database capabilities with computerized maintenance management systems software and even automate systems layout based on preset parameters.  

The ability to use the intelligence of the model to identify components, track locations, adjust layouts, generate lists and quantity takeoffs and identify clashes has expedited tedious tasks that were previously manually executed and required constant updating as changes were made. While custom schedules and data were available in AutoCAD, the data was only as good as what was built into the architecture, engineering and construction components.  

Now Revit families that capture a vast array of data or creating customized elements that embed the desired information allow a fully automated process using the power of the computer to keep track of changes as they are made. This power has transformed the computer from a role of “digital pencil” to that of a digital design assistant.  

A transformation? 

When Revit was first introduced, design firms saw the potential for the software to transform the design process, but as with any new tool, the transformation took some time to implement. Initially, like AutoCAD, Revit was used consistently with the design practices that were already in place; the status quo was the development of two-dimensional plan drawings to convey the design intent. Revit was used as a newer, better tool to create those plan drawings.  

Several of the key features noted above, including automatic clash detection, creation of sections and three–dimensional views and the ability to incorporate intelligent data within the elements of the model were immediately impactful. The use of other capabilities — most notably the generation of systems diagrams, materials schedules and performance of flow calculations — has necessitated a transformation in the way the design process is executed. 

The design process prior to the implementation of Revit had been optimized to produce a consistent two-dimensional design with as little repetition as possible. The mantra of the time was to “not show anything in more than one place,” a direction driven by the reality that any change could cascade through the entire set of documents if the information affected was shown in multiple places.  

In terms of MEP systems design, the typical approach was to document the main components of systems and identify the specifics in a diagrammatic fashion on plan views that allowed for location and quantification of components; detail was represented by specific elements in detail sheets, which attempted to remain as typical as possible so that they applied across multiple conditions. General spatial coordination of systems distribution was performed to understand the ability of elements to fit within the allocated pathways and document specific locations desired for visible components like lights, diffusers and sprinklers, but final coordination of distribution above ceilings and in chases was often left to the installing contractors.  

The ability of Revit to support multiple disciplines working in the model simultaneously (or through multidiscipline linked models, as is more typical for larger scale projects) to automatically create sections and three-dimensional views and to perform automated clash detection has upended that diagrammatic approach. Information contained in the model families or elements in one location can now be automatically represented in schedules, sections and details if the parameters and data is built into the families or content.  

Designers and contractors also immediately recognized the potential of the software to deliver a more comprehensively coordinated design from the outset, which expedites the contractor’s coordination efforts prior to installation. While creation of the two-dimensional plan “deliverables” identified in design professional contracts that had been the standard at the time were somewhat expedited by the use of Revit, calls to allow the contractor access to the model for coordination purposes became more typical.  

The transformation of the deliverable to include the model, even just for coordination purposes, in turn drove the designer to be more diligent in model coordination efforts and ultimately to develop the systems distribution to be more completely illustrated in the model. Portions of the distribution that had previously been illustrated only diagrammatically, such as the plumbing piping within a chase wall or the vertical drops and horizontal run outs to perimeter fin tube, were now being modeled down to the final connection fittings.  

This comprehensive illustration of the systems allowed for the automatic generation of component schedules and system schematics, the incorporation of flow and systems sizing programs and the use of quantity takeoff software for estimating from the model. It also represented an increase in overall effort by the designer.  

A coordinated deliverable 

Contractors and owners recognized the value of the model as part of the overall design process and soon demanded that the model be part of the deliverables. The ability to generate a complete and coordinated design model created a situation where the design professional was expending more effort to develop documentation at an earlier time in the design process than had previously been required. This resulted primarily from the illustration of the systems distribution in more detail then had previously been the norm.  

The industry benefitted in that designs were forced to develop more fully earlier in the project process. On the surface, the more detailed early–stage drawings appeared to show a more complete picture of the finished product. Expedited coordination of building elements within the model held the promise of expediting contractors’ coordination process in the field. The ability of the software to quantify components facilitated the development of cost estimates and the ability to generate bills of material.  

But there was inconsistency in the accuracy of what was being represented and how it should be used. The completed appearance of elements in the model did not necessarily bely the detail being represented at a given stage in the process. Information that appeared complete in many cases was still only representative of a work in progress. Software programs that took quantities from the model did not necessarily take into account partially completed work. Initially, designers turned over the model reluctantly with multiple disclaimers as to liability for and the expectation of accuracy. The estimating, installation and owner side of the industry wanted more. 

New contractual requirements were developed by the American Institute of Architects identifying standards for the way models were to be delivered and used. The demand for more accurate and comprehensive models only increased, as did the expectation that the model could be used in addition to and sometimes in place of two-dimensional documentation.  

Eventually, the demand for incorporation of the model as a deliverable became part of the norm. Models are now provided regularly to support coordination during the installation phase and owners are requesting the model as a final deliverable in ever–increasing frequency. To support this transformation, additional modeling standards have been developed by AIA, the National Institute of Building Sciences and the BIMForum. 

Level of development 

Many contracts now require the designer to develop and deliver a model as part of the project and go as far as to define what must be included in that model using the standards that have been developed. The standards are important in that they provide a consistent vocabulary for the discussion of what is represented in the model at any given stage. Crucial to these standards and the ability to understand what is being represented by the model is the concept of level of development.  

The definition of LOD for specific items was originally published as part of the AIA Building Information Modeling Protocol in 2008. AIA has continued to develop protocols for BIM since then and further definition of LOD has been advanced by the BIMForum starting with the creation of a LOD specification in 2011. Per the 2018 version of the BIMForum LOD specification, LOD is defined as the degree to which a specific element’s geometry and attached information has been thought through and which the project team (consultants, contractors, owner) may rely on the information when using the model.  

The use of the BIM LOD specification as intended by the BIMForum was not to establish a universal protocol for the sequence of model creation or to specify responsibility for the creation of various elements, but rather to define a vocabulary for each model author, firm or project team to define how developed and reliable their models are at a particular stage. The clear communication of what can and cannot be relied upon supports the use of the terminology in the creation of contracts. It should be noted that LOD never relates to the entire model, but only to specific elements individually within the model. This is an important concept as there will be elements at different LODs within the model during any level of completion, even at the final deliverable. 

Specific LOD definitions are provided in Table 1, including the AIA definitions.  

A graphical illustration of the concept of LOD progression from LOD 200 through LOD 400 is provided in Figure 1. 

The use of a consistent vocabulary in referencing what is represented in a model was necessitated when the model became part of the deliverable. LOD does not seek to define what is being provided as a deliverable or how to use a model, but only to serve as a tool in communicating the definition of what information is available within the model for the various elements contained therein. The task of defining the LOD of specific elements at the various stages of project delivery is typically addressed through the development of a BIM execution plan that is referenced in the contract.  

The execution plan serves as the tool that defines a common understanding of how the model will be developed, what information will be available at specific stages of progression and how the model might be used once completed. Within the execution plan, the LOD of various elements of the design at the milestone delivery stages will be defined. This allows the project team to understand how to rely on the model at each stage for the various purposes for which the two-dimensional documentation was previously used.  

As project delivery methods evolve, the use of BIM has become increasingly complex; design-bid-build procurement using the BIM as part of the deliverable requires a consistent understanding by all parties of what the model represents. Integrated project delivery methods can involve the subdivision of BIM development, with early stages of the modeling executed by the design professional while later stages are allocated to the installing contractor.  

Virtual design and construction methods seek to use the model to manage the procurement, construction and future operation of a project virtually to expedite the actual execution of those tasks.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.