IFC and COBie
COBie (Construction-Operations Building Information Exchange) is the facility-management handover dataset: the non-graphic data an owner needs to populate a maintenance and asset-management system. In IFC terms COBie is a MODEL VIEW DEFINITION SUBSET, realised as the Basic FM Handover View. It captures spaces, zones, components, types, systems, spares, resources, jobs, documents, and attributes. It is NOT a geometry format.
This skill covers the COBie worksheet to IFC entity map, the IFC2x3 and IFC4 bindings, the STEP versus spreadsheet exchange forms, and extracting a COBie subset from a full model.
Verified against the buildingSMART MVD database and the IFC 4.3.2 specification (ISO 16739-1:2024). The Basic FM Handover View is verified as an IFC2x3 TC1 MVD with status Final. COBie applies to IFC2x3, IFC4, IFC4.3.
Quick Reference
What COBie is and is not
| COBie IS | COBie is NOT |
|---|---|
| A subset of IFC: non-graphic FM handover data | A separate file format competing with IFC |
| Spaces, equipment, types, systems, jobs, documents | A geometry or visualisation format |
| Exchangeable as IFC STEP, ifcXML, or a spreadsheet | A replacement for the design model |
| The Basic FM Handover MVD applied at handover | A live maintenance database |
COBie data ALWAYS lives in standard IFC entities. There is no IfcCobie*
entity. NEVER invent one.
The COBie worksheet to IFC entity map
| COBie worksheet | IFC entity | Version note |
|---|---|---|
| Contact | IfcActor, with IfcPerson / IfcOrganization / IfcPersonAndOrganization |
all |
| Facility | IfcBuilding within IfcProject and IfcSite |
IfcFacility exists in IFC4.3; COBie uses IfcBuilding |
| Floor | IfcBuildingStorey |
all |
| Space | IfcSpace |
all |
| Zone | IfcZone |
all |
| Type | IfcElementType subtypes (IfcFurnitureType, IfcDistributionElementType, ...) |
all |
| Component | IfcElement occurrences |
all |
| System | IfcSystem |
all |
| Assembly | IfcRelAggregates or IfcRelNests |
all |
| Connection | IfcRelConnectsElements and the IfcRelConnects family |
all |
| Spare | IfcConstructionProductResource |
all |
| Resource | IfcConstructionResource subtypes |
all |
| Job | IfcTask |
TaskTime, PredefinedType are IFC4 additions |
| Document | IfcDocumentInformation and IfcDocumentReference |
all |
| Attribute | IfcPropertySet and IfcProperty |
all |
| Coordinate | ObjectPlacement on the spatial or component entity |
all |
Full attribute signatures and the relationships that wire these together
are in references/methods.md.
COBie versions and IFC bindings
| COBie release | IFC binding | MVD |
|---|---|---|
| COBie 2.26 | IFC2x3 TC1 | Basic FM Handover View (status Final) |
| COBie 2.4 | IFC4 | FM Handover, produced by the buildingSMART MVD support group |
The buildingSMART MVD database enumerates the Basic FM Handover View on
IFC2x3 TC1. buildingSMART runs the COBie Certified Professional programme,
aligned with ISO 19650. ALWAYS bind a COBie export to the schema named in
FILE_SCHEMA; NEVER mix IFC2x3 and IFC4 entity sets in one file.
The two exchange forms
- IFC STEP physical file or ifcXML: the full-fidelity exchange, used for large projects and when the COBie data must round-trip with the model.
- The COBie spreadsheet (one tab per worksheet): the lightweight exchange, used for small projects and human review. National codes of practice govern the spreadsheet layout (for example BS 1192-4 in the UK).
Both forms carry the SAME data. The spreadsheet is a projection of the IFC entities, NOT a different dataset.
Decision Trees
Is this data in COBie scope?
What kind of data is it?
|
+- Managed physical asset (equipment, fixture, furniture) that the
| owner maintains
| -> in scope. Component (IfcElement) + Type (IfcElementType).
|
+- Space, floor, zone, or facility the asset sits in
| -> in scope. Spatial backbone.
|
+- Maintenance job, spare part, resource, document, contact
| -> in scope. Job / Spare / Resource / Document / Contact.
|
+- Detailed parametric geometry, structural analysis, fabrication
| detail, construction sequencing geometry
-> NOT in scope. COBie carries non-graphic FM data only.
A wall's exact swept-solid profile is NEVER COBie data. The wall as a maintainable Component, with its Type and attributes, IS.
Which IFC entity for a COBie record?
Which COBie worksheet is the record on?
|
+- Component -> an IfcElement OCCURRENCE (the placed instance)
+- Type -> an IfcElementType (shared definition)
+- Space -> IfcSpace ; Floor -> IfcBuildingStorey
+- Zone -> IfcZone, members assigned by IfcRelAssignsToGroup
+- System -> IfcSystem, members assigned by IfcRelAssignsToGroup
+- Job -> IfcTask, operating on products via IfcRelAssignsToProcess
+- Document -> IfcDocumentInformation + IfcDocumentReference,
| associated by IfcRelAssociatesDocument
+- Attribute -> an IfcProperty inside an IfcPropertySet
+- Spare -> IfcConstructionProductResource
+- Resource -> an IfcConstructionResource subtype
NEVER map a Component to a type object. A Component is a placed occurrence; its shared data lives on the linked Type. See the occurrence-versus-type split below.
STEP or ifcXML or spreadsheet?
What is the consumer?
|
+- Another IFC-aware tool, or the data must round-trip with the
| model
| -> IFC STEP physical file (.ifc) or ifcXML (.ifcXML).
|
+- A human reviewer, a small project, or a CAFM import that
| expects tabular input
-> the COBie spreadsheet (one tab per worksheet).
ALWAYS keep the IFC file authoritative. The spreadsheet is generated FROM the IFC entities; edits made only in the spreadsheet drift from the model.
Component or Type for shared data?
Does the data value vary per placed instance?
|
+- Yes (asset tag, serial number, install date, barcode,
| warranty start)
| -> the Component occurrence (IfcElement).
|
+- No (manufacturer, model number, nominal length, expected life,
replacement cost)
-> the Type (IfcElementType), shared by every Component of
that type.
This mirrors the COBie split: the Type worksheet holds the catalogue data,
the Component worksheet holds the per-instance data. See
ifc-impl-data-enrichment for the attachment mechanics.
Patterns
Every snippet uses STEP physical file syntax. $ marks an unset optional
attribute. Full verified signatures are in references/methods.md;
complete instances are in references/examples.md.
Pattern: the spatial backbone
COBie Facility, Floor, and Space are the IFC spatial structure: an
IfcBuilding decomposed into IfcBuildingStorey, decomposed into
IfcSpace, all wired by IfcRelAggregates.
#10=IFCBUILDING('0FacilityGuid0000000001',#5,'Main Building',$,$,
$,$,$,.ELEMENT.,$,$,$);
#11=IFCBUILDINGSTOREY('0FloorGuid000000000001',#5,'Level 1',$,$,
#82,$,$,.ELEMENT.,0.);
#12=IFCSPACE('0SpaceGuid000000000001',#5,'A-101',$,$,#83,$,'Office',
.ELEMENT.,$,$);
Every COBie Space ALWAYS belongs to exactly one Floor through
IfcRelAggregates. See ifc-impl-spatial-decomposition.
Pattern: Zone grouping
A COBie Zone groups spaces. IfcZone is a subtype of IfcSystem; its
members are assigned by IfcRelAssignsToGroup.
#20=IFCZONE('0ZoneGuid0000000000001',#5,'Fire Compartment 1',$,$,$);
#21=IFCRELASSIGNSTOGROUP('0ZoneAssignGuid000001',#5,$,$,
(#12,#13),$,#20);
IfcRelAssignsToGroup carries the members in RelatedObjects and the zone
in RelatingGroup. A zone member is ALWAYS an IfcSpace, IfcZone, or
IfcSpatialZone per the IfcZone WHERE rule.
Pattern: Component and Type
A COBie Component is an IfcElement occurrence; its COBie Type is an
IfcElementType. The two are linked by IfcRelDefinesByType.
#30=IFCFURNITURETYPE('0TypeGuid0000000000001',#5,'Desk-1200',$,$,
$,$,$,$,.NOTDEFINED.,.USERDEFINED.);
#31=IFCFURNITURE('0CompGuid0000000000001',#5,'Desk A-101-01',$,$,
#84,#90,'ASSET-0001',$);
#32=IFCRELDEFINESBYTYPE('0TypeRelGuid000000001',#5,$,$,(#31),#30);
Catalogue data (manufacturer, model) goes on the Type; per-instance data
(the Tag asset id) goes on the Component. NEVER place an asset tag on the
shared Type.
Pattern: System grouping
A COBie System groups the components that work together (an HVAC system, a
lighting circuit). IfcSystem members are assigned by
IfcRelAssignsToGroup.
#40=IFCSYSTEM('0SystemGuid000000001',#5,'AHU-1 Supply Air',$,$);
#41=IFCRELASSIGNSTOGROUP('0SysAssignGuid00001',#5,$,$,
(#31,#33,#34),$,#40);
The same component is allowed in several systems through separate
IfcRelAssignsToGroup instances.
Pattern: Job as an IfcTask
A COBie Job is maintenance work. It is an IfcTask, linked to the
component it acts on by IfcRelAssignsToProcess.
#50=IFCTASK('0JobGuid00000000000001',#5,'Filter replacement',$,$,
$,$,'NOTSTARTED','Scheduled',.F.,$,$,.MAINTENANCE.);
#51=IFCRELASSIGNSTOPROCESS('0JobRelGuid0000000001',#5,$,$,
(#31),$,#50,$);
PredefinedType (.MAINTENANCE.) and TaskTime are IFC4 additions. On an
IFC2x3 file IfcTask carries a TaskId instead and has no TaskTime.
Pattern: Document association
A COBie Document is an IfcDocumentInformation plus an
IfcDocumentReference, associated to objects by IfcRelAssociatesDocument.
#60=IFCDOCUMENTINFORMATION('OM-001','O+M Manual AHU-1',$,$,$,$,$,
$,$,$,$,$,$,$,$,$,$);
#61=IFCDOCUMENTREFERENCE('https://docs.example/om-001.pdf',$,
$,$,#60);
#62=IFCRELASSOCIATESDOCUMENT('0DocRelGuid0000000001',#5,$,$,
(#31),#61);
IfcDocumentReference carries either a Name OR a ReferencedDocument,
never both (the WR1 constraint). Here ReferencedDocument is set, so
Name is $; the human-readable title lives on the
IfcDocumentInformation. See ifc-syntax-classifications for the related
external-reference pattern.
Pattern: extracting a COBie subset
COBie export is a SUBSET extraction from a full model. ALWAYS:
- Keep the spatial backbone (
IfcProject,IfcSite,IfcBuilding,IfcBuildingStorey,IfcSpace). - Keep the maintainable components and their types; drop elements with no FM relevance.
- Keep the FM property sets (
Pset_*Common,Pset_ManufacturerTypeInformationand similar); drop analysis and fabrication property sets. - Drop or simplify geometry: COBie needs placement and identity, not parametric detail.
- Keep
IfcSystem,IfcZone,IfcTask, document and contact data.
The result conforms to the Basic FM Handover MVD. See ifc-impl-mvd-export
for the general MVD-subset mechanics and ifc-core-mvd for the MVD model.
Anti-Patterns
Full detail with the failure mechanism is in references/anti-patterns.md.
The ones that matter most:
- Treating COBie as a geometry format and exporting parametric solids. COBie carries non-graphic FM data only.
- Inventing an
IfcCobie*entity. COBie data ALWAYS lives in standard IFC entities; there is no COBie-specific schema. - Mapping a Component to a type object. A Component is a placed occurrence;
the Type is the shared
IfcElementType. - Putting per-instance data (asset tag, serial number) on the Type. The Type holds catalogue data shared by every occurrence.
- Mixing IFC2x3 and IFC4 entity forms in one COBie file. Bind to the single
schema in
FILE_SCHEMA. - Editing the COBie spreadsheet in isolation. The IFC model stays authoritative; spreadsheet-only edits drift from the model.
Reference Links
This skill
references/methods.md: every COBie-relevant IFC entity with attribute signatures, the relationships that wire them, and version notes.references/examples.md: verified STEP physical file instances per COBie worksheet.references/anti-patterns.md: COBie export failure modes and root causes.
Related skills
ifc-core-mvd: the Model View Definition model and the four MVDs.ifc-impl-mvd-export: extracting any MVD subset from a full model.ifc-impl-property-extraction: reading the property sets COBie carries.ifc-impl-data-enrichment: attaching the FM property sets COBie needs.ifc-impl-spatial-decomposition: the Facility, Floor, Space backbone.
Official sources
- MVD database: https://technical.buildingsmart.org/standards/ifc/mvd/mvd-database/
- COBie certification: https://cobiecert.buildingsmart.org/
- IfcZone: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcZone.htm
- IfcSystem: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcSystem.htm
- IfcTask: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcTask.htm
- IfcDocumentReference: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcDocumentReference.htm