Understanding IFC

Understanding the Spatial Breakdown Structure 

The IFC-schema uses a spatial hierarchy to organize and position physical entities within a construction and infrastructure project. This hierarchy gives you the ability to link specific objects, such as elements of roads, railroads, drains, and light poles, with a named section of the infrastructure e.g. for improved asset management and project organization. 

The illustration below shows the three main structures in the IFC-schema:

• Spatial Breakdown Structure

  • All physical objects must be contained in the spatial breakdown structure with the relation type IfcRelContainedInSpatialStructure. This is the main “backbone” of an IFC data model.

• Functional Breakdown Structure

  • This is a breakdown based on the functionality of the physical objects, like drainage system, fresh water system etc.

• Physical Component Breakdown Structure 

  • Physical objects are often represented in different composition hierarchies. For example a manhole could be an aggregation of bottom plate, cone, extension ring, top lid etc

The illustration below is the standard illustration used in most IFC documents showing these three breakdown structures.

When using the IFC 4.3 object type catalog, you can define the spatial breakdown structure, groups and systems in the model and associate the objects in the model to these structures with the correct relation types. How to do this is explained in chapters further down in this document. 

The illustration below shows the different spatial breakdown entities available in the IFC-schema. There are 5 main domains that are well defined within the schema: Road, Bridge (structures), Railway, Marine Facilities and Buildings. If you are working with a domain that is not represented by one of these predefined domains, then you can use IfcFacility, IfcFacilityPart and IfcFacilityPartCommon to model the spatial breakdown structure in the domain of interest.

The illustration below shows the principal spatial breakdown structure hierarchy. Each organization, responsible for one or several BIM-projects, must define the detailed spatial breakdown structure to be used in their projects.

Note that there are two different relation types in use between physical objects and the spatial breakdown entities:

• IfcRelContainedInSpatialStructure: All physical objects must be connected to the spatial breakdown structure once-and-only-once by this relation type.

• IfcRelReferencedInSpatialStructure: Physical objects can be connected to the spatial breakdown structure many times by this relation type.

Between the spatial breakdown entities the relation type IfcRelAggregates is used. 

A specific example of a spatial breakdown structure is shown below containing a suggested spatial breakdown structure for a road. 

The abbreviations in the illustration above have the following meaning:

PT: The attribute Predefined Type (explained in the next section)
OT: The attribute Object Type (explained in the next section)
CISS: The association IfcRelContainedInSpatialStructure

Note: All the spatial breakdown and group/system breakdown entities are represented as tasks in the model.

Sub-typing of the IFC entities by using the attributes PredefinedType and ObjectType

One of the main benefits of the IFC-schema is that it allows a strict structure to be applied to data sets that help with model interoperability. To fit into the IFC 4.3-schema, all objects imported into an IFC 4.3 object type catalog model must have the proper attribution applied to them. 

Most entities (object types are called entities in the IFC-schema) have an attribute named PredefinedType with specific enumerated values for the given entity. Every enumerated value specifies another (sub) object type. An example is IfcCourse with the PredefinedTypes: ARMOUR, BALLASTBED, FILTER, PAVEMENT etc. The PredefinedType attribute essentially provides another level of object typing without the need for additional “subentity” definitions in the schema.

PredefinedType values are not just informational; various rules apply, such as applicable property sets e.g.. for the different enumerated values given for the PredefinedType attribute. 

If a custom value is needed because you don’t find an enumerated PredefinedType in the schema that covers your modelling requirements, then the free text attribute ObjectType has to be used to define such a custom type. In this case the PredefinedType is set to USERDEFINED.

The main attributes to be provided for an object instance are:

• PredefinedType - Holds the entity-specific enumeration of predefined type values to further classify the entity.

• ObjectType - Allows for a custom value, if no applicable PredefinedType enumerator can be found. The BIM-manual used in the project must define allowed values for the ObjectType attributes for all the entities used in the project.