Real BMP - Best Modelling Practice

In my last post I wrote about Minimum Modelling Requirements, and the lack of standards around what that encompasses. But looking at examples of Minimum Modelling Requirements, and BIM Management Plans generally, it strikes me that the majority of their content describes what I would call competent modelling practice.

I can't help thinking that if we BIM authors modelled properly all this would be unnecessary.

But is it such a big deal? Sure it annoys me that someone else is telling me how to do my job, but I could just ignore it.

The problem is the bomb shells hidden inside Minimum Modelling Requirements. Like "all walls will be modelled floor to floor", "all door hardware shall be modelled", "components shall be named as per the owners FM requirements", etc. But what do we expect when non-experts get involved in areas they know little about?

How about we BIM authors take back the initiative by setting our own Best Modelling Practices, our alternative to BIM Management Plans.

We should be doing it anyway to get our in-office teams working efficiently. Unfortunately the reality is that few firms allow the resources necessary. Management see it as an in-house overhead with no tangible benefit to the bottom line.
But what if BMP is escalated to being a requirement necessary to achieve BIM deliverables? That it is not just an office "CAD manual" but a description of the limits of your BIM deliverable. An antidote to the unlimited scope of work a BIM Execution Plan can trap the unwary player into. 

There will never be standard BIM Best Modelling Practices (despite the efforts of the standards junkies). Different BIM softwares (and different versions of the same software) require different approaches, also BIM competencies and BIM requirements differ. But really the details don't matter. If BMP cover appropriate issues and are well structured they will be adequate to achieve their aims.

What are the basics of Best Modelling Practice?

CATEGORIES

All BIM software categorizes elements. Called Categories in Revit; Layers, Levels, and the like in other softwares. It  is the name given to elements with a common function and behaviour, like Walls, Ceilings, Doors, Furniture etc.

It is fairly obvious that it is important the same things are identified together. That when you make only walls visible all you can see are walls, not kerbs, beams or parts of windows; when someone does a wall schedule it only lists walls; when thermal analysis is done walls can be identified by the thermal analysis software.

Sounds pretty straight forward yet it is amazing how often you will find a floor used for a ceiling, a floor used for beams, windows used as doors. Then there is the ambiguity that plagues furniture, joinery (casework), fixtures and equipment.

Make a list of your software's categories describing what each is to be used for. This list can be just for your office, discipline, or across all disciplines for a project. If it involves other disciplines list which discipline is responsible for which category.

If categories in your software are user defined, (Revit Categories are fixed, but ArchiCAD Layers are not), institute a method to manage parameters to prevent new ones popping up in an uncontrolled way. This can be a shared spreadsheet, project model manager, or the office BIM tyrant, (sorry . . . BIM Manager). 

If there is a hierarchy of categories (Revit has user defined subcategories), try and manage those as well.

PARAMETERS

Sometimes called attributes or properties. Basically the names of data fields used to contain data about elements, like Thickness, Material, Model Number etc. At the simplest level these are used to generate schedules, but may also be used for analysis, and to provide data to others for their purposes (e.g. FM).

There can literally be thousands of parameters in a project. For Doors alone it can run into the hundreds. Some try and list every conceivable parameter that anyone may possibly use one day. Some insist parameters follow a labyrinthine naming schema that only computer scientists understand (both of which happen if you get a "BIM consultant" involved). This is clearly ludicrous (see my COBie post).

The reality is that if you have managed parameters you can convert them to any other system. For example you don't need to use COBie names to export COBie, you just need to know which of your parameters correspond to the appropriate COBie attribute.

Start with a naming schema for your parameters. Even if they are only for internal use it is good practice to make your parameters identifiable as yours. The most common method is an abbreviated prefix, e.g. PB_is Existing.

Also insist naming be major - minor - subminor etc. so similar things list together; instead of Door Type, Frame Type, Glazing Type use Type Door, Type Frame, Type Glazing.

Next list the parameters needed to create your schedules, which, when you think about it, is just a list of schedule headings. This list forms the master list of parameters.

Then institute a method to manage parameters.  The best way is to limit who can create them, like the project model manager, or make someone responsible for schedules in your project team. 

A word of warning - don't overdo - remember every piece of data not only has to be put in, it has to be managed, checked and kept up to date.

MODEL CONSTRUCTION

Model Construction is about the limits on how things in a model are constructed.

This is a fairly fluid area which tends to change depending on the abilities of those working on the project, expectations of others, and limitations of software (which changes with each new version). It is also hard to make hard and fast rules. Whilst modelling down to 25mm might be OK for doors and windows, it is overkill for facade systems and equipment. Never the less it is worth establishing guidelines to help those modelling make consistent decisions and inform those receiving models what to expect.

An effective way to begin is to make a list of things that are ambiguous; the things users ask about, the things users do not do consistently. Work out what the alternative answers could be, and then pick one. Don't worry too much about being right or wrong. No-one really knows what will work or won't, we are all still grappling in the dark. And rest assured, if something doesn't work someone will tell you soon enough.

Some suggestions to start with:

• Thicknesses: actual material thicknesses or a 'zone'?
  actual thickness mean dimensions are too precise (eg. 92 instead of 90);
  zones reflect reality - there is always tolerance, but then do you;
  - 'fake' a material thickness - which ones - structure or finish; or
  - add 'tolerance' materials.
• Minimum size: what is the minimum size that will be modelled?
  what is identifiable on a 1:100 or 1:50 drawing; or
  actual size 50mm or  25mm;
• Type of things not modelled:
  fixings (bolts, screws, fixing plates etc);
  materials or objects smaller than (materials thinner than 5mm, pipes < 25mm OD);
  controls (buttons, switches etc), hardware (handles, hinges, latches, hooks etc.);
  certain elements (reinforcing bar, single wire runs, etc).
  other's work (ducts if you are an architect, plant room walls if you are an engineer).

This list is not exhaustive, some projects will suggest different things.
If you are worried about the imprecision of it all, make general statements, like "model elements will generally not contain parts smaller than 25mm".

NAMING

Lots of things in BIM software have user definable names. From wall types to fill patterns. If you are providing your BIM model to others your names will need to be navigable.

But that said, exact naming conventions is not that important to others outside your office. What is important to them is that naming is consistent and understandable. That the same thing does not exist under multiple names (e.g. same wall construction with different names); that names are human understandable by someone other than those that have memorized some archaic abbreviation system; that some computer friendly / human incomprehensible naming schema has not been used.

Another trap is to use project specific notation for names. Like wall type codes to name wall types. Not only do you have to be familiar with the project's wall codes to know what you are looking at, if the code changes you have to change the name. And what do you do early on in the project, before wall codes for the project have been developed? What do you call them then? And if you think you can create a master list for all projects think again. World experts can't do it (see section on Classifications below), and if they could why wouldn't you use theirs instead of making your own up?

My point is any naming schema must work during design phases, before codes, schedules etc have been established. And they should not encode information available elsewhere as a parameter. The worst case I have seen is COBie's suggestion that components have the room they are in embedded in their name. What happens if they are moved to another room?

So names of things should describe, using normal language, what they are. But be brief, you don't want names so long they don't fit on the screen. Structure names, major - minor - subminor etc. and use punctuation characters and capitalization to make them understandable.

Example Wall Type names.
<interior|exterior>.<Partition|Stud> <OA thickness> _ <exterior material / structure / interior>

CLASSIFICATION 

Classification systems attempt to provide everything with a unique identifying number (or number/letter combination). The two biggest in the english speaking world are the US Omniclass and the UK Uniclass.

Classifications should probably be first on the list, but at the present time classification systems are not quite there yet. These systems were originally established for specifications and other AEC reports. As it turns out they are not that comprehensive, nor logical enough to be computer useful.

UK's Uniclass is more BIM friendly (according to them), but has many unfinished parts to it. The US's Omniclass is not as well structured for BIM, nor complete. Revit had to add non-Omniclass numbers when they introduced the ability to assign a value to Revit elements. And just to confuse everyone Omniclass includes tables called Uniformat (which is what the Assembly parameter in Revit is assigned to).

But in the long term everyone will be better off if we all just use one or other of these systems. It makes our BIM models discoverable without us having to do extra work, like follow the contractors or owners naming schemas.

I recommend getting into the habit of assigning Omniclass (incl. Uniformat) or Uniclass numbers to elements (pick one, don't mix them up!). Components (e.g. Revit families) should have them when constructed as a matter of course. Standard walls, roofs, ceilings etc. in template files should also have them filled in.

But there is no point insisting all project generated elements have a classification if it is not a deliverable. However by having pre-made elements pre-populated you will be more than halfway there when it does become a deliverable. 

SUMMARY

To set your team up for Best Modelling Practice you need to ensure:

• Categories are used consistently
• Parameters are logically named, and there are sufficient to do the tasks required, but no more.
• Model Construction limitations and practices are defined.
• Naming of all things is structured and human legible.
• Classification numbers are assigned, where convenient.

And the best way to do this is to document how each of these will be achieved.

Not only can this documentation be used to manage your in-house team, it can form the basis of a full BIM Execution Plan, or your contribution to a project BIM Execution Plan.

So what are you waiting for, start your BMP today.

Postscript:
I don't claim to be the font of all BIM knowledge. I'd be keen to hear from anyone who knows of other important Best Modelling Practices I may have missed.

Minimum Modelling Requirements

The basis of BIM as a process is that information created by a participant for their purposes can be reused by others to assist them with their purposes.
For this to work 3 things have to happen:

1. The information has to be there at the time it is required (i.e. is actually generated).
2. It needs to be in a form useful to others (i.e. they don't need to re-create it)
3. It needs to be reliable (at least for the purposes others will use it for).

The last is covered by LOD, the middle one is covered by designating software, or use of standards (like IFC), and the first is covered by Minimum Modelling Requirements.

The first requirement is the most important - the others have no meaning if the information doesn't exist - yet it is the least discussed and tackled by industry bodies. There is endless discussion and work being done on openBIM, COBie and the like; LOD is becoming mature and is now appearing in agreements and contracts.

But where is the clear definition of Minimum Modelling Requirements? Certainly many owner groups have tackled this issue and come up with their own solution - they have to, they operate in the real world where results are a necessity. But where are all the bureaucrats, academics and standards junkies?

Am I being unfair? - probably. I don't really believe the issue is being totally ignored. But the reality is where do I go to get practical advice on Minimum Modelling Requirements? Surely there is a better way than just referring to publicly available owner's attempts at solving the issue (and I say attempts because there is no way to assess how successful they have been).

Like all things BIM different participants have different views on what Minimum Modelling Requirements means. From owners who think it is just about ensuring they have a BIM based FM system at the end of the project to BIM mangers trying to get their team to model consistently.

Delineating Minimum Modelling Requirements

So let's start by trying to list what Minimum Modelling Requirements could include.

WHO

Who are Minimum Modelling Requirements directed at:

• others so they can meet their own Minimum Modelling Requirements 
• others documentation needs 
• others analysis needs
• construction needs (clash, sequencing)
• costing 
• FM 
• your own needs (like documentation, analysis etc)

TYPES of INFORMATION

What are the types of information Minimum Modelling Requirements applies to:

• element categories 
• element geometry 
• degree of detail (how much)
• degree of precision (how small)
• data (parameters)

WAYS to DEFINE

What are (some of) the possible ways to define Minimum Modelling Requirements:

• text description 
• table / matrix 
• no definition, just suitable for end use

WAYS to ENFORCE

How might Minimum Modelling Requirements be enforced:

• contract deliverable (forced)
• scope of works in agreements (offered)
• included in BIM Execution Plan (agreed)
• industry expectation ("reasonable professional" would provide)

COMPLIANCE

Once Minimum Modelling Requirements have been established how might they be checked for compliance:

• human sign off
• computer checking
• fit for purpose

Note that these lists are not all unique methods, some are alternatives that on the surface seem to have the same purposes. Nor exclusive; more than one may be utilized. But of course different methods will have different outcomes.

Different participants will use different methods to achieve what they believe are their aims. Owners like using end use / fit for purpose type methods as it shifts their responsibilities onto others. BIM managers like using highly specific software dependant requirements that can be computer checked because it makes their job easier (and they like using computers).

Current Examples

A comprehensive analysis of all attempts at Minimum Modelling Requirements would be a PHD in itself, and be out of date before it was finished. But I'll endeavour to show examples of different approaches to the issue.

MPS - VICO Software (US commercial)

VICO is an example of a number of commercial firms providing BIM planning services. They call their Minimum Modelling Requirements product Model Progression Specification (MPS). They also offer many other services around this so it is not a matter of simply purchasing a copy and using it.
I can't go into the specifics about their MPS as I have never used it, but it seems to be an elaboration of the [US]AIA E209 Document LOD table (the E209 document is actually based on VICO's MPS).
Commercial firms effectively make you pay to utilise their experience. But they also offer a service - they do some of the work someone in the team would otherwise would have to do. It is therefore hard to say if their success is due to the experience they bring or the extra manpower. I suspect it is both.

M3 - USACE (US government body)

The USACE (U.S. Army Corps of Engineers) Minimum Modelling Matrix (M3) is used by the US military to manage BIM construction projects. It is an example of owner created Minimum Modelling Requirements. It is freely available at their BIM web portal (with free registration).

The M3 relies on Uniformat 2010 codes being associated with every element. Uniformat 2010 is a hierarchical classification system that includes 'headings' that apply to multiple elements. The M3 has designated Levels 1 to 3 to these headings, with only Level 4 applying to individual elements.

As an example:

• Level 1 is all equipment and furnishings (E);
• Level 2 is equipment (E10) and furnishings (E20);
• Level 3 is Commercial Equipment (E1030);
• Level 4 is individual equipment type like Hospitality Equipment (E1030.50).

The M3 has a separate table for Levels 1 and 2 where general text descriptions of what is required are listed against each element 'heading'.

USACE M3 level descriptions

The other table has all Levels in a tabular format. Levels 1, 2 and 3 are just headings with little information against them, Level 4 is for elements, with a range of columns against them.

USACE M3 example

In terms of  Minimum Modelling Requirements the columns for LOD and Grade are of interest.

LOD means what we now expect it to mean - it indicates the level of certainty required of that element and is defined in terms of the [US]AIA E209 document. But only LOD 100 to 300 are given a definition, and in this table LOD is not associated with a milestone. Yet the other column of interest, Grade, is. But only for Construction Documents and As-Builts.

Grade sets how elements are to be graphically represented:
A   3D + facility data
B   2D + facility data
C   2D only (drafting, linework, text and or part of an assembly)
+   original grade modified
-    not included or tied to the BIM model (however is still required in the deliverable)
●   Refer to the other Levels 1 & 2 table, or is a heading (Level 3).

M3 definitions reflect strongly back to documentation. Many Level 1 and 2 requirements include
"... elements shall be depicted with necessary intelligence to produce plans, sections, elevations and schedules ...". LOD 300 includes "Accurate to the degree dimensioned or indicated on contract documents".
Other types of description are also found, although not consistently across all definitions. Things like "Small diameter (less than 1-1/2” NPS) field-routed piping is not required to be depicted in the Model", and "Slabs shall be developed in the structural model and then referenced by the architectural model".

So the M3 defines:

• General modelling requirements (using text)
• Type of graphic (2D or 3D) and whether data included. (using a table)
• LOD (sort of, surely LOD changes between Construction and Record models)

As you can see it is really quite a mish-mash not only of methods, but also mixes documentation with BIM requirements.

Despite this the USACE M3 is often quoted as one of the best examples of Minimum Modelling Requirements freely available. From a practical sense I tend to agree. They are making a good attempt at encouraging BIM in an industry not yet geared up to provide it. Which is its Achilles heal when it comes to taking lessons from it. The M3 is not necessarily best practice for BIM proficient participants. In fact I believe it has the potential to hinder BIM use. But it is (so far) an evolving document and well worth keeping an eye on for future developments.

LOD Specification - BIMforum (US industry group)

BIMforum is a US based non-profit industry group. There are many of these, but BIMforum is worth a mention because they have recently released an LOD Specification.
This document was created in response to the [US]AIA E209 document and directly uses its definitions.

It lists elements using the Uniformat classification system, and against each element there is a list under the title of   "Element modeling to include:"
Like the USACE M3 it is hierarchical, but simpler. Higher order classifications contain descriptions that are typical referenced back to by lower order classification that don't require further modeling (typically for LOD100 & LOD200). Further, if an element has the same requirements as another, it references back to that earlier element rather than repeat the same information.

BIMforum LOD Specification Example

Strictly speaking I shouldn't include BIMforum's LOD Specification in a discussion on Minimum Modeling Requirements. LOD is supposed to be about what information can be used with certainty - not what information exists.

But one way to define what can be used with certainty is to describe the minimum amount of information required to meet that certainty. This method becomes a de-facto description of Minimum Modeling Requirements: if you do no more than meet the LOD Specification requirements you will have met your LOD obligations; if you have done more than that, others can only reliably use what the LOD Specification describes for that LOD.  

But BIMforum admit their LOD Specification is not intended to be for Minimum Modeling Requirements. In the LOD Definitions sections it list two examples of areas not covered: Size Thresholds and Clearances,  inferring there are others also not covered.

LOD is often mistaken for, or assumed it can be used for, Minimum Modeling Requirements. An instance of which I discussed in my last post.
That said they both make use of the same information - descriptions of element modeling. There may be a way to leverage this to reduce the amount of information necessary to define Minimum Modeling Requirements.
But I believe it is important to remember that LOD by itself is not enough to define Minimum Modeling Requirements.

DPoW  - BIM Task Group (UK government)

The BIM Task Group is a government body in the UK with the aim of "helping deliver the objectives of the Government Construction Strategy and the requirement to strengthen the public sector’s capability in BIM implementation".
I came across one of their draft documents while researching this post. Its name "Digital Plan of Work (DPoW)" [follow the links - requires registration] made me think it might be a good candidate for defining Minimum Modeling Requirements. Particularly as it may possibly be an extension of an existing body of work by the RIBA on building design and construction processes (RIBA Plan of Work).

But alas, I was disappointed, not surprised, but disappointed at another lost opportunity.
Admittedly it is a draft, but the problem is with the whole focus of the document, nothing a few tweaks are going to overcome.
Beside some items that probably should be in another document it is dominantly a proposal for computer based checking of COBie data submission.

For a start COBie is no-where near being a way of defining Minimum Modeling Requirements. COBie is only about data, not geometry, not end uses. It is a standard way of structuring data, it actually says nothing about what that data needs to include (see my post for more on COBie).

As a strategy, computer based checking is problematic. To do the checking some-one has to set up a checking system. That system will have its own requirements. So there needs to be Minimum Modeling Requirements Checking Requirements defined. And how is it checked that these Minimum Modeling Requirements Checking Requirements have been met?
Assuming the checking has fewer requirements than the actual requirements, in theory there could be a series of checking levels of reducing complexity, until a level simple enough for a human to grasp in its totality is reached.
But we all know what will happen in the real world. No-one will check the checking requirements. A template will be used from another project without being properly edited, because the person editing is not responsible for the outcome, the person being checked is. It will be left up to the parties being checked to highlight errors in the checking, creating an enormous additional work burden for everyone actually involved in getting the facility built.
Computer based checking has a place, as a tool in a kit of tools, not as a strategy for defining requirements.

The biggest problem is none of it is useful, or even close to being useful. Beside the fact it doesn't actually cover what is required for Minimum Modeling Requirements (or Plan of Works for that matter), it can't be used until the checking software is finished and tested. What does the industry do in the meantime? Keep doing it the old way then suddenly everyone switches at the same time to the new way? Are they serious?

This is a classic example of bureaucrats, academics and standards junkies tackling the Minimum Modeling Requirements problem. I just hope this is not the only attempt the UK government (or the RBIA for that matter) will make at integrating BIM into their Plan of Work concept.

Conclusion

At risk of being compared to bureaucrats, academics and standards junkies, I don't have any practical solution. I just don't think we are there yet.

At the moment I suspect the USACE M3 approach is the most realistic. A customised mish-mash to get the results required.
BIMforum's LOD Specification is new (released August this year) and largely untested. It is not designed to be customised so may or may not work for you. In any case it could only ever be part of a customized mish-mash as it doesn't cover everything required of Minimum Modeling Requirements.
If the money available a commercial provider is a good bet, if for no other reason than to lessen the workload and extra responsibilities a BIM delivery requirement generates for everyone involved.

But in the spirit of being practical I will offer some advice on good practices that should make complying with any Minimum Modeling Requirements easier.

GOOD MODELING PRACTICE

• Use your software as it was designed to be used - don't use shortcuts purely for the production of documentation.
• Embed all the data you can into your model - then use it to generate all schedules.
• Use categories (or their non-Revit equivalents) in consistent and transparent ways.
• Insist on a robust co-ordinate base point.

GOOD EXCHANGE PRACTICES

• Make sure all non-BIM and non-project specific elements are identifiable, and if possible remove them before issuing your model.
• Check your model for consistency before issuing.
• Provide documentation to others on how your model is structured.
• Define the degree of precision you model to.
• Create a table of LOD expectations for selected milestones.

Postscript - What's in a name

I've used the term Minimum Modeling Requirements throughout this post. But is it the best term?

• Requirements makes it sound like an imposition. Something only the owner controls.
• Standard? The level everyone is expected to achieve. Perhaps too soon to be meaningful.
• Provision? The level to be provided. Bit like Requirement.
• Contribution? The level each participant contributes to the overall BIM.

I like the last. Minimum Modeling Contribution. It can come from anyone, as an offer, or as a request. It is in the spirit of collaboration.

What is the use of BIM Use

In my last post on LOD I touched on "BIM Use" as used in the [US]AIA E203 document. In that post I wondered why certain BIM Uses are not mentioned. But on reflection I now wonder what the concept of "Authorized BIM Use" is, and what it is trying to achieve.

What is "Authorized BIM Use" 

The obvious meaning of "Authorized BIM Use" is the use that elements in a BIM are "authorized" to be used for.

In the [US]AIA G202 document this is described as:

4.4 Anticipated Model Authorized Uses.
Indicate below the anticipated Authorized Uses of Models on the Project, which Authorized Uses will be agreed upon by the Project Participants and described for each LOD in G202–2012.

As you can see each "Authorized BIM Use" is associated with each LOD. So "Authorized BIM Use" is a requirement for properly describing an LOD. Note also that the assumption is BIM Uses are "agreed upon", so they are not necessarily imposed by the owner, but real Uses by actual participants.

It appears the idea is that when you select an LOD level that applies to certain elements, it is necessary to say what those elements can be used for.
I assume this is because the [US]AIA has decided that it is not enough to say that an element is "graphically represented in the Model with a symbol or other generic representation" (LOD100), but must add these definitions:

1. Analysis. The Model Element may be analyzed based on volume, area and orientation by application of generalized performance criteria assigned to other Model Elements.
2. Cost Estimating. The Model Element may be used to develop a cost estimate based on current area, volume or similar conceptual estimating techniques (e.g., square feet of floor area, condominium unit, hospital bed, etc.).
3. Schedule. The Model Element may be used for Project phasing and determination of overall project duration.
4. Other Authorized Uses. Additional Authorized Uses of the Model Element developed to this LOD, if any, including Authorized Uses identified or required by uses set forth in Section 4.4 of E203–2012, are as follows:

It seems to make sense

So apparently if you are defining the level of resolution or certainty of an element you also need to say for what purposes this certainty applies to.

And the act of defining "Authorized BIM Uses" means that if a BIM doesn't contain information needed for that particular use the BIM author can be forced to provide it via contractual coercion (assuming they signed up for it).

So there are two purposes for including "Authorized BIM Use" in LOD definitions:

1. defining what information in a BIM can be used for,
2. ensuring BIM modelling meets the requirements of others.

But is "Authorized BIM Use" rational?

Lets start with the fact that there is a separate BIM Use definition for each LOD. There are 5 LODs (6 if you include LOD350), times 4 BIM Uses for each equals 20 (or 24) separate "Authorized BIM Use" definitions as standard in E203. Possibly more if there are more "Authorized BIM Uses".  That is a lot of definitions.

The next issue is although LOD relates to elements and not the whole model, BIM Uses are usually deliverables that apply to the whole model. That is, for example, a use like Cost Estimating is not done as a continuous exercise, it is associated with project milestones. So strictly speaking there should be different BIM Use definitions per each LOD per each Project Milestone.
Or is this considered unnecessary because there is an assumption an LOD level matches particular milestones? (LOD100 = Concept estimate, etc). Surely not, that kills the concept of LOD not applying to the whole model.

And if a BIM has elements at different LOD levels at a particular time what does that mean for a BIM Use? If a thermal analysis is done and the floor is LOD 400, the walls are LOD300 but the roof is LOD100 what does the BIM Use definitions mean? There are three different BIM Use definitions applying to the analysis. How is that helpful?
Or is the assumption that for a particular BIM Use certain LOD levels must be met. So in the example above floor, walls and roofs must be LOD300 before the BIM is ready for thermal analysis. But doesn't that mean different milestones for each BIM Use will be required? If that is the case why associate BIM Use with an LOD level? Why not just associate BIM Use with a milestone?

So I really don't understand how BIM Use applied to LODs is supposed to work.  But more concerning is how are "Authorized BIM Uses" decided and what their implications are.

Problems with "Authorized BIM Use" in practice

There are a number of issues that arise when trying to apply "Authorized BIM Use" to the real world.

Insufficient Information

As I pointed out above the [US]AIA E203  document assumes project participants will decide what "Authorized BIM Uses" will be for a project. That is fine in theory but my experience with real projects is that not all project participants are on board when the BIM agreement is signed. The architect usually starts before anyone else, the quantity surveyor may be there depending on the contract type, then the consultant engineers, and the contractor doesn't appear till way past the time most have finished their BIMs. So BIM Uses are a guess as to what future participants may or may not want, or be able, to do. And of course there is no-one to offer any expert advice on specific requirements that those BIM Uses may require.

The assumption in BIM agreements is that the 'details' will be worked out later on when the BIM Execution Plan is done. But how do authors progress their BIMs if specific requirements are unknown when they start their BIM? How do they scope the amount of work that will be required so they can work out what their fee should be and how long it will take them?

Restricting BIM Use

There is an implicit assumption that by defining "Authorized BIM Uses" that other uses, i.e. those not explicitly defined, are NOT authorized. Why? Why can't anyone use a BIM for any purpose they like? Why do they need the BIM author's permission?

Certainly some-one using a BIM for their own purposes needs to be confident the information in it is accurate and complete enough for their purposes, but isn't that what an LOD level tells them?

What would the author know

And why would a BIM author (typically an architect or engineer) know what is required for some-one else's purpose? As an architect I have no idea if my BIM is adequate for cost estimating because I don't know what an estimator or their software requires. That is not my area of expertise. I can not warrant that my BIM is "suitable" for cost estimating, my Professional Indemnity insurance won't cover me for it. All I can say is I have modelled elements I am responsible for to a particular standard and they have a particular LOD level.

Other's requirements interfering with my requirements

The inference is that an author's BIM must be "suitable" for other people's particular BIM Uses. But what if the requirements of others prevents the author from using the BIM for their own purposes?
On a recent Linkedin group discussion on Correct Modeling Practices an estimator listed their requirements for a Revit model. One was to model floor penetrations as an "opening object", presumably so their software can extract accurate quantities. But we model floor penetrations with a component that cuts a hole in the floor. By doing this we can tag each penetration, embed what its purpose is in the component's data, and produce schedules of penetrations. All this greatly facilitates coordination, one of our responsibilities. Are we expected to forgo these benefits to fulfill our responsibilities under E203?

Allied with this problem is what if a requirement for one BIM Use conflicts with another Use? The estimator requires penetrations to be modeled as opening objects but the scheduler requires them to be modelled as shaft objects?

What is "Authorized BIM Use" really trying to achieve

Lets go back to the purposes of  "Authorized BIM Use":

1. defining what information in a BIM can be used for,
2. ensuring BIM modelling meets the requirements of others.

I believe both these purposes are misguided.

Is it really necessary to define what information in a BIM can be used for? Why do we think we need to restrict what a BIM can be used for? People are coming up with new and novel uses for BIMs all the time. Indeed there may be Uses that don't exist or are impractical when a project that goes for 2 to 5 years starts.

Ensuring BIM modelling meets other's requirements is not practical. Only the user can know what their requirements are, and quite frankly, their requirements may be unreasonable.


What is actually required is a way to ensure minimum modelling requirements are met. That the normal deliverables of an author is provided in BIM form that is known and consistent.
Recognition that it is the user of a BIM who has to work out how to utilize the information it contains, it is not the BIM author's responsibility to provide a "ready to use product".

And there is absolutely no need to tie this in with LOD definitions.  LOD may play a part but there are plenty of other ways to define minimum modelling requirements. Just look to the USACE M3 for a real life example.

Conclusion

"Authorized BIM Use" has no place in LOD. It is not necessary for the LOD concept to work in practice.

It is in fact an example of confusing Level of Development with Level of Detail, or degree of certainty with amount of information. "Authorized BIM Use" in the [US]AIA E203 document is an attempt to define minimum modelling requirements, which is a measure of amount of information, it has nothing to do with degree of certainty.

So what replaces "Authorized BIM Use"? - ways of defining minimum modelling requirements - an issue I think is becoming critical to practical use of BIM.
A topic for a future post.

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.

to COBie or not to COBie

When BIM and FM are talked about COBie always gets a mention. No self proclaimed BIM evangelist ever misses the opportunity to insist COBie must be a deliverable.
But must it? Is it the easiest, or even best, way for a construction team to deliver FM information?

What is COBie?

COBie is an acronym for "Construction Operations Building information exchange".
Its purpose is to exchange information that is gathered during construction to be passed on to a building's facility manager. COBie defines the way this information is structured, and the formats that can be used.
COBie is managed by the buildingSMARTalliance, a council of National Institute of Building Science (US).
The aim is that it becomes the standard way this information is delivered. A noble cause, but not without some notable problems.

What COBie is not

COBie is not a predefined list of what information is required. What it does define is how information is to be structured and what the minimum data fields are. It is a data format, not a standard on what information is to be provided for FM.
So to ask for 'COBie' without defining what you want in the 'COBie' is a bit like asking for a MS Word document without saying what you want written in it.

What does COBie look like

COBie can be delivered as a spreadsheet or an xml file (a structured text file, a bit like HTML). xml files require software to make them human readable so unless a software (or web service) is proscribed COBie is normally requested as a spreadsheet.
The theory is a spreadsheet can be filled manually by humans, yet still retain the possibility of populating data automatically via software from BIM models.
However don't think you could deliver COBie through entirely manually filling in a spreadsheet. COBie spreadsheets may be human readable, but are not human friendly (except maybe to computer programmers). True, you could set up human friendly spreadsheets that fed data to COBie spreadsheets, but that doesn't overcome the enormous amount of data that has to be manually typed in, checked and verified.

What COBie contains

Unlike IFC COBie data is just information in text and numbers, it doesn't include geometric information. It may contain the sizes of components and their X,Y,Z coordinates, but not enough information to recreate the components in 3D software like IFC can.

Because it is for FM COBie data is supposed to only contain information about "managed assets". Assets that:

• require management
• require (considerable) on-going maintenance
• has consumable parts requires regular periodic inspections

 Therefore COBie is not intended to exchange ALL information about a building. For example it is not meant to include information about flow systems like air conditioning systems or water pipework. BuildingSMART's approach is to have other  information exchange formats (some still under development) to do this: HVACie (for Heating Cooling and Air Conditioning systems), WSie (for Water System information exchange),  Sparkie (for electrical system information exchange) to name few. See the NIBS web site for a current full list of 'ie' projects.

The concept is that there will be overlaps. For example equipment in HVACie that requires maintenance will also be in COBie. In theory if information exchanges are largely automated from BIM this overlap shouldn't involve (much) extra work for users. Not so if done manually as the same information will have to physically entered multiple times.

COBie only sets out how to structure information that lists equipment, it doesn't dictate how information about a piece of equipment is structured. So COBie will define how to list, say a pump, but not how to list the manufacturer, model, rating etc. This information is defined by another information exchange - SPie, Specifier's Properties information exchange.
The objective of SPie is to create set of product templates that can be used by manufacturers to export product data into an open-standard format consumed by designers, specifiers, builders, owners, and operators. So its use is beyond just COBie.
Product information can be included in a COBie deliverable, it is just that you will need to refer to SPie rather than COBie on how that data is structured.

COBie and IFC

So how does COBie fit into IFC?
COBie is what is called a Model View Definition (MVD) of IFC. A sub-set of data that is useful for a particular purpose. COBie is the Facilities Management Handover model view.

SPie is the product data model view, HVACie the mechanical systems model view, etc.
All the model views ending in 'ie' (for 'information exchange') are actually a sub-set of Model View Definitions. They are specifically for exchanging information. Other IFC MVDs may be for other purposes, for example displaying certain components in a view.

In theory a COBie deliverable could be extracted from an IFC export. However all the data required would have to exist in the IFC file. Just exporting an IFC file in itself won't guarantee a valid COBie deliverable.
Conversely COBie data could be pushed into an IFC file. But again it is not automatic. Matching objects would have to exist in the IFC file. If a pump doesn't exist in the IFC file, COBie can't push data into it.
Using IFC to deliver COBie is NOT easier and quicker, it adds another layer of tasks. Which is why both IFC and COBie are usually requested by owners.

COBie innards

I don't intend to go into detail about how COBie is structured (my view is as AEC professionals we shouldn't have to), but there are some notable things to know that effect how a BIM model is structured.

Equipment must exist in a 'space', IFC's name for rooms. If it exists in more than one room the recommendation is to use the room it is accessed for maintenance from. Under COBie a piece of equipment can only exist in one 'space'. Therefore if you want it identified with more than one space you need to enter it multiple times, which of course creates a whole lot of other problems, so is not recommended.
But 'Spaces' can be grouped into 'Zones', so equipment can also be identified by the zone they belong to. Example of zones are Lighting zones, Fire Compartments, Secure zones, etc.
Equipment can also belong to a 'System', which is not related to 'spaces' or 'zones'. Systems group equipment that perform a specific function. Examples of systems are HVAC service, Cold Water reticulation, electrical distribution, etc..
Not all BIM software have 'zones' or 'systems' as defined by COBie so workarounds may be required.

How to name things is not defined in COBIE, but it does say everything must have a unique name that is human readable, for example "AHU-03". BuildingSMART recommend basing names on the US National CAD Standard abbreviations. As construction terms differ between countries this won't work everywhere, but local standards could equally be used.
This requirement is a little surprising as it is not strictly necessary. A unique identifier for each component is also required by COBie (a GUID), and easily supplied when exporting from BIM software. I presume this requirement is to make COBie  data more human friendly for manual data input, as I don't see why it would be required by an FM database either.

Another requirement for COBie is to assign a classification code to each component. A classification standard like Omniclass (US) or Uniclass (UK) is suggested, but COBie does not proscribe what should be used.
I'm not sure why this is required at all, an FM database doesn't necessarily use a classification system. But that said, getting into the habit of applying widely understood classification codes to BIM components will make BIM more useful across a whole range of uses.

Questionable Practices 

There are a number of issues that could potentially cause problems. Some are due to poor practices in the way COBie is used, others are built into COBie itself.

The requirement to create a unique name has caused some users to mix data together. This includes the COBie web site which offers this advice:

"if there were two sinks of type “Sink-A” in space “100” the unique names of each of these components following the algorithm shall be “Sink-A-100-01” and “Sink-A-100-02." 

This is poor practice because separate data fields are being combined into one field.  If the room a component is in changes (either because it is moved or the room number is changed) the component will have to be renamed. The same if other data used changes, like the System it is a part of, manufacturer, supplier, authoring company, etc.

The example above can be avoided by users, but COBie itself has examples built in. Doors and windows are required to have the rooms on either side, separated by a comma, in one field, e.g. [G.03,G.04]. Although this data can be created programmatically by combining two fields, it then has to be either programmatically separated by the FM database on input, or the database has to do a complicated text field search to find which doors are in which rooms.


Every component in a COBie output is identified with the author and supplier. Supplier I can understand, but I'm not so sure author ("createdBy") will end up being very reliable in practice. As it is a required field it is likely the BIM author of the component will be initially listed as author. But they may not have provided all information, or indeed any of the critical information. And they are unlikely to be the ones responsible for verification. If the author is not changed at later stages it is likely the draftperson or component authoring company who created the BIM component will end up as the contact.
Another quirk is that the mandated method to identify is via an email address. Email addresses are generally for individuals. To identify one person from an organization for information that is expected to be current for years to come is in my view a bit silly.

More concerning is there still seems to be some issues "under the hood" that those trying to create products for COBie are struggling with. See this example on the COBie linkedin discussion group.

Is COBie still Beta?

Does all this mean COBie is immature, not ready for business use?
To be fair COBie is an open source initiative, it is not a product being developed for a specific sales launch date. As long as there are interested people it will continue to develop and change.
Interestingly Bill East of the USACE, COBie's guru, believes COBie has moved from concerns with development to concerns about use:

" Those who just want it to work (mainstream users) are now engaging on the early side of the adoption curve regarding getting answers to issues directly relevant to daily practice. This new constituency brings its own questions and concerns..." [link]

So although COBie is not fully developed I believe it is beyond beta. It is now in the realm of user testing. I just hope the COBie team are still open to making changes, not just to tackle user issues but also to improve the way COBie interacts with software. Just offering to test software is not enough (like the COBie challenge, discussed below), it should be a two way street.

When COBie is a Deliverable

There are organizations that request COBie, define what they want, and use it to populate their FM system. The USACE and University of Southern California are two examples.

But I've been involved in a few projects now where the owners have demanded a COBie deliverable without defining what that is. They just ask for a "COBie file at completion of schematic design, design development and construction documentation" (I'm an architect, presumably they made similar requests to others for later stages) . They say nothing about what they want in that "COBie file". In an attempt to get a bit more information we asked what they they intend to do with the "COBie file". A lot of talk about the need for open standards but they don't have a specific use in mind. It seems they believe that by using an open standard they can avoid making decisions.

Now this situation can be a blessing in disguise. You get the opportunity to decide what you deliver. As Bill East himself says:

"If the owner doesn't specify up front, then you get to do what you want. My recommendation, however, is that the COBie Guide be followed even if the owner has not provided their own Appendix A. If the COBie file provided by the designer does not contain the identified attributes (or if the designer did not provide a COBie file at all) then I would also provide the minimum attributes for COBie.Types as would be required for existing contract's paper deliverables." [link]

But only if you define what you will provide. A generic COBie deliverable that is not defined by some-one, anyone, is dangerous. For all I know we are the only ones required to provide COBie and the owner is expecting us to include all services and constructed information, not just architectural information.
The COBie web site gives some guidance, but the bottom line is that COBie is only a format, so if an owner asks for COBie it is reasonable to assume they mean provide what you would normally provide on paper (or digitally) in a COBie format.

Who provides COBie and When?

COBie covers all information required to operate a building. From room names to purchase date of equipment. This information obviously comes from a variety of sources. Therefore there will be a range of people involved in providing information. Whether each has to provide it in COBie format is a matter for their individual contractual agreements. Certainly the bulk of information is provided by the services sub-contractors, but design professionals need to set up the structure for this information. Spaces, Zones and Systems must be set up before equipment can be added.

As COBie is for facility management you would think it only needs to be delivered at the end of construction. But COBie defines 5 different stages, from Early Design Stage to System Commissioning Stage, with COBie deliverables expected at each stage.

Whilst in theory COBie could just be delivered at the end of construction, it is not considered best practice.
Firstly those involved early in the project (architects, engineers) may not be around at the end. So if their contribution hasn't been captured some-one else is going to have to put it in. You might think this is preferable, because by the end everything is known, whilst earlier on there are a lot of unknowns. But remember the aim of COBie is to avoid re-entry of data, to use information already captured.
Secondly time is important. If an FM system is not up and running when a building opens, data captured during construction gets further out of date every day it remains outside the FM system. Even if, several months after sending construction documents to India to get turned into COBie, it is 90% correct, that 90% will still need to be verified, manually, on site.
A third reason is to practice. Each project is different, with different participants, and COBie itself is not bullet proof. Doing multiple COBie exports before the final deliverable gives everyone a chance to get it right. So there is some certainty the FM system will be up and running on day one.

Are COBie Deliverables Free?

As I mentioned above, the idea of COBie is to capture data that already exists. If that is the case shouldn't it be free - at no extra cost?
After all it is just the same information in a different format. Like providing a book in a different language, and translation is free isn't it?.
As ridiculous as this sounds there are plenty of people who subscribe to this view and fall for it. From developers offering free COBie to potential buyers to architects and services sub-contractors allowing it to be added to their services for no extra charge.

My response is to offer our Revit model. If we are not being paid for it because there is no cost involved, why can't the owner (or contractor) create their own COBie? If they claim they don't have the expertise then they need to pay some-one who does, just like we have to. COBie is not an area of expertise of AEC professionals, and nor should it be.

So if you are ever required to provide a COBie deliverable make sure you cost it. You may decide to throw it in to get the job, but don't think you can just load it on to the team delivering the project. It takes time and expertise, factor that in.

And if you are in a position to request COBie, only do it if you are actually going to use it. Don't ask for it because you might have an unknown  use for it some time in the future. As I said above, if the FM system is not up and running from day one all that COBie data is next to useless.

Should COBie always be Required?

COBie is one method for providing construction information for Facilities Management. It is not the only method, and not necessarily the best. Its purpose is to be vendor agnostic, the one you use when you don't know where the information will end up.
But what if you do know? Does it make sense to force construction data into a COBie format, then the FM system extract that data from COBie. Wouldn't it be simpler to just provide the data from construction in a format the FM system understands? Particularly if that FM systems talks directly to your BIM authoring software.
More and more FM systems are utilizing BIM information to populate their data, and the Internet to allow multiple people to provide data in a managed way. For example Veo by M-Six.
To be honest, sending around excel spreadsheets to be filled in sounds so 1990s (although to be fair, COBie doesn't have to work that way. See Ecodomus below).
`
So, no, COBie should not always be required. Ideally an owner would know what FM system they will be using and deliverables for that system are tailored to suit it. And the extra work is identifiable and compensated for.

But be careful what you wish for. The ultimate aim of COBie is to be THE way construction information is delivered for Facilities Management. That means the AEC industry learns one system, not multiple proprietary systems. Even if COBie might be a bit more difficult to use at the moment, that scenario sounds better to me.

The Future of COBie

COBie sounds like a good idea. A standardized way to deliver information, in a format based on a broad standard (IFC), using easily accessible and understood technology (spreadsheets).

But when I look at how COBie works something doesn't seem quite right. At first I thought what perturbs me is that COBie is based on trying to automate, or make more efficient, an old fashioned paper based system. Rather than starting from the idea that data is already in electronic format and just needs to be "exchanged" into another format, it starts with the idea that most information is on bits of paper. So its paradigm is based on organizing those bits of paper in a way that is familiar with how people do it now.
I still suspect there is a little of this but it is certainly not the intention of COBie. As Bill East himself says:

"Generally, direct use of spreadsheets is -not- recommended, except as last resort. Use of over 20 COTS ( Commercially available Off The Shelf ) products that allow COBie data to be created/updated/exchanged without anyone using the data file directly is recommended." 

So I ask - why is it so difficult? Authoring softwares seem to have to go through the hoop to output COBie compliant data. Even though Revit did pretty well compared to other authoring softwares in the BuildingSMARTalliance COBie challenge, (see below for more detail) a substantial 'toolkit' was required, that apparently is so complicated AutoDesk haven't released it for general use.
Yet FM softwares appear to have no problems. Of the 5 who participated in the challenge for COBie handover all achieved it with no errors.

To me it seems a bit lop sided. The creators of the information are being forced to structure their data to suit FM, without a thought to how FM could manipulate available data to suit their purposes. Which is surely fairer. After all it is FM who gain all the benefit, not the authors.

But this is not a comment on the usefulness of COBie itself. As I said it is a good idea. But by loading the effort onto those that don't benefit I wonder if it well ever gain traction.
Once BIM authors are awake to the extra effort involved they will all demand payment. And in the construction industry where costs are constantly trimmed I can see COBie being value managed out of most projects, particularly if there are commercial alternatives that are easier (and therefore more cost efficient) to use.
Surely a more sustainable approach is not to rely on government mandates, but to utilise market forces. Establish what construction information can be extracted easily, and the methods that the beneficiaries of that data might use manipulate that data. A good start would be to remove requirements that do not already exist in the construction process. For example, why does the construction team have to generate a unique names? Can't the FM system do that once it has the data?

As an open source project COBie could, in theory, change. But only if it takes seriously the difficulties facing BIM authors. Rather than just attacking commercial BIM authoring softwares for not 'supporting' open source, and accusing AEC professionals of not 'collaborating'.

Making COBie Practical

COBie is real and there is every chance you will one day be asked to be involved in a COBie process. What are the best ways of approaching COBie demands?

Define what a COBie deliverable contains

Whether you are an owner mandating COBie or a draftperson on the tools, you need to know what is to be delivered. If you can't find out make it up yourself and share it around. If no-one else puts their hand up you have at least got a fall-back position.

Use software that makes it easier.

Not all software are equal at exporting data to COBie. BuildingSMART runs regular "COBie challenges" open to any software vendor. In January this year they held a challenge for model authoring software. Autodesk Revit, Graphisoft ArchiCAD and Bentley AECOsimBuilding participated. Success was measured in how long it would take to manually fix or add information the softwares mismatched. The results were:

• 503 minutes (8.4 hours)    -  ArchiCAD 
• 218 minutes (3.6 hours)    -  AECOsimBuilding
•     9 minutes (0.15 hours)  -  Revit

I'm not suggesting anyone completely change the software they are using just to make COBie easier, but be aware how much effort (and therefore cost) it takes will depend on the software you use. Just because your software is better at IFC doesn't mean it is better at COBie.

There are also alternatives to a raw spreadsheet (e.g. Excel) format. An example is Ecodomus, a web based service that has free COBie functionality. They have an add-in for Revit that uploads data to their web site. The data can then be edited and/or added to by anyone with Internet access, and finally exported as a COBie compliant spreadsheet. Some owners, such as University of Southern California allow Ecodomus as a delivery method for COBie data.

There are also COBie utilities that are useful. Onuma provides a free COBie2 validation service.

BuildingSMART provide a list of softwares on their web site, although I don't know how up to date they keep it.

COBie deliverables are relatively new so I expect there will be more such softwares that take some of the pain out of it. When you are at the point of having to make a decision I suggest you check to see what is available. It may end up saving you a lot of time.

Structure it to suit the way you work.

COBie is supposed to capture data that already exists. It should NOT interfere with the production of other deliverables, like construction documentation. Resist calls to change the way you structure your BIM model just to suit what some-one thinks is required for COBie.

I have been requested, and seen examples of it happening to others, to rename all our Revit families (components) to suit what the contractor thinks is required for COBie. They are trying to comply with the "everything must have a unique name" requirements. They think that means the name used in the authoring software. But to COBie it is just a data field, it doesn't matter where it comes from. If they want their own name for things create a parameter for it (you can in Revit, I don't know about other softwares), and direct that parameter to the COBie name field on export.
The same goes for room numbers and names. If they want to use a different numbering system create a room parameter to hold the COBie space number. There is no technical reason that the Revit (or other software) room number has to match the COBie space number.

As I've said above the requirement for a unique, human readable component name is a COBie quirk, it is not needed for BIM authoring or FM softwares. The best way to create this name is to use data you already have. You shouldn't need to manually create names just to suit COBie. In Revit you can use Family, Type and Mark. Not only is it unique, but should be human readable if you have good Revit standards in place. You could also use the schedule code you are using for documentation, although this may not be human understandable nor unique. Remember the name has to be unique across all disciplines over the whole project.

Try keep as much data creation as possible within your authoring software. Although it is possible to do tricks in excel to manipulate data to suit COBie it adds another task and another possibility of error. That said, it may not be practical. The two rooms in one field problem I spoke of above is solved by the Revit 2013 COBie toolkit in excel, not in Revit.

Pick an easy to use Classification System

If your client doesn't proscribe a classification system, and you don't need a particular one for your own processes, minimise the effort where you can by using the easiest one at hand. Some BIM authoring softwares have classification codes built in. For example Revit has Uniformat (a sub-set of Omniclass) for all objects and Omniclass for components (family files). Mind you it still involves work. When you create a new wall type you still have to select the appropriate Uniformat code, Revit just makes it easier by only listing codes relevant to walls.
A word of warning - if you do decide to select which classification system to use make sure you communicate this to your client. You don't want to have to re-enter it all again later (not for free anyway) when they finally decide what they are doing.

Workflows & Responsibility

Providing COBie is more than just a single software export. The total COBie deliverable is provided by a range of people. And what you provide may depend on what others have provided. This all means there is a workflow involved. You may not be in charge of the workflow, but you need to be aware of what it is and where you fit in. Otherwise you may find yourself adding data to an outdated COBie spreadsheet and have to do it all over again.
And be clear about what you will be contributing. Authors of BIM models are often pressured into including information they are not responsible for just because everyone else perceives it is easier for them to do it. The mechanical engineer shouldn't be putting in product information if supply is performance based. The mechanical sub-contractor should do it, or the mechanical engineer should be paid to do it.

Set aside Time

COBie is not just going to fall out of your BIM model. It will take time to set it up, test it, and then do the export and validate it. Keep in mind it will take a lot less time if you use some-one who knows what they are doing.
Ideally it should be programmed to avoid other deliverables. It is silly to expect COBie to be delivered on the same day as a milestone document issue. They are required for different purposes so why increase the stress levels of everyone?

COBie Resources

Official COBie web site:
http://www.nibs.org/?page=bsa_cobie

Bill East's article at WBDG:
http://www.wbdg.org/resources/cobie.php

COBie UK 2012:
http://www.bimtaskgroup.org/cobie/

UK NBS on COBie:
http://www.thenbs.com/topics/BIM/articles/whatIsCOBie.asp

Youtube lessons:
http://www.youtube.com/results?search_query=COBie-Class


Linkedin discussion group for COBie:
http://www.linkedin.com/groups?gid=2638637.
 It is moderated by Bill East, the COBie man so is the best place to ask questions.


COBie software and toolkits:
Autodesk Revit COBie toolkits.
For Revit versions 2011 upwards.

Ecodomus
Free COBie Revit add-in that links to Ecodomus web app.

Solibri
Solibri model checker has an extensions package for COBie.

Onuma COBie Validator
Free on line COBie 2 validator.

2013-01-10-UsingGoogleDocsForCOBie.pdf
Description of how to use Google Docs (now called Google Drive) spreadsheets for COBie. Using Google Drive means you effectively have a free web service accessible by multiple parties.

buildingSMART alliance information exchanges: Means and Methods
buildingSMART alliance suggestions.


Revit and COBie:
For some more comprehensive information on Revit and COBie have a look at Brian Renehan's post on his BIM Fix blog about COBie and Autodesk Revit

Bored with BIM? Need a present for that special woman in your life? The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, fashion and ... men. Book one of the series, "Awakening the lost woman", is available now on Amazon,  Google Books,  Kobo  and  iBooks.