Category Archives: Building Information

Visualizing Building Information – Clash Detection

September 17, 2012 By in Building Information, Process Tags: , , , 1 Comment

One of the more useful applications of building information we’ve been experimenting with has been visualization. We first started experimenting with visualizing building data back in 2010. You can see a presentation I gave at KA Connect 2010 on the research we were doing on this front with SOM here. The research we did on that project has evolved into a full fledged web based tool that is helping them manage their thousands of gigs of BIM data production.

Since I’ve become obsessed with other applications of visualization. Let’s look at what it can do to clash detection or conflict analysis. This is an area I spend a lot of time on since it is at the core of our Project Consulting services. Model progress comparisons, conflict analysis, audits, craft, etc… are all critical parts of the continuous BIM data management responsibilities that go along with BIM project delivery.

Of course, the objective behind visualization is to help emerge some other interpretation of the data that can provide further insight, whether it be through a new pattern that is recognized, grouping, or something else. It must teach us something new by viewing the data from a different perspective.

Here are a couple of examples:

1. Plotting the x and y coordinates of clash instances

clash detection visualization by x and y coordinates

clash detection visualization by x and y coordinates

Though seemingly obvious, the above image helps us tremendously to quickly understand a simple clash test. By plotting the x and y coordinates of each clash instance, and coloring them by the discipline, we are able to quickly identify the area and model that have the most issues. On the image above, the lighting model has an area of severe congestion on the north-east of the building. Without having gone through every clash, I already understand, at a high level, where most of my time should be spent.

Conflicts by x and y

Conflicts by x and y

Similarly, on this analysis we see an x y plot that quickly categorizes the source files of the clashes by color, labels the elements by name, and indicates the severity of the clash by the size of the bubble. This analysis looked at conflicts between curtain wall components against the building’s superstructure.

2. Ranking BIM elements by number of conflicts and severity

BIM visualization by element clash severity

BIM visualization by element clash severity

This image takes each distinct BIM element and ranks it based on number of identified conflicts and sizes them by severity. From this, we are able to quickly assess the type of elements that may need the most amount of attention. Not to imply that clash quantity is the single source for qualifying a coordination issue, it is not, but elements that have a high number of clashes of high severity should be addressed.

3. Model version comparison analysis

BIM version comparison

BIM version comparison

In this case, we are comparing one model version versus a previous one. We are interested in seeing how much, and what has changed between submissions. We see, very quickly that on this MEP model, most of the work has gone into re-routing plumbing systems and relocating electrical fixtures. This can be incredibly helpful on large projects to understand model progress and keep an eye on craft.

Level of Development (LOD) is updated in E203

August 21, 2012 By in Building Information, Process Tags: , , , 3 Comments

In the past few months, I’ve been involved in several conversations on projects that want to move forward with model based delivery, but are having a hard time understanding the legal implications. What does LOD mean to us? Does everything have to be in the model? What if is wrong? Mostly, people are consistently nervous about having an external definition to their instruments of service.

The reality is that the LOD system is not meant to be a prescription, but instead a framework. Unfortunately, it is also very vague, and has failed to guide people in its implementation. This has led to general confusion and even dilution of the effort as some have even come up with their own interpretations, many of them just plain wrong.

I recently came across James Vandezande’s most recent post on this and found his explanation to be most in line with the realities of those who are implementing this stuff on non-IPD projects. Probably the most useful aspect of the post is that he swiftly debunks the incorrect definition of LOD in the E202 context as being ‘Level of Detail’ (to be fair it does mean that if you’re thinking of the computer graphics term, which only adds to the confusion). What I like is that he provides a clear explanation as to why it is incorrect and even misleading. He states:

DETAIL = INPUT

DEVELOPMENT = RELIABILITY

This is probably the clearest distinction I’ve seen out there on the issue of LOD. What is most compelling about it, is the fact that it brings the conversation back into the realm of actual project delivery. We are not talking about abstract modeling concepts anymore. We are talking about the documents, or artifacts, that are used to actually design and build. This is very important because it places the focus back on the intent behind the model and elevates the status of the model from somewhere above a physical model (usually only a visual aid), to somewhere just below the actual drawings. It grounds a model back within the realm of process.

The Louisiana State Museum and Sports Hall of Fame LOD400 model

An update to the E202 with E203

Coincidentally, at the end of last week the AIA also published their updated Digital Practice Documents E203 – 2012, G2012 – 2012 and G202 – 2012 for public review. In it, there are a lot of improvements, but off the bat, one caught my eye. Section 1.4 of the E203 document lists the definitions and there are many more this time around that in the E202. There are some that were there before too, but have now been updated. One of these is LOD.

The new version, the E203 (2012) defines LOD as:

The Level of Development (LOD) describes the minimum dimensional, spatial, quantitaive, qualitative, and other data included in a Model Element to support the Authorized Uses associated with such LOD”.

Versus the old version, the E202 (2008) which defines LOD as:

The Level(s) of Development (LOD) describes the level of completeness to which a Model Element is developed.”

The new version refers to two other terms, Model Element and Authorized Uses, whereas the old version only refers to Model Element. Authorized Uses was actually not part of the E202 document at all. Authorized Uses is defined as:

The term “Authorized Uses” refers to the permitted uses of Digital Data authorized in the Digital Data and / or Building Information Modeling protocols established pursuant to the terms of this Exhibit”

The new version more clearly defines LOD as the minimum information needed to support the authorized uses. This new definition clearly speaks to James’ definition and I’m glad it’s made its way into the new documents. The prior definition was definitely misleading in that it seems to imply a geometric completeness over its intended use. It is a very clear directive to tell someone not only that they can use a model for a particular purpose, but that they may rely on it for that purpose.

We’ll see how people take to it…

Delivering BIM for FM isn’t without cost

August 12, 2012 By in Building Information, Process Tags: , , , , 1 Comment

Don Rudder, our CTO and I presented at RTC recently on our recent work implementing BIM for FM solutions. The presentation focused on what we’ve learned over the past year or so implementing custom workflows and tools within two hospital systems, the Porter Replacement Hospital in Porter, Indiana, and Children’s Hospital in Birmingham, Alabama. Both of these projects were done with the Contractor as a client, not the owner. In both cases, the contractor was acting as a proxy to the owner in helping them get the most out of what BIM they had developed to date, for downstream use during operations. I also want to point out that both projects are the brain child(ren?) of Aaron Wright, Hoar Construction’s BIM Director. It’s been his dedication to figure out the real application of a construction model during FM that brought us on board on both of those jobs.

Although very different, both projects faced similar issues: purpose built models not quite meeting necessary requirements for FM use; model craft required for coordination is different than that required for FM; information requirements for one is not the same as the other, etc. The list goes on… In any case, we knew there was value in there, we just needed to figure out how to squeeze it out, or better yet, how to repackage it to make it useful downstream.

Probably the more interesting development in all of this was that many of the more common issues weren’t issues at all, but instead general misconceptions about BIM and its utility over the lifecycle of a building project. One of these misconceptions was:

The only cost associated with BIM is its creation

This statement supposes that once you have a model, you’re done. This is a huge industry problem right now and is causing a lot of unnecessary friction. First, it falls into the usual trap of thinking BIM is a product and not a process. Off the bat, you’re thinking that the cost of BIM is finite and that once you’ve paid for a model, you can move on to the next item on your list. This is very much incorrect, and misses the point on a lot of the potential value to be derived. Yes, there is a cost associated with modeling, but the model is only a part of the process, not the end in itself.

The big misconception, then, is in thinking that there is no cost to maintain a model.  Again, if BIM is a process, then the process itself has a cost. If the product of a Construction BIM process is to be used during an FM BIM process, then one needs to budget for two things: first the translation of the construction BIM to something useful in FM, and second, the process of maintaining that BIM over the lifecycle of the facility.

BIM during FM should be dynamic and constantly learning about day to day facility operations.  If it is not, then you will quickly find its value degraded to no more than a ‘snapshot of the facility at the end of construction’. Over time, there will be enough difference between the physical facility and the virtual one that BIM will be set aside and lose its privileged position within day to day operations.  That moment marks the death of a model in most cases.

If you want to learn more about cost, effort and value of BIM, I recommend you read Mario Guttman‘s “The Information Content of BIM“