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.