LOD, are we there yet

After going through the [US]AIA  E203 document Draft (actually the G202 where LODs are described) and BIMforum's LOD Specification I got a bit excited. Maybe, just maybe, LOD is maturing and might actually be useful in a practical way.

To be honest it was Brian Renehan's excellent blog post Developing LOD (Level of Development) that made me think progress had been made. It clearly set out the differences between the original E202-2008 and the new E203-2013.

Mind you, the 20 odd pages that the [US]AIA Digital Practice Documents Guide took to describe LODs left me with the impression it shouldn't be this complicated. So I thought I would try and write a simplified, concise description of LOD. But when I studied it closer I found I couldn't follow the way some things were supposed to work, and felt there were some things missing.
I think I understand what is being attempted, but am not confident my reading of the literature is correct. And if I am having trouble understanding it, there must be others out there in the same boat.

So before attempting my "LOD for Dummies" post I thought I should write about my concerns to see if they are shared, or are, in fact, completely wrong.

Isn't BIM about Data?

In the [US]AIA E203 under every LOD description (except LOD100) there is the sentence:

 "Non-graphic information may also be attached to the Model Element".

"may"? I would have thought "non-graphic information" - i.e. data - would be a requirement for it to even be called BIM.

How do you derive information if there is no data, just geometric modelling? I call that 3D drawing, not BIM.

LOD100 is silent on "non-graphic information", but presumably it is not a requirement just like all the other LODs. Yet there is an assumption information can be "derived" from areas. Yet isn't area "non-graphic information" ? After all you can create a graphical representation of say a floor, without an area attached to it. That is what CAD software does.

And why are elements to be "graphically represented"? Don't we want them to be geometrically represented? Something that represents the critical 3D shape and size of elements. Strictly speaking an element can be "graphically represented" by a 2D symbol.

I find this approach strange and unnecessary. Why would you even distinguish between graphic and non-graphic information? The point of BIM is that they are tied together. You might as well use CAD and spreadsheets.

LOD 100 - how does it work?

The big one for me is I really could not follow how LOD100 would work in practice.

To recap G202 says:

“2.2 LOD 100 – Model Element Content Requirements.
The Model Element may be graphically represented in the Model with a symbol or other generic representation,
but does not satisfy the requirements for LOD 200.
Information related to the Model Element (i.e. cost per square foot, tonnage of HVAC, etc.) can be derived from other Model Elements.”

Firstly I don't see how "graphically represented in the Model with a symbol" helps anyone. Unless that symbol has data that can be extracted it is pretty much invisible to other softwares. There seems to be confusion between drawings and BIM.

But data is not mentioned as I discussed above. Shouldn't there be a requirement in the LOD100 description for gross quantities such as areas and volumes? How can estimating be done without it? Or is there an unsaid assumption all BIM software will have this anyway?

Perhaps the most significant part of the LOD100 description that it "does not satisfy the requirements for LOD 200". That is you allocate LOD100 to everything in the model that doesn't satisfy any of the other LODs. But of course that means LOD100 can't really be used for anything. You don't know if the element has been put in the BIM to just satisfy a documentation requirement, or as a work-around, or is actually a representation of something real. So I don't think that is the intention.

I don't understand what the process is for identifying information "derived from other Model Elements”. The example of lighting being costed on the basis of floor area is given. So OK, lights are not modelled, I get that. Therefore they are not in the BIM.
But how do you communicate that the quantity of lights is to be derived from the floor area? Is it something you put in the LOD table, or is there an expectation that data associated with floors includes information about lights (and all the other things derived from floor areas)? But then why does this need to be explained in the BIM at all?

Surely it would be simpler to say lights are not in the BIM model and leave it at that. In the costing example the estimator then knows not to rely on the BIM for information on lights, it will have to be calculated within the estimating process using other information. There is no need for the BIM to indicate what that other information is, as the costing expert the estimator makes that call. It is not up to the BIM to tell anyone how to do their work. It is just a resource, and the LOD table merely tells people what is in the BIM and how reliable it is.

So I really don't know what I am supposed to do to comply with an LOD100 requirement.

I understand it is supposed to provide notional information, but I can't envisage how the [US]AIA G202 definition might be used on a real project. 

LOD 500 - confused?

LOD500 has caused some confusion. Certainly Brian Renehan writes about it in his blog post.

To recap the [US]AIA definition in G202 is:

"2.6 LOD 500 - Model Element Content Requirements.
The Model Element is a field verified representation in terms of size, shape, location, quantity, and orientation. Non-graphic information may also be attached to the Model Elements.”

One area of confusion is BIM Use. By LOD500 uses like clash detection, time sequencing and costing are no longer in play. So it makes no sense to say an LOD500 element has these BIM Uses. About the only use left is Facilities Management. Yet FM is not a BIM Use the BIMforum LOD specification or [US]AIA G202 includes by default (although that doesn't mean it couldn't be included).

The other is the lack of definition around data. It may not be necessary to upgrade the element's graphical representation at all, because it already meets the LOD 500 definition. All that may be required is that data associated with the model element is upgraded to describe what was built or installed. But you wouldn't get that from the definition because non-graphical information is optional.

Like LOD100 I am pretty sure I understand what is being attempted, it is just not being explained very well.

Missing LODs

Not Everything is BIM

There is no method to describe things that aren't to be used even though they are in the BIM. Despite what others think we BIM authors don't create our BIM models purely for their benefit. At the moment our main purpose is the generation of printed drawings and schedules. Our BIM models also end up with design options and other deliverables (like GreenStar or LEED). This means our models contain things of no interest to anyone else, or the proscribed BIM uses. But how would they know?

Not Everything is in the BIM

The other missing descriptor is that there is no method to describe things that aren't in the BIM. In the [US]AIA guide there is a suggestion to use 'NM' (not modeled). But I think it should be integral to LOD descriptions.  It is just as important to know what is not modelled as to what is.  There should be an explicit way to say something is not in the BIM, not just a 'suggestion'  in the guide.

Is Creation of Construction Documentation a BIM Use?

One of the uses we are all using BIM for at the moment is for the creation of construction documentation - drawings and schedules.

Yet this is not mentioned as a BIM use. I'm not sure why not.

No-one builds straight from a BIM model. Some construction tasks might make use of the BIM model, like laser set-out and other surveying tasks, but drawings and schedules are still required to explain how, and scope what, is to be built.

Certainly authors of BIM models are using their model for this use. But could we say others are utilizing BIMs that are not their own for their documentation?

Possibly not. I can't think of an example where this happens. You might use some-one else's BIM for design or analysis (engineering or otherwise), but generally not for producing your drawings or schedules. If you did you would effectively be taking information some-one else is responsible for and presenting it as work you are responsible for. Something I would have thought should be avoided.

But using BIM for the creation of construction documentation is a valid use, and one that needs to be encouraged. I am constantly surprised at how few in the AEC industry use BIM to generate schedules, how many details are still done in isolation using CAD.

At the end of the day if the construction documentation doesn't match the BIM that BIM is going to be pretty useless, whether you are using it for design, analysis or anything else. Which is why this should be addressed as part of LOD. I always include "creation of construction documentation" as a BIM use. It may only be the authors using their own BIM for this use, but it needs to be stated, and participants need to be held accountable if they agree to it.

End of a Milestone is Too Late 

The [US]AIA E203  guide rightly says milestones are not equivalent to project stages (concept, schematic,  documentation  etc.). 

Their example LOD tables put these milestones are across the top which puts a practical limit on how many milestones there can be (otherwise they won't fit on a printable page). 

[US]AIA G202 LOD Table

This infers there shouldn't be that many of them, and further that all elements will probably meet the same milestones.

But the reality is BIM deliverables don't necessarily all happen at the end of a project milestone, and don't necessarily involve every element in the project. It is more likely certain elements will require a level of resolution before other elements can progress.
For example milestones might be the week number of a project stage, or if the program is not sufficiently defined divided into, say, 10 parts. Then certain elements can be targeted to reach their LOD level earlier or later.

 Brian Renehan suggested an alternative LOD table format in his blog post Developing LOD (Level of Development). I've created an example of a similar table below.

after Brian Renehan's LOD table

Milestones (MS) are a column, and LODs run across the top. LOD tables will then be a fixed width (i.e. LOD100 to LOD500) but allow a varying number of milestones per element. 

Certainly the LOD table structure in the [US]AIA G202 will work if there are limited BIM milestones, but I believe Brian's alternative provides greater flexibility.

Am I wrong?

Generally l believe the [US]AIA E203 Document conception of LODs is good. Restricting LOD 400 to only fabricated elements makes practical sense. As does utilizing LOD 500 to identify only those elements actually requiring field verification.
The BIMforum Specification has clear and concise descriptions of the [US]AIA LOD definitions, along with a sensible addition of an LOD 350 for installation information.

And to be clear I am not commenting on the whole [US]AIA  Digital Document set, only the LOD part. Nor do I consider it to be the only definition or only use for LOD. The LOD concept has a wider application than a single legal document in one country. But the [US]AIA E203 Document is a good starting point.

So I am supportive of the [US]AIA and the good work they have done. It is just that there are a few things that I believe don't quite seem clear enough to make practical use of LOD.

I'd be grateful if anyone can put me straight.