Thursday, April 17, 2014

Hacking BIM

No, I’m not talking about the good kind of hacking, like the AEC Hackathon. I’m talking about the kind of hacking that steals your identity and buys a diamond necklace for some anonymous Russian mistress! The kind of hacking that sneaked into Target retailers and grabbed millions of PIN’s from register transactions. How did they get access? Through an HVAC contractor. The Target corporation felt there was a significant benefit from facility energy savings in allowing broader access and connections to heating and cooling systems. Does this benefit outweigh the potential security risk?

matrix-hack

A recent article in the New York Times by Nicole Perlroth (“Hackers Lurking in Vents and Soda Machines”) highlights a growing danger of hackers gaining access to corporate networks in some uncommon ways.

“They came in through the Chinese takeout menu.”

This got me thinking about the all-too-cool initiatives we are pushing in the AEC industry. Why not connect BIM to facility management (FM)? One of the most recent marketing emails I received is for YouBIM – a cloud-based BIM solution for facility management. Check out their introductory video. What happens when we start connecting all the players in the design and construction work flow with cloud-based BIM data? What happens to the benefit of ‘big data’ when it starts to communicate and co-mingle with consumer profiles? Food for thought…

Monday, April 07, 2014

NYC Revit Users Group: Mar 2014 Meeting

Continuing the tradition of extremely relevant content, the NYC Revit Users Group invited industry lawyer Rebecca McWilliams, AIA, Esq. (mcwilliams-law.com) to share some insight related to sharing our BIM data with others.

The recording is long, but here are some highlights along the way:

  • 0:42:25 BIM Execution Planning
  • 1:01:30 Risk management and standard of care
  • 1:18:00 LOD
  • 1:35:20 Managing owner expectations and ‘bad’ contract clauses
  • 1:41:00 Litigation case studies

Friday, March 07, 2014

Seattle Revit Users Group: Feb 2014 Meeting

The creative folks in the rainy city have established quite a nice following for their local Revit users group. The February 2014 meeting featured a panel of general contractors sharing their experiences with BIM implementation, including some intriguing ROI numbers.

The have graciously provided a recording of the event:

Monday, January 13, 2014

Spring BIMForum 2014: Call for Presenters

The next BIMForum event is scheduled for April 23-24, 2014 in Boston, MA, for which the theme is “Optimizing Design with BIM.” If you’d like to submit a speaking proposal, time is running out. Click here to begin a proposal, because the deadline is January 15. All you need is a title, some learning objectives and a brief summary of your proposed speaking topic. Presentation formats are in Pecha Kucha (20 slides, 20 seconds each), 20 minutes, or 30 minutes.

The BIMForum events committee is looking for individuals or project teams to share real world experiences that illustrate how BIM tools and workflows have improved the design process and/or the built environment. Architects, engineers and any other design professionals are welcome to submit a proposal.

boston-events-page

Registration for the event is also now open. Early bird discount ends March 1.

Tuesday, October 01, 2013

UK Commentary on LOD

I stumbled upon another excellent commentary on Level of Development (LOD) from Stephen Hamil (@StephenHamilNBS) from NBS in the United Kingdom. On his blog, Construction Code, he writes about the differences and similarities between the LOD Specification and various developments such as PAS (Publically available standard) 1192-2:2013, which defines levels of model detail (LOD) and levels of model information (LOI); as well as the RIBA Plan of Work.

Take a visit to Construction Code and let me know what you think.

Wednesday, September 04, 2013

LOD Spec: Do I have to model in progression?

Over the course of the first two years of development before the first release of the LOD Specification for BIM in 2013, the work group thoroughly discussed many topics related to the real world use of the levels of development. One such extended discussion focused on how architects or engineers might develop their model data through the various stages of design while adhering to a model element table using the standard LOD’s.

The initial assumption is to think of LOD as ‘level of detail;’ therefore, you might think you are required to model with a generic component first, and then swap it for a more detailed component later in the design phase. While this approach seems logical in accordance with much of the imagery you’ll see in the LOD Specification, it’s not how most of us work.

The correct way to think about this progression is in terms of the RELIABILITY of the information in your model. For example, you might start a project with your company’s model template that has all the standard wall types defined. You might progress through concept or schematic design using an assortment of these standard wall types, but the overall layout and scope of interior partitions is still in flux. In this case, you would define Interior Partitions to be at LOD 200 in the early stages of design, and then specify LOD 300 for the latter stages. How can this work if you’re using the same wall types through all stages?

The LOD 200 definition in the LOD Specification for Interior Partitions includes the definition: “Generic wall objects separated by type of material (e.g. gypsum board vs. masonry).”

This definition can serve as either a guide to the model element author (architect) to model to the minimum specification – or, it can serve as the definition of reliability for a recipient and end user of the model, such as an estimator. An end user may receive a model with highly detailed wall types, but because it is contained in an interim deliverable and the model element table established Interior Partitions to be at LOD 200, the recipient can only use the model data up to the level at which the partitions can be distinguished by type of material. The more detailed data is there – but it cannot be relied on just yet.

Here’s another example – in another blog post from Practical BIM, Antony McPhee uses an illustration from the AEC (UK) BIM Protocol in which a chair is shown at varying levels of detail:

LoDETAILexplained_500pix

Notice that the reliable properties are shown in red. Now, what if your practice only has the chair model as depicted under Component Grade G3? Can you put that component in your model if Moveable Furnishings was initially specified to be LOD 200 (the equivalent of G1 in the above image)? The answer here is YES. You can put the highly detailed chair element in your project model, but the project design has only been developed to a conceptual level at LOD 200. Therefore, even though it looks like a finished, rendered product, it can only be considered as a generic office chair.

Sunday, August 25, 2013

LOD Reply: PracticalBIM

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.

LOD 100

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.

Milestone Definitions

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.

I am happy to get some commentary on the milestone aspect of LOD use from those in other countries. Please continue to contribute to this important discussion either in the blogosphere or on Twitter using #LODSpec.