SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsifc-impl-cobie

ifc-impl-cobie

Data & analytics

View repository

Updated 10-15 22:18

About this skill

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:

  1. Keep the spatial backbone (IfcProject, IfcSite, IfcBuilding, IfcBuildingStorey, IfcSpace).
  2. Keep the maintainable components and their types; drop elements with no FM relevance.
  3. Keep the FM property sets (Pset_*Common, Pset_ManufacturerTypeInformation and similar); drop analysis and fabrication property sets.
  4. Drop or simplify geometry: COBie needs placement and identity, not parametric detail.
  5. 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