Over at the practicalBIM blog, Antony McPhee has provided a few very insightful posts about real world (ummm...practical) application of the levels of development (LOD) for modeling. His most recent post, "LOD, are we there yet?" raises some interesting questions that I'd like to address.
First let me share some background information. I am an active member of the LOD Specification work group. The establishment of the LOD Specification is just that - a specification. It is intended to be a baseline, or a minimum standard. Where there wasn't a clear methodology for modeling something to a particular level, we did not speculate on a single solution. Instead the Specification allows for additional customization to be appended to the baseline in a BIM Execution Plan.
Isn't BIM about data?
First topic Antony approaches is the notion of "non-graphic information" (as described in the AIA digital practice documents and the LOD Specification). Of course it's all about 'the I in BIM'... This is a known issue and despite the LOD Spec group working for over two years, we have barely scratched the surface in terms of standardizing which parameters or properties go with which levels of development. Luckily, we have the IFC schema and the Object Element Matrix (OEM) from the US Dept of Veterans Affairs (VA) to help us heading into the next version. (Refer to VA BIM requirements, and the OEM spreadsheet) We will be looking to incorporate some form of this type of required information matrix in the next version of the LOD Specification.
Oh...that one. I could write a book on this topic alone because the LOD Spec group spent so much time debating about this level. The initial assumption was that a system or component at 100 might not be modeled, but provided as 'non-graphic information' in a narrative or attached to other model elements. Wait...what? As an example, you might model a simple floor slab and assign a parameter for an allowance of structural framing per unit of area.
Another assumption was to utilize a massing model. This is something that most Revit users are familiar with, but could also be accomplished in SketchUp, Rhino, and so on. The first debate was whether to make a 'mass' it's own class of model elements like walls or floors. What does a mass at LOD300 look like?... End of that discussion. A mass is simply a medium to establish a level of development for some other element class.
After many weeks and months of deliberation, it was finally decided to keep it simple and maintain the relationship to the classification of system element. Think of it in terms of one step below LOD200 (generic placeholder). In a wall example, 100 would simply be a wall - not identified by type or material. At 200, you would at least distinguish between drywall and masonry, but not specific types.
Take a look at the final published version of the LOD Specification 2013 and you'll see the clearer definitions for LOD100.
What ISN'T in the BIM
Antony notes the absence of means to address elements in the model that are not to be referenced. That is good feedback for the LOD Spec group as we progress into the next version. It's always tricky to address something that isn't to be addressed...
Not necessarily in this section, but Antony asks about an object being "graphically represented." I think the intent is meant as "geometrically represented," but AIA might have been trying to be consistent with "graphic" versus "non-graphic." On the subject of using 2D symbols in the BIM, I will likely write another dedicated post on this topic based on my conversations with the BIM team at the US Army Corps of Engineers. In their Minimum Modeling Matrix (M3), they use LOD definitions along with a "grade." This grade allows an element to be either 2D or 3D. Read more about the M3 here.
What ISN'T BIM
This is a subtle difference from the topic above, but Antony asks how one addresses project content that is part of a deliverable package, but not in the model. This is a good question that was discussed quite often within the LOD Spec group. The simple answer starts with an equation:
Deliverables = Model + x
In this equation, x refers to anything else that might accompany a model being offered as a project deliverable. This might include drawings, specifications, napkin sketches, and so on. The LOD Specification addresses ONLY the "model" part of the equation - it does not serve as a guide to complete project deliverables in current work flows.
Now, if we are talking about certain building systems or components that are just not going to be modeled - for example, you might not be modeling furniture in your BIM - there are two ways to address this. One way is to simply not define an LOD in your project's BIM execution plan. The other is to devise some nomenclature to call out such omissions. Antony notes that "NM" (not modeled) could be used in the plan. Sounds like a reasonable solution to me.
Construction Documentation as a BIM Use
As I mentioned earlier, the LOD Spec is intended to be used as a measure of model reliability - if you will, the dictionary for the authors (modelers) and readers (recipients) of written works (models). It is assumed that BIM is currently being used throughout the industry to generate and deliver 2D construction documents, but the model itself is often not shared with estimators, builders, and so on. That is the focus of the LOD Spec.
The game plan for the LOD Spec group was much like the game Jeopardy - where you are given an answer and you have to guess the question. We did not want to explicitly state any BIM uses in the Specification; however, we did start with three uses common to the state of the industry today: 3D coordination, quantity takeoff, and on-site layout (see BIM.psu.edu for definitions of these uses). The definitions of the levels were developed in order to fit these common use cases, but not restrict project teams to only three use cases.
In the last section of Antony's post, he comments on the organization of milestones as columns versus rows in a table. He refers to another blog by Brian Renehan in a post titled "Developing LOD" in which an alternate method of documenting model milestones - with LOD's at the top - would allow greater flexibility with a project milestone schedule that is established on a weekly basis. If weekly milestones are used in reality, then Antony is correct in assuming that would not fit in a printable format, thus the need to flip the milestone table on its side. Personally, I've never seen such a detailed model progression schedule, and I don't think you would be able to get enough granularity out of the LOD definitions for that to be practically applied.