COBie is not what you think it is

When BIM is talked about mention of COBie is never far away. What I don't understand is why COBie has reached such a privileged position. Sure it is (pretty much) mature, sure it has been used in the real world (although far from ubiquitous). But it is only a small part of BIM, a small part of the whole process of establishing, building and operating facilities.

Part of this seems to be coming from the UK and the furore to understand what they call "Level 2 BIM". But we see it here in Australia as well. Clients and owners who place requests for COBie deliverables that on closer inspection are not actually COBie at all.

I suppose COBie is tangible, you can download COBie spreadsheets and so tick the COBie box on your BIM checklist. But I feel COBie is a bit like Quantum Mechanics - most people have heard of it but very few actually understand it.

So it is very likely your understanding of COBie is wrong.

Not that COBie is as complicated as Quantum Mechanics. In fact COBie is probably far simpler than you think it is.

I'm no COBie expert, I'm an architect, not a facilities manager. Bill East is THE expert. He developed COBie while at the US Army Corps of Engineers (USACE), shepherded it in to the National Building Information Model (NBIMS-US) standard, and is still heavily involved in COBie, including the latest update.

Bill is co-manager of a COBie LinkedIn group, and is active in discussions. It is fascinating reading (for a BIM geek). Rather than provide my own commentary I've used quotes from discussions to clarify what I see as the most common misunderstandings of what COBie is (and is not).

COBie the Acronym

COBie, according to the buildingSMART alliance, is an acronym for 'Construction Operations information exchange'.

Bill East adds an important rider:

"...COBie requirements consistent with it's name the 'Construction (to) Operations Building information exchange' format."

COBie is about exchanging construction information to operations. That is, information that already exists for construction purposes is 'exchanged' for operation purposes.

"COBie is the list of scheduled assets found on drawings and in existing contractor O&M related deliverable. The sole focus of COBie is the capture of assets that need to be managed following construction." 

Therefore COBie is NOT about construction and does not include sufficient information for construction purposes.

And COBie is NOT a method to embed information required for Operations only within construction data or models.

COBie is only for Operations

The meaning of  'Operation' in the context of COBie is limited. Again from Bill East:

"COBie should include 'Managed' assets. Managed assets are those assets which;
- requires management
- requires (considerable) on-going maintenance
- has consumable parts requires regular periodic inspections"

"COBie only defines requirements for information about the spatial containment of managed assets -- these are manufactured products that have tags or serial numbers. These items appear in drawing schedules."

Yet there is a misunderstanding that COBie should contain anything that may even remotely be referenced. Bill East:

"A bit confused about the discussion of Walls since the COBie specification EXPLICTLY excludes walls, beams, columns, foundations, and all other structural members." 

"I hope that this effort will clarify the distinction between requirements for facility and asset management handover (which is COBie) and other needs such as carbon and life-cycle costing (which is not what COBie was designed to do). While other needs may be critically important, delivering them through COBie is likely not to work. Why? because COBie was not designed for that job."

Don't call it COBie

Not that Bill East is saying standards and methods to exchange information outside of COBie can not be done. Just don't call them COBie, call them something else:

"COBie is specifically for the purpose it was designed. If you are trying to make it do something else then it is no longer COBie." 

"Real Estate information is not required to solve the problem of eliminating boxes of paper in the boiler room -- i.e. "information about pump 5 in room 3." As a result, real estate information is not explicitly represented in COBie.

... if you change the purpose or content of COBie you will need to call it something other than COBie according to it's creative commons licencing terms."

And the warning is not just for those attempting to create a different COBie standard. If you use COBie on a project and add things beyond what COBie includes you also should not call it a COBie deliverable:

"If you use COBie in a way which violates the COBie specification you are no longer meeting the COBie requirement. You are doing something else that is not COBie."

COBie is not equal to IFC

There is a fair bit of confusion over the relationship between COBie and IFC. In simple terms COBie is not IFC, but follows IFC standards and protocols.

Ian Hamilton provided a good general description:

"IFC is a data format, well 2 actually: STEP (ISO 10303) and xml (ifcXML).
COBie is a list of things. It can be in a spreadsheet, in IFC or in other appropriate formats.

Bill East was more specific:

"In point of fact, COBie an IFC Model View Definition (http://docs.buildingsmartalliance.org/MVD_COBIE/)."

A Model View Definition (MVD) describes the things in a BIM model that are required for a particular purpose. In IFC those "things that are required" are labelled "information exchanges" (more on that below). From the buildingSMART website:

"An IFC View Definition, or Model View Definition, MVD, defines a subset of the IFC schema, that is needed to satisfy one or many Exchange Requirements of the AEC industry."

Stephen DeVito made it even clearer:

"COBie is a subset of IFC, an IFC Model View Definition, and comparing IFC to COBie is like comparing the whole assortment of fruit in a basket with only the apples. This is a most basic fundamental misunderstanding which occurs constantly in the industry ..."

One of the causes of confusion is that the IFC used by design and construction software is also an MVD. As Bill East explains:

"BIM authoring tools (up to this time) produce IFC files based on the Coordination Model View Definition. The purpose of that MVD is to express the geometry of all physical objects in the project for purpose of collision detection.

The MVD inside COBie has a much more modest goal, simply to deliver information about managed and maintained facility assets. As such, COBie data in any presentation format (IFC, ifcXML, SpreadsheetML, COBieLite) will be smaller than that of the Coordination View."

The idea is that the design and construction team's IFC Coordination MVD can have the COBie MVD extracted from it.
This is fine in theory, the reality is not quite so simple. Different softwares export varying qualities of IFC, and not all items included in the IFC Coordination MVD are always modelled (because they are not needed for the particular project).
So whilst in theory you should be able to extract COBie from an IFC export, currently it rarely works without a lot of unnecessary extra effort, if at all. One day this might be practical, but generally it is easier and less work to extract straight to COBie from design softwares.


Another misunderstanding is that COBie, although not currently containing a 'full' definition of IFC, will be further developed so it includes a greater range of definitions.  As Bill East says:

"COBie-UK is clearly called out as a stepping-stone to 'full' building information modeling in IFC. In my view UK should just stop calling what they are doing COBie and simply get on with requiring IFC with all disciplines, trades, geometries, entities, properties, etc..."

To sum up, COBie is NOT a general delivery method for everything in IFC.

COBie doesn't need to do everything

The 'ie' in COBie stands for 'information exchange'. From the buildingSMART alliance web site:

"The requirements [of information exchange projects] are defined in an 'Information Delivery Manual.' The IDM clearly defines the problem to be solved and makes clear who is involved, what information is needed, and when that information is needed. These requirements are translated into a 'Model View Definition' that provides the technical description of which parts of the Industry Foundation Class Model (IFC) found in ISO 16739 are needed to solve the problem."

COBie is only one of a number of information exchange projects. Other projects listed by the buildingSMART alliance to date are:

• BIMSie - BIM Service interface exchange
• BAMie - Building Automation Modeling information exchange
• BPie - Building Programming information exchange
• Sparkie - Electrical System information exchange
• HVAC information exchange (HVACie)
• LCie - Life Cycle information exchange: BIM for PLM
• QTie - Quantity Takeoff information exchange
• SPie - Specifiers' Properties information exchange
• WALLie - Wall information exchange
• WSie - Water System information exchange

All of these follow the same structure as COBie - they are subsets of IFC definitions, with their own MVD.

So you can see the intent is that information specific to a purpose has its own 'ie'. There is no need to expand an existing 'ie', instead a more appropriate 'ie' is used, or another project is started.

For example COBie doesn't define the format manufacturers provide their information in, SPie does that. However when manufacturer's information is required by COBie it has to follow the SPie format.

Rather than have one big standard the idea is to break it down into more specific standards that can reference each other. From Bill East:

"The sole focus of COBie is the capture of assets that need to be managed following construction. The system "ie's" include COBie for that discipline (i.e. the Components), but also include the assemblies of those components and the connections between the components. These system ie's provide the full geometry at least as far as fabrication and can be included in construction contracts as a better statement of as-builts than any attempt at having someone do a walk through of the project after the fact..."

So in the example above where Bill East is talking about Real Estate information (in response to some-one asking why that information isn't included in COBie), the way to do it is to create a Real Estate information exchange:- REALie, or if the data is actually about land titles:- TITie.
This information could be delivered in spreadsheet form, even within the same file (in its own worksheet) as a COBie deliverable, just don't call it COBie.

Anyone can start or get involved in an 'ie' project. From the buildingSMART alliance website:

"To participate in an existing project simply contact the point of contact identified on that project page." 

"If the project you need isn't in the list above, you can start your own project by joining the buildingSMART alliance."

There is more than just COBie

There has been enormous focus on COBie but it is not necessarily the only data exchange that will improve productivity.

Specifiers' Properties information exchange (SPie) is an interesting case. Basically it is meant to standardize the way products are specified, leading to standardizing how manufacturers define their products. So they all use the same names for the same things, and include the same information as each other. You would think this would be an easy task. Apparently not. Bill East admitted:

"The conclusion reached during the SPie project [in the US] are that "If you build it, they will NOT come" (see movie Field of Dreams for quote). The bottom line is that the integration of product and equipment manufacturer data into the construction supply chain is a very, very hard problem. Publishing a list of product templates does not mean that anyone will actually use them. It has been tried over 4 times now in the US with national projects. Two have been attempted with the authoritative product data publisher, once by NIBS, and once by NIBS (under the SPie project). Despite significant development work and and participation by companies such as General Electric, there has been zero effective use by the supply chain."

However the UK may have better results:

Carl Collins:

"Is the failure of SPie in the US a function of who created it? Have the suppliers themselves been an integral part of the process? I'm guessing not, as they are often unaware of SPie when I have spoken to them." 

This is the difference that the CIBSE started Product Data Templates (http://bimtalk.co.uk/bim_glossary:pdt) has; we are defining them with the Manufacturers and Suppliers and asking for sign-off from their Trade Associations, so there is buy-in from the outset.
Our starting point for each template is the SPie template, but we have found that they are not detailed enough to adequately describe the product and have too many project specific parameters that don't really belong on the Product side, but should be detailed on the Project side. This allows a Manufacturer to complete a template once for each product line and may be used for any project."

This is really critical. Producing COBie mainly involves manually transferring manufacturer data into COBie format, whether done directly into COBie spreadsheets or into a BIM model. Enormous productivity gains will happen when this data can be pulled in directly.

Rather than just mandating COBie specifications and contractor's supplier contracts should be required to demand suppliers provide standard format product data. I'm sure transferring a little money from manufacturers' marketing budgets would more than cover the cost.

COBie UK

The UK government has a BIM mandate. Does this mean COBie is a required deliverable for all projects?

Rob Jackson:

"COBie will be mandatory for all centrally procured UK Government projects from January 1st 2016 [now 4th April 2016]. The private sector can do what they want but even most of them will align with recognised standards."

And COBie is not necessarily a requirement if UK standards are followed. COBie is merely one method that may satisfy requirements.

Charlotte Brogan (Gray):
"COBie is one way of transferring data from a 3D environment to an facilities management software, however depending on clients in the UK will depend on how the data is handed over. This is why it is not mandatory in the UK, the standards state that a single source of asset information is to be produced and handed over to the client upon project completion. Therefore with the use of document management systems and links this can be achieved without the use of COBie. One day when clients are up to speak COBie may become more prominent in the UK AEC Industry."

Is COBie-UK different from COBie?

The fact the UK have developed their own COBie templates tends to confuse many. Some believe there is a UK COBie and a US COBie, which makes a farce of the idea of COBie as a standard.
COBie allows for regional customization so the fact COBie-UK templates exist is not evidence there are two standards. For example COBie-UK mandates UniClass for classification. But this does not necessarily mean it is non-compliant as the choice of classification system is not defined in COBie. Bill East:

"According to the standard, classification is required but arbitrary. The choice depends on regional, national, local, owner convention. Ultimately, the best choice is the one that serves the recipient of COBie data."

Although COBie-UK does have some language differences which can cause problems for computerized processes. Rob Jackson:

"The U.K. COBie-UK-2012 template have Moveable and Fixed in the standard Picklist for AssetType. The US standard as Bill points out uses Movable. This is one of the minor differences either side of the pond."

But more of concern is Bill East's view that COBie-UK is pushing COBie beyond its intended purpose.

"COBie-UK efforts have resulted in unrealistic expectation that (for example): the Coordinate sheet should be required (it is, in fact, junk and will likely be removed from the next iteration of the COBie standard); the insistence that COBie can successfully model steel structures; and the expectation that every possible permutation of room finishes -should- be included in COBie." 

This may just be due to overzealousness, or perhaps a lack of understanding the concept of MVDs and information exchanges as envisioned by buildingSMART.

But I agree with Bill East. If you don't think COBie is adequate for your purposes then use, or develop, something else. Don't mess with an existing standard. It just confuses everyone.

For example if the UK want a single deliverable for all information exchange data create a container for COBie and any other 'ie' that a client/employer/owner may want. And call it something like "UKie", or "HMGie", after all the mandate is only for government projects.

Use COBie properly

From Bill East:

"Owners need to answer three critical questions if they want COBie data they can use. Why? because COBie is only the format to deliver handover data. COBie can't possible predict the specifics of an individual Owner or project. Here are the questions: 

1. What assets do we manage? The Owner should look at what they actually maintain over time. The default position of getting "everything" distracts the team from the Owner's real needs. 
2. What information do we need? If Owners need the fan belt size for fans, say so in writing. Without such specifics Owners can expect to get whatever is given, and like it. 
3. How will it be organized? Campus/Installation owners with a consistent Classification method for COBie.Space and COBie.Type will be able to mine data."

COBie is only meant to contain information called for in design and construction contracts. As Bill East says:

"This topic keeps cropping up, so I thought I would remind everyone of the following rules about COBie and product data. First, COBie product and equipment properties at design must match what appears on design schedules. Second, COBie equipment properties at construction must match what is in the existing non-COBie contract specs (typically equipment nameplate data). Because of this, there is -no- additional cost of "doing COBie" since the information being required is no different from what is currently in design and construction contracts."

Therefore if your COBie deliverable contains data that is NOT required for design or construction, it is beyond the scope of COBie. And that extra data is extra work for those creating the deliverable. Don't expect it for free.

(Although I disagree with Bill about there being no additional cost for "doing COBie". If that were the case we should be able to deliver our documents in Spanish, or Chinese, - same information, just different format.)


But my favourite comment from Bill East says it all:

"what COBie repeatedly has been about is the 'art-of-the-possible' not the 'art-of-the-aspirational'."