COBie 2.4, BS 1192-4:2014 and ARCHICAD 18/19 – Part 3: Component


In the previous two posts about COBie we have looked at Instruction, Contact, Facility and Floor and then Space and Zone. In this post we will look at the data required by COBie 2.4 and BS 1192-4:2014 for Components.

With the exception of 2D, Grids and Spaces everything else we place in an ARCHICAD model is considered a Component in COBie terminology. ARCHICAD users often refer to them as an Element and in IFC they are considered an IfcElement. They could also be referred to as instances. For the purposes of COBie and this blog piece though we will refer to them as Components.

COBie 2.4 Component attributes/properties

COBie Component

Image: COBie 2.4 Component data in Microsoft Excel

Each Component requires 2 core pieces of data as a minimum – Name and Description. Each Component must have a unique Name. For example for doors the Name field may be Door 101, Door 102, Door 103 etc.

Tip: Unique Names can be managed within the ‘Element ID Manager’. Checks for duplication can also be managed in Interactive Schedules.

Beyond the core set of data there are 6 additional pieces of data per Component – SerialNumber, InstallationDate, WarrantyStartDate, TagNumber, BarCode and AssetIdentifier. These would normally be provided by others at a later stage but it is necessary to include these with placeholder data. Serial Number, Tag Number, Bar Code and Asset Identifier should have ‘n/a’ inserted as the default value. Installation Date and Warranty Start Date should have ‘1900-12-31T23:59:59’ as their default value.

All these placeholder values can be automated in the IFC Scheme in ARCHICAD by setting up some very simple mapping. In order to work through setting up the IFC mapping it is necessary to understand which Components need to have this data applied to them. See below in this post for what should be included.

COBie Component Door 2

Image: Typical COBie 2.4 Component data for a Door in GRAPHISOFT ARCHICAD

SerialNumber and BarCode are completed under the Pset_ManufacturerOccurence Property Set.

InstallationDate, WarrantyStartDate, TagNumber and AssetIdentifier are all completed under the COBie_Component Property Set.

COBie Component Schedule

Image: All COBie 2.4 Component data can be scheduled in GRAPHISOFT ARCHICAD

BS 1192-4:2014 Component attributes/properties

BS 1192-4 recommends that the following attributes could be included if required by a client: IsExternal, MountingHeight, IsLoadbearing and Criticality (this is the operational criticality to the Owner/Operator (see BS 8544) and would have values of Very low, Low, Normal, High or Very High).

It is unclear where MountingHeight and Criticality data should be placed in the IFC scheme. Neither of these attributes appears in either the IFC 2×3 or IFC4 schema (as far as I can tell). We will seek clarification and will update this post if and when more information is forthcoming.

Area, Length, ElementalQuantity and Volume are also identified by BS 1192-4 but the user should not need to manually input this data as it can be automated.

For existing Components BS 1192-4 recommends, if a client requires, including AssessmentDate, AssessmentDescription and AssessmentCondition. All of these are to be provided in the Property Set: Pset_Condition. This property set will be standard in IFC4 but for current ARCHICAD models produced in 18 or 19 and using IFC 2×3 it will be necessary to add these fields manually into the IFC Scheme.

One thing that is not made particularly clear in BS 1192-4 is that all of these additional attributes would populate the Attribute sheet rather than appearing on the Component sheet itself.

Which Components?

It is often misunderstood that not every Component is required within COBie. This is true of the NBS approach (in the National BIM Library, BIM Toolkit Level of Information and NBS Product Data Templates), which assumes COBie data is required for every Component in the model. There seem to be some in the industry suggesting that COBie is required for every Component but with little explanation of why.

Of course the more data in the file the bigger the file is so being smart about where data is will ensure your files are optimised for exchange rather than overloading them with data.

Whilst Components not required could be included, as soon as you do it can no longer be called COBie under the terms of the license. COBie is after all a standard so deviating means you have created a bespoke solution. More data on the face of it sounds good but if that data won’t be used then this simply introduces waste to the industry, something that BIM is striving to remove. So if a client specifically asks for COBie then the list below are the Components that should and shouldn’t be included.

This information has been taken from the COBie Responsibility Matrix which can be found here if you want to double check any of the list below. The Responsibility Matrix covers both IFC2x3 and IFC4 formats and there are some differences between the two schemas when it comes to Component classification. The list below covers both and highlights where the differences are between the two schemas. ARCHICAD 18 and 19 currently support IFC2x3, with IFC4 integration yet to be implemented.

IFC Scheme IfcElement

Image: ARCHICAD’s IFC Manager IfcElements (referred to as Components in COBie)

Included Components

Key:  black – ARCHICAD Tags and Categories; blue – IFC classification at the Component/Element level; grey – further notes and additional explanation from buildingSMART of what this element classification includes.

  • Building Element Proxy (IfcBuildingElementProxy) – think of this as “other” when no other category is available (Solibri refers to these as “objects”)
  • Chimney(IfcChimney*) – a user would need to use Building Element Proxy until IFC4 is implemented in ARCHICAD.
  • Ceiling (IfcCovering with a predefined type of CEILING) – see Covering
  • Covering (IfcCovering) – includes predefined types of CEILING, FLOORING, CLADDING, ROOFING, INSULATION, MEMBRANE, SLEEVING and WRAPPING – buildingSMART describes an IfcCovering as “an element which covers some part of another element and is fully dependent on that other element”
  • Discrete Accessory (IfcDiscreteAccessory) – this includes shading devices (note: in IFC 4 this has its only element classification), corbels as separate components, anchor bolts, connecting accessories, electrical accessories for precast concrete elements, fixing parts, joint accessories, lifting accessories and accessories mainly used in the building services domain
  • Distribution Chamber Element (IfcDistributionChamberElement) – buildingSMART describes an IfcDistributionChamberElement as “a place at which distribution systems and their constituent elements may be inspected or through which they may travel”
  • Distribution Control Element (IfcDistributionControlElement) – buildingSMART describes an IfcDistributionControlElement as “elements of a building automation control system that are used to impart control over elements of a distribution system” which includes elements which impart control over flow control elements, sensing elements and controllers
  • Distribution Element (IfcDistributionElement) – buildingSMART describes an IfcDistributionElement as a “generalization of all elements that participate in a distribution system” and includes typical examples such as: building service elements within a heating systems, building service elements within a cooling system, building service elements within a ventilation system, sanitary elements, electrical elements and elements within a communication network
  • Distribution Flow Element (IfcDistributionFlowElement) – buildingSMART describes an IfcDistributionFlowElement as “elements of a distribution system that facilitate the distribution of energy or matter, such as air, water or power”
  • Door (IfcDoor and IfcDoorStandardCase*)
  • Duct Flow Terminal (IfcFlowTerminal) – buildingSMART describes an IfcFlowTerminal as an “element that acts as a terminus or beginning of a distribution system (e.g., air outlet, drain, water closet, sink, etc.)”
  • Energy Conversion Device (IfcEnergyConversionDevice) – buildingSMART describes an IfcEnergyConversionDevice as “a device used to perform energy conversion or heat transfer and typically participates in a flow distribution system”
  • Flow Controller (IfcFlowController) – buildingSMART describes an IfcFlowController as “elements of a distribution system that are used to regulate flow through a distribution system (e.g., damper, valve, switch, relay, etc.)”
  • Flow Moving Device (IfcFlowMovingDevice) – buildingSMART describes an IfcFlowMovingDevice as “an apparatus used to distribute, circulate or perform conveyance of fluids, including liquids and gases, and typically participates in a flow distribution system (e.g., pump, fan)”
  • Flow Storage Device (IfcFlowStorageDevice) – buildingSMART describes an IfcFlowStorageDevice as “a device that participates in a distribution system and is used for temporary storage of a fluid such as a liquid or a gas (e.g., tank)”
  • Flow Treatment Device (IfcFlowTreatmentDevice) – buildingSMART describes an IfcFlowTreatmentDevice as “a device typically used to remove unwanted matter from a fluid, either liquid or gas, and typically participates in a flow distribution system (e.g., air filter)”
  • Furniture (IfcFurnitureElement, IfcFurniture and IfcSystemFurnitureElement*)
  • Lamp (IfcFlowTerminal) – see Pipe Flow Terminal for more information on IfcFlowTerminals
  • Light Fixture (IfcFlowTerminal) – see Pipe Flow Terminal for more information on IfcFlowTerminals
  • Pipe Flow Terminal (IfcFlowTerminal) – buildingSMART describes an IfcFlowTerminal as an “element that acts as a terminus or beginning of a distribution system (e.g., air outlet, drain, water closet, sink, etc.)”
  • Shading Device* (IfcShadingDevice*) – as this will not be available until IFC4 a user should use Discrete Accessory until IFC4 is implemented in ARCHICAD.
  • Tendon (IfcTendon) – buildingSMART describes an IfcTendon as a “steel element such as a wire, cable, bar, rod, or strand used to impart prestress to concrete when the element is tensioned”
  • Tendon Anchor (IfcTendonAnchor) – buildingSMART describes an IfcTendonAnchor as “in prestressed or posttensioned concrete, the end connection for the tendons”
  • Transport Element (IfcTransportElement) includes predefined types of ELEVATOR, ESCALATOR and MOVING WALKWAY
  • Window (IfcWindow and IfcWindowStandardCase*)

Excluded Components

Key:  black – ARCHICAD Tags and Categories; blue – IFC classification at the Component/Element level; grey – further notes and additional explanation from buildingSMART of what this element classification includes; green – IFC Type level.

  • Beam (IfcBeam and IfcBeamStandardCase*)
  • (BuildingElementPart) – available in translator settings
  • Cable Carrier Fitting (IfcCableCarrierFittingType) – this is only covered in the buildingSMART standard at Type level (i.e. IfcCableCarrierFittingType). GRAPHISOFT has created this classification to create a link between the placed Component and the Type information
  • Cable Carrier Segment (IfcCableCarrierSegmentType) – this is only covered in the buildingSMART standard at Type level (i.e. IfcCableCarrierSegmentType). GRAPHISOFT has created this classification to create a link between the placed Component and the Type information
  • Column (IfcColumn and IfcColumnStandardCase*)
  • CurtainWall (IfcCurtainWall)
  • Duct Fitting (IfcFlowFitting) – buildingSMART describes an IfcFlowFitting as “a junction or transition in a flow distribution system (e.g., elbow, tee, etc.)”
  • Duct Segment (IfcFlowSegment) – buildingSMART describes an IfcFlowSegment as “a segment of a flow distribution system that is typically straight, contiguous and has two ports (e.g., a section of pipe or duct)”
  • (ElementPart)
  • Fastener (IfcFastener) – buildingSMART describes an IfcFastener as “representations of fixing parts which are used as fasteners to connect or join elements with other elements”. This includes glue, weld and mortar joints.
  • Footing (IfcFooting) – includes predefined types of FOOTING_BEAM, FOOTING_PILE, STRIP_FOOTING
  • Mechanical Fastener (IfcMechanicalFastener) – buildingSMART describes an IfcMechanicalFastener as “fasteners connecting building elements mechanically”. This includes bolts, nuts, washers, screws, nails and rivets.
  • Member (IfcMember and IfcMemberStandardCase*) – buildingSMART describes an IfcMember as “a structural member designed to carry loads between or beyond points of support. It is not required to be load bearing”. Typically if you use the Curtain Wall tool in ARCHICAD it will be made of Plates (i.e. the panels) and Members (i.e. transoms and mullions).
  • Pile (IfcPile)
  • Pipe Fitting (IfcFlowFitting) – buildingSMART describes an IfcFlowFitting as “a junction or transition in a flow distribution system (e.g., elbow, tee, etc.)”
  • Pipe Segment (IfcFlowSegment) – buildingSMART describes an IfcFlowSegment as “a segment of a flow distribution system that is typically straight, contiguous and has two ports (e.g., a section of pipe or duct)”
  • Plate (IfcPlate and IfcPlateStandardCase*) – buildingSMART describes an IfcPlate as a planar and often flat part with constant thickness”. Typically if you use the Curtain Wall tool in ARCHICAD it will be made of Plates (i.e. the panels) and Members (i.e. the transoms and mullions).
  • Railing (IfcRailing) includes predefined types of HANDRAIL, GUARDRAIL and BALUSTRADE
  • Ramp (IfcRamp)
  • Ramp Flight (IfcRampFlight)
  • Reinforcing Bar (IfcReinforcingBar)
  • Reinforcing Mesh (IfcReinforcingMesh)
  • Roof (IfcRoof)
  • Site Geometry (n/a)
  • Slab (IfcSlab, IfcSlabElementedCase*, IfcSlabStandardCase*) including predefined types of FLOOR, ROOF, LANDING and BASESLAB
  • Stair (IfcStair)
  • Stair Flight (IfcStairFlight)
  • Wall (IfcWall, IfcWallElementedCase*, IfcWallStandardCase)

* IFC4 Components and therefore not yet available in GRAPHISOFT ARCHICAD 18 or 19

Tip: All of these classifications can be preset up in Favorites. Also you can add a piece of data in the IFC Scheme to schedule only elements that have a parameter as “Included for COBie”.

Please note that ARCHICAD also has the element classification “ArchiCAD Type”. This is fine to use when using a specific tool for the classification it was intended. i.e. using the wall tool as a wall or the slab tool as a slab. However, if you are using the tool for another purpose it is important that component/element is correctly classified. Without using the correct classification, for example for a Ceiling that has been modelled with the slab tool, then this would not appear in the COBie output despite being a required Component. This approach of course is equally important where sharing IFC models not just COBie data. I will cover more detail on this in a separate post about IFC.

Category (Classification Reference)

A Classification Reference (Category) is required for all Components* required by COBie 2.4.

COBie-UK-2012 and BS 1192-4:2014 currently use Uniclass 1.4 and Table L which is for Construction products for the Classification Reference. For Uniclass 2 and Uniclass 2015 this would be the ‘Pr Products’ Table. In the US this would be Omniclass Table 23 Products.

* Strictly speaking the Category (COBie) (or Classification Reference as it is referred to in ARCHICAD) should be placed at the Type level for COBie purposes. However this approach in ARCHICAD causes a number of issues. If the Category is placed at the Type level then it means Types must be manually edited. This can cause issues with automation and overriding the Types should be avoided wherever possible in my opinion. This is not always possible (this will be discussed in the next blog post about Types).

Also if the Category is added at the Type level it can not be scheduled within GRAPHISOFT ARCHICAD. Note that we have also found that at present Solibri Model Checker also requires the Category at Component level in order to use Solibri’s COBie resources.

Finally it should be noted that it is not possible to use the Classification Reference (Category) data using ARCHICAD’s labels. This is true in both ARCHICAD 18 and 19. Unfortunately his means this data can not currently be used on 2D outputs.

Component workflow issues in ARCHICAD

The one issue that makes COBie delivery slightly difficult when managing Component data within ARCHICAD is the management of the Name field (which to most ARCHICAD users would be the ID field). This is because if any Component is duplicated it will take the Name/ID of that original Component. Element ID Manager is a useful way to update Components Names/IDs but this workflow is cumbersome when the design continues to evolve after the Element ID Manager has been run.

Unique Component/Element naming (I would call it numbering) is one area where GRAPHISOFT need to make the workflow simpler for users as solving this issue will mean we can automate 100% of the Component requirements needed by designers for COBie.

Conclusion (Component)

Setting up mapping in ARCHICAD means the vast majority of Component data can be fully automated. In fact of the 8 pieces of data only 2 are really required from the designer – Name and Description. Plus you need to add the Category which strictly speaking should be at the Type level (the reasons for which are noted above). This is only 3 pieces of data for each Component/Element. I would suggest that a Description is required for every Component/Element whether it is required for COBie or not. Description forms the basis for other model data usage and in particular quantification and for me is at the heart of a reliable BIM workflow.

In the fourth blog piece in this series we will look at Type data.

Rob Jackson, Associate Director, Bond Bryan Architects


This post has been viewed 2804 times.

2 thoughts on “COBie 2.4, BS 1192-4:2014 and ARCHICAD 18/19 – Part 3: Component

  1. I find it a little odd that some Components are required and some are not. For instance, an anchor bolt or insulation (IfcDiscreteAccessory) are required, but the slab (IfcSlab) and wall (IfcWall) are not. Seems weird to think that FM requires a part number or serial number for an anchor bolt or a layer of insulation.

    Do you find yourself modeling Elements in ARCHICAD that you wouldn’t necessarily model if it weren’t required by COBie? Or do you simply provide the required data for the things that you DO model?

    Love this series, Rob, and I look forward to more. Thanks for sharing so much information.

    • Hi Brian,

      Well i’ll start by saying I didn’t write the standard so these blogs are about what users need to do and not commentary on whether it is right or wrong. There are things in the standard that I also think are a little odd but for me we should aim at the standard as our approach. Deviating from standards means you aren’t using a standard. You either apply them or not.

      At the moment we have’t changed our modelling approach. There aren’t too many architectural elements where a change would be required. We don’t model anchor bolts as this would be a structural element. I think the Covering ones are a little more up for debate but we are typically developing an approach including CEILING, FLOORING and ROOFING predefined types. I would say CLADDING and INSULATION form part of our overall wall constructions and would strictly be called an Assembly in COBie. I’ve always seen the INSULATION predefined type for insulation around pipework which would need to be maintained by FM.

      However, we should also remember that whilst COBie has many fixed aspects the client is responsible for defining what they require. They should only ask for data that they will use as otherwise it is just waste. At the moment few clients in the UK have been through the process and in time I expect the approach to be finessed as more clients understand what they can use the data for.

      And finally thanks for the positive comment. 🙂 Always nice to know readers appreciate the effort.


Leave a Reply

Your email address will not be published. Required fields are marked *