AECbytes Viewpoint #68 (May 16, 2013)
Jim Bedrick, FAIA, LEED AP
Principal, AEC Process Engineering
In 2008, I published an article in AECbytes entitled “Organizing the Development of a Building Information Model” in which I introduced the concept of LOD. At that time, the acronym stood for “Level of Detail,” a concept developed by Vico Software (then a division of Graphisoft) for its “Model Progression Spec.” Since then, a lot of work has gone into the LOD framework, first by the AIA California Council IPD committee and then by the AIA Contract Documents Committee, who adopted it as the core of its E202-2008 Building Information Modeling Protocol (see Figure 1) This committee evolved the concept into “Level of Development”—the difference is significant and is discussed below.
Figure 1. The Building Information Modeling Protocol in the AIA E202-2008 document.
In early 2011, the LOD Working Group was formed under the auspices of the BIMForum and began developing the LOD framework into a consensus-based standard that would be useful for defining, at the assembly and component level, the reliability of information contained in a BIM. This group divided the major building systems into four areas, and formed subgroups to address each area. In order to create the broadest possible consensus, each subgroup was co-chaired by a designer and a builder, and the subgroups’ results were vetted and integrated by a core group comprising all of the subgroup chairs.
The group first interpreted the AIA’s basic LOD definitions for each building system and subsystem, and then compiled examples to illustrate the interpretations. Because BIM is being put to an ever increasing number of uses, the group decided that it was beyond the initial scope to address all of them. Instead, the specifications were developed to address model element geometry, with three of the most common uses in mind—quantity take-off, 3D coordination, and 3D control and planning. The group felt that in taking this approach, the interpretations would be complete enough to support other uses.
The first draft of the resulting Level of Development Specification was released for public comment at the Miami BIMForum on April 24 (see Figure 2). This document is a reference that enables practitioners to specify and articulate with a high level of clarity the content and reliability of Building Information Models (BIMs) at various stages in the design and construction process. The LOD Specification utilizes the basic LOD definitions developed by the AIA for the AIA G202-2013 Building Information Modeling Protocol Form (part of a new series of digital practice documents the AIA will be publishing in conjunction with the AIA National Convention in June 2013) and is organized by CSI Uniformat 2010. It defines and illustrates characteristics of model elements representing building systems, assemblies, and components at different LODs. This clear articulation allows model authors to define what their models can be relied on for, and allows downstream users to clearly understand the usability and the limitations of models they receive.
Figure 2. The cover of the Level of Development Specification released at the Miami BIMForum.
The intent of the Specification is to help explain the LOD framework and standardize its use so that it becomes more useful as a communication tool. It does not prescribe what Levels of Development are to be reached at what point in a project but leaves the specification of the model development to the user of this document. To accomplish the document’s intent, its primary objectives are:
The LOD framework addresses several issues that arise when a BIM is used as a communication or collaboration tool, i.e., when someone other than the author extracts information from it:
The LOD Specification addresses these issues by providing an industry-developed standard to describe the state of development of various systems, assemblies, and components within a BIM. This standard enables effectiveness and efficiency in communication and execution by facilitating the detailed definition of BIM milestones and deliverables.
Level of Development vs. Level of Detail
This Specification uses the concept of Levels of Development rather than Levels of Detail. There are important differences.
Level of Detail is essentially how much detail is included in the model element. Level of Development is the degree to which the element’s geometry and attached information have been thought through—the degree to which project team members may rely on the information when using the model. In essence, Level of Detail can be thought of as input to the element, while Level of Development defines reliable output.
In 2008, the AIA developed its first set of Level of Development definitions in AIA Document E202™-2008 Building Information Modeling Protocol. Due to the rapidly evolving nature of the use of BIM, the AIA evaluated the E202–2008, including the LOD definitions. The result is the updated and reconfigured Digital Practice documents, AIA E203™–2013, Building Information Modeling and Digital Data Exhibit, AIA G201™–2013, Project Digital Data Protocol Form, and AIA G202™–2013, Project Building Information Modeling Protocol Form, which are accompanied by a detailed guide document entitled Guide and Instructions to the AIA Digital Practice Documents. The AIA’s updated Digital Practice documents include revised LOD definitions.
To help further the standardization and consistent use of the LOD concept, and to increase its usefulness as a foundation for collaboration, the AIA agreed to allow the BIMForum to utilize its latest LOD definitions in this Specification. The LOD definitions that are used in this document are identical to those to be published in the AIA’s updated Digital Practice Documents, with two exceptions.
First, the working group identified the need for an LOD that would define model elements sufficiently developed to facilitate coordination between disciplines—e.g., clash detection/avoidance, layout, etc. The requirements for this level are higher than those for 300, but not as high as those for 400, thus it was designated LOD 350. The AIA documents do not include LOD 350, but the associated Guide and Instructions references it.
Second, while LOD 500 is included in the AIA’s LOD definitions, the working group did not feel it was necessary to further define and illustrate LOD 500 in this Specification because it relates to field verification. Accordingly the expanded descriptions and graphical illustrations in this Specification are limited to LOD 100-400.
Fundamental LOD Definitions
The descriptions of the LOD Definitions are given below:
The definitions for LOD 100, 200, 300, 400, and 500 included in this Specification represent the updated language that appears in the AIA’s most recent BIM protocol document, G202–2013, Building Information Modeling Protocol Form. The LOD 100, 200, 300, 400 and 500 definitions are produced by the AIA and have been used by permission. LOD 350 was developed by the BIMForum working group, and is copyright to the BIMForum and the AIA.
Taking a light fixture as an example, its different LOD definitions would be:
LOD Definitions Explained
LOD 100, then, corresponds to a conceptual level. For example, in a massing model the interior walls may not yet be modeled, but we can use the approximate floor area to generate an area-based interior construction cost. Thus the walls are at LOD 100—they’re not modeled, but information about them can be obtained from elements that are modeled (the floors) coupled with other information (area-based cost tables).
To continue with the wall example, a floor plan is often first laid out using generic walls. The walls can now be measured directly, but the specific wall assemblies aren’t known and the quantity, thickness, and location measurements are approximate. The walls are now at LOD 200. To step back to the massing model, if generic exterior walls are modeled and can be measured directly, they are actually at LOD 200, even though there is little detail.
At LOD 300, the wall element is modeled as a specific composite assembly, with information about its framing, wallboard, insulation if any, etc. The element is modeled at the thickness of the specified assembly, and is located accurately within the model. Non-geometric information such as fire rating may be attached as well. This means that it’s not necessary to model every component of the wall assembly—a solid model element with accurate thickness and location and with the information usually included in a wall type definition satisfies the requirements of LOD 300.
At LOD 350, enough detail for installation and cross-trade coordination is included. For the wall example, this would include such things as blocking, king studs, seismic bracing, etc.
LOD 400 can be thought of as similar to the kind of information usually found in shop drawings.
The expanded definitions in the LOD Specification use the following interpretations of these terms:
The “Model Element Author” document does not prescribe who the author of a particular component at a certain LOD should be—the sequence of responsibility for modeling various systems will vary from one project to another. To accommodate for this variation, this document defers to the concept of Model Element Author (MEA) as defined in the AIA document E203-2013, Building Information Modeling and Digital Data Exhibit: “The Model Element Author is the entity (or individual) responsible for managing and coordinating the development of a specific Model Element to the LOD required for an identified Project milestone, regardless of who is responsible for providing the content in the Model Element."
A noteworthy caveat is that there is no strict correspondence between LODs and design phases. Building systems are developed at different rates through the design process—for example, design of the structural system is usually well ahead of the design of interior construction. At an early design milestone, the model will include many elements at LOD 200, but will also include many at LOD 100, as well as some at 300, and possibly even 400.
Similarly, there is no such thing as an “LOD ___ model”. As noted above, project models at any stage of delivery will invariably contain elements and assemblies at various levels of development.
The LOD framework enables effective and accurate planning and tracking of many aspects of the project delivery process. Here are several examples:
Mapping Firm Standards
This is a process of defining a firm’s standards in the LOD format. This definition provides the clarity necessary to ensure that project teams develop model elements to the detail that’s required without wasting effort on detailing that’s not needed. For firms without existing standards, the LOD Specification provides clarity that greatly facilitates standards development.
Some examples are:
These standards form an effective baseline for the definition of project-specific milestones, deliverables, and information exchanges.
Scoping Modeling Effort
The standards noted above provide a clear basis for determining the effort needed to develop required model(s). When additional modeling functionality is contemplated, comparison with the baseline enables accurate and transparent determination of the cost and time needed to develop it.
Developing a Baseline Design Schedule
This is done by defining standard milestones using one or more of the firm standards mapped out as described above, and then assigning dates to them. Often the starting point is the architect’s standard, since it is the architect that’s responsible for overall coordination. Once the baseline is laid out, any changes needed for the specific project can be clearly identified and accommodated.
Defining Use-Case Milestones
Modeling use in supporting a specific function will usually have several associated milestones. For example, the estimating function may have several budget check points specified by the owner as well as project delivery estimates such as a GMP, bidding documents, or an IPD target cost. The LODs for use-case milestones are set according to the precision needed to generate the information required for the milestone.
Setting Milestone Dates Based on Standard Workflow
If the team wishes to stay with the standard workflow as defined by the baseline schedule, use-case milestones can be compared to the baseline, and dates for these milestones can be set according to when the necessary LODs will be available.
Determining Workflow Based on Milestone Dates
If certain use-case milestones have critical dates, they can be inserted into the baseline according to those dates. This will clearly indicate any systems whose development will need to be accelerated in order to meet the milestone dates.
Defining a Design/Build Bridging Package
In this form of project delivery, the “bridging” can happen at a range of points—often at the end of Design Development, but in some cases as early as partial Schematic Design. Defining the bridging package through the LOD Specification enables the owner and the preliminary designer to be clear on both the scope of the preliminary design effort and the level of completeness of the information the owner will have to pass on to the design-builder.
Defining a Design Architect – Executive Architect Transfer Package
On projects where these are separate entities, clearly defining the transfer package through the LOD Specification can eliminate unnecessary uncertainties in the design as well as much redundant work.
Passing a Model from Design to Construction
It is still common practice for contractors to re-create a model from scratch, at significant cost, for use in construction tasks such as estimating, system coordination, and layout, even when the design team has already created a detailed model. However, on many current projects, the teams are able to avoid much of this cost by passing the design model on to the construction phase, the contractor adding the necessary construction detail to the existing model rather than building a new one.
The LOD Specification enables this handoff by clearly stating, at each defined milestone, both the allowable uses and the precision of model elements representing various components of the building. This process works best if the architect and contractor agree on LOD-based milestone definitions at the beginning of the modeling effort. Alternatively, the contractor can define its own needs in models to support various use cases as firm standards. Then if the contractor comes on to a project after modeling is underway, its standards can be compared to the project milestones. This comparison will show any gap between what is available and what is necessary, and the effort needed to fill the gap can be scoped and fairly priced.
Defining Facilities Management Models
Facilities management includes many functions, with widely varying needs from models. For example, support of remodeling and repurposing of a building requires a complete construction model, some of it field verified. Space and asset management, on the other hand, usually doesn’t require more from a model than the visible geometry of the spaces as a base for CAFM information. In order for the owner to be assured of getting the model(s) it needs without paying for non value-add effort, the FM functions to be supported are selected, and then one or more supporting models are defined via the LOD Specification.
At the time of this writing, two software vendors, Assemble Systems and Autodesk (in its BIM 360 Glue offering), have initiated implementation of the LOD Specification in their applications. Both vendors are developing functionality to support the uses described above through tabular and model views of the LODs of individual elements within a model. Assemble Systems plans to roll out its initial LOD capabilities at the end of May.
While the LOD Specification is intended as a reference that can be cited in agreements such as contracts and BIM execution plans, it is recognized that the use of BIM in design and construction is evolving rapidly. To accommodate this evolution, the Specification will be updated periodically in clearly identifiable versions. Initially the target frequency is annually, but that may change in the future. In addition, interim updates may be issued if needed.
The LOD Specification allows both interim and final models to be fully and clearly defined, an endeavor that until now has been vague at best. For any BIM effort, this enables the generation of higher value deliverables, avoidance of unnecessary modeling effort, vastly improved planning and tracking, accurate and fair scoping and pricing of modeling effort, more reliable models, and the ability to leverage models for more purposes, all leading to improved efficiency and significant cost savings.
Between now and June 7, the BIMForum LOD Working Group is seeking public comment on the first draft of the Specification. This can be downloaded from www.bimforum.org/lod, where you will also find instructions for submitting comments.
Jim Bedrick, FAIA, is principal of AEC Process Engineering (www.aecpe.com), a consulting firm focused on Integrated Project Delivery, Virtual Design and Construction, and collaboration. A registered architect, Mr. Bedrick holds degrees in Architecture and Electrical Engineering, and has over 30 years experience in the AEC industry. After practicing architecture for ten years, he moved into the design and management of information systems for architecture firms. In 1998, he joined 3Com Corporation, directing information technology for their worldwide construction and facilities management division. In 2001, he joined Webcor builders, where he led the development and implementation of both Virtual Building processes and technology, and the company’s Integrated Project Delivery capabilities.
Mr. Bedrick is active in many organizations, working to advance collaborative tools and processes for the AEC industry, including Stanford University’s Center for Integrated Facilities Engineering, the International BuildingSmart Alliance and the American Institute of Architects, where he serves on the Contract Documents Committee and is a major contributor to the Integrated Project Delivery effort.
Note: The views expressed in Viewpoint articles are those of the individual authors and do not necessarily reflect those of AECbytes. Also, AECbytes content should not be reproduced on any other website, blog, print publication, or newsletter without permission.
Have comments or feedback on this article?
Visit its AECbytes
blog posting to share them with other
readers or see what others have to say.