I’m sure that you have heard before that ‘COBie is a subset of IFC’ or maybe ‘COBie is a model view of IFC’.
IFC – Industry Foundation Classes
COBie – Construction Operations Building information exchange
What both statements are saying, in their technical ways, is that there are similarities and links between COBie and IFC.
A model view is a defined method of viewing a smaller part of the larger IFC data.
The different types of IFC model views and referred to as Model View Definitions (MVDs).
IFC contains both model geometry information and data about the objects within a model.
COBie Data
COBie primarily contains data about the objects within a model. It also contains a limited amount of geometry data, but this is very basic, you wouldn’t be able to reproduce the original 3D model from COBie
Both IFC and COBie contain data about objects within a model. The data within an IFC file could be data on the installation date or manufacturer of an item. But, it could contain absolutely any relevant data. Data within COBie is more limited and focuses on information required for the operational phase of a project.
An IFC file in its most basic format is a text file produced in a standard and predefined way. The most familiar format for a COBie file is as a spreadsheet, using the platform neutral and open spreadsheet XML format.
COBie As A BIM Level 2 Deliverable
The UK’s BIM Level 2 strategy identifies COBie as a deliverable. Interestingly, IFC does not appear to be defined as a deliverable. Although, as COBie is a model view definition of IFC, then it follows that IFC is provided, it’s just provided in a stripped down version.
Now that we have established that COBie and IFC are closely related. We can look into more detail in how they are linked.
BS 1192-4
BS 1192-4:2014 Collaborative production of information. Fulfilling employer’s information exchange requirements using COBie. Code of practice.
BS 1192-4 is one of many documents contained within the suite of documents that detail the UK’s BIM Level 2 requirements. It focuses on producing and delivering COBie.
From the point of view of COBie the document provides excellent and well-defined guidance. It has clear explanations of the data types and examples of COBie deliverables. In that regards it delivers on its core requirements, producing COBie.
BS 1192-4 does contain some references to IFC. Significantly, it lists BS ISO 16739, Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries section 2 as a normative reference. BS ISO 16739:2013 provides the specification for IFC 4. The normative reference is important as it essentially identifies IFC as being fundamental to COBie.
In section 3.2 of BS 1192-4 the concept of COBie as a model view definition (MVD) is identified. Notes at the bottom of Tables 8, 9 and 10 reference IFC attributes and IFC property sets. And finally, Annex A provides examples of COBie entries, which lists within the purple sections the external sources, such as IfcZone for the Zone ExtObject.
The introduction to BS 1192-4 Annex A provides a description of each coloured section. The purple section is described as – Application: This field might be filled by the generating application. In practice, this means that the purple section is largely ignored, after all, it might be produced by the generating application.
Data Mapping From IFC to COBie
However, what is evidently missing from BS 1192-4 are clear descriptive references to IFC. Which as COBie is a MVD of IFC this appears to be flawed. Especially as the link from COBie back to IFC is not that clear. If you were to look in detail at an IFC text file you will not, for the average file, find any reference to COBie. The exception to those comes when the COBie deliverable is derived from the model, which requires adding some COBie specific attributes.
The majority of data that you find within a COBie deliverable is extracted from standard IFC attributes. Attributes within IFC have a predefined mapping to parameters within COBie.
There are some exceptions (particularly within IFC 2×3 and I would assume it would be similar within IFC 4), where COBie specific property sets are required. This requires the originator of the data to provide the COBie property sets for each object.
- COBie_Warranty
- COBie_Specification
- COBie_Component
- COBie_EconomicImpactValues
- COBie_Spare
But, the predefined mapping and the requirements for COBie specific property sets are not widely understood.
Data Within the Model
It makes sense that data, where possible, resides within the model. And not found on isolated and unlinked documents and schedules. When information is contained within the model the data will have a single source and will be coordinated with other information from within the model. When something gets changed or updated, any associated information will also be changed.
So a UK BIM Level 2 project may request COBie as a deliverable. Hopefully, the requirements of the COBie data content are well defined. Ideally, all information that can be generated is obtained from the project model. In theory, COBie deliverables can be produced by hand from scratch or supplemented by adding additional data. But manually adding data by hand is time-consuming and prone to human error.
It may seem obvious, but generating COBie deliverables from a model requires that the COBie output data is also contained in the IFC file. IFC files contain geometric objects, with data associated with the objects, often through groups of data called property sets.
Current Methods for Producing COBie Data
Current knowledge and understanding of the mapping of data fields between IFC and COBie is limited. What happens, on a good project, is that designers will produce project specific data fields containing COBie property set attributes. These are often not the standard IFC attributes that map automatically to COBie. But project specific attributes that require manual mapping to produce COBie deliverables. The manual mapping isn’t too problematic to achieve. But, ideally, we want the same type of data to be included within standard IFC attribute fields.
That provides an example of what happens on a good project. But, on a project with poor data management, all designers will have their own unique COBie attributes within their model. Indeed, they may even have different attribute names for identical attribute types. This results in inconsistency between designers and inconsistency within the model. Obtaining the IFC output requires a mammoth task ensuring that all the required data gets correctly exported.
The Future of COBie Data
Many of the IFC to COBie mapped attributes are contained within standard IFC property sets (referred to as Psets). Such property sets are easily produced from within your standard model authoring application. They just requiring populating with the correct data.
COBie data should just be a regular part of the overall IFC model data
COBie data should not be an isolated spreadsheet
So what we have in the UK is a requirement for delivering COBie. But, it would be even better if we focused on producing high-quality IFC models with the COBie data contained within the mapped IFC attributes. This would enable COBie deliverables to be easily (and often automatically) produced from the IFC model, but, would also provide a data rich model which has countless benefits and opportunities beyond an isolated COBie deliverable.
Contents