IFC - Industry Foundation Classes/IFC classes

From Wiki.OSArch
< IFC - Industry Foundation Classes
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
IFC bsi icon.png This page is relevant to understanding Industry Foundation Classes (IFC). The Industry Foundation Classes (IFC) Category includes all pages related to Industry Foundation Classes (IFC).

When we talk about BIM concepts, we refer to objects such as walls, doors, and windows. Sometimes we refer to non-object elements like buildings, materials, and annotations. We also refer to other concepts such as coordinates, properties, and geometry. Each distinct noun, element, object, or concept that we refer to is called a "class" in IFC, and is what gives the name Industry Foundation Classes (IFC). The jargon "class", instead of the more widely understandable term "element" or "concept" is borrowed from the software development industry, and remains with us today.

All digital data in IFC belongs to an IFC class. IFC classes can be divided into two categories: rooted and non-rooted classes. Rooted classes inherit attributes from an IFC class called IfcRoot, whereas non-rooted classes do not. This IfcRoot class is special because it provides the following four attributes:

Attribute Required Description
GlobalId Yes A unique identifier of the object, generated by a computer. This is usually created automatically by the BIM authoring tool.
OwnerHistory This special attribute can store names, dates, organisations, software vendor, and contact details of people who are responsible for this object. This is usually created automatically by the BIM authoring tool.
Name This can contain a short text that names the object.
Description A sentence or so to describe the object.

All rooted classes are semantically significant to end-users and created specifically for a project or library. Examples include IfcProject, IfcBuilding, and IfcWall. They are usually annotated in documentation, or named specifically in schedules. These objects are generally useful to end-users, and for this reason can be tracked with a GlobalId and given a Name.

In contrast, non-rooted classes do not have the ability to assign a GlobalId, Name, or otherwise, and are used to store non-project-specific data like XYZ coordinates, RGB colour values, vectors, and so on. One example is IfcCartesianPoint. They are needed from a technical perspective, and are usually automatically generated by the BIM authoring tool, and can usually be safely ignored by end-users. It is important, however, to know that they exist as power users may encounter them when trying to optimise OpenBIM data.

Classes are often described as what they inherit from. For example, rooted classes can be described as classes that inherit from IfcRoot, or subclasses of IfcRoot. If a class inherits from another class, or is a subclass of another class, it inherits the same abilities of that class, such as the ability to have certain attributes, properties, or relationships, assigned to it. Subclasses do not actually inherit the values of the attributes themselves, but only the ability to have that attribute.

Subclasses of IfcRoot[edit]

Rooted classes may be further broken down into three types of classes.

IFC Class Description
IfcObjectDefinition These subclasses describe "objects" or "things" that relate to the AEC industry. This includes walls, people, and tasks. You may think of them as the "nouns" in IFC.
IfcPropertyDefinition These subclasses describe properties of "objects" and "things". They themselves are not an object, but instead a property or quantity like fire rating, energy usage, or volume.
IfcRelationship These subclasses describe relationships between "objects" themselves, between properties, or between objects and properties. The relationships can be objects that contain other objects, connect to objects, have system inputs or outputs, or are assigned a property or quantity.

Subclasses of IfcObjectDefinition[edit]

Although there are many IFC subclasses, there are only a handful relevant to different BIM authors, and it is useful to provide a summary of them. Underneath these handful are many subclasses which go into more detail, but knowing these broad categorisations exist help with an understanding of IFC data. The following table is not exhaustive.

IFC Class Description
IfcContext This special category holds the starting point of IFC data, by describing either a project or library. There are only two subclasses: IfcProject and IfcProjectLibrary. See IFC projects and contexts for more information.
IfcElement These hold physical built elements that we come across every day, like slabs, columns, beams, furniture, pipes, cables, ducts, and so on. Example subclasses of IfcElement include IfcColumn, IfcBeam, and IfcFurniture. They may have geometry associated with them.
IfcSpatialElement These describe spatial concepts, such as sites, buildings, bridges, storeys, and spaces. These IfcSpatialElement classes can contain IfcElement elements inside them, such as a slab being inside a building storey. Example subclasses of IfcSpatialElement include IfcSite, IfcBuilding, and IfcSpace.
IfcElementType These describe construction types. A construction type may be assigned to an IfcElement, just like a particular IfcWall might have a particular construction type of 2 layers of plasterboard on a metal frame. Example subclasses of IfcElementType include IfcWallType, IfcDoorType, and IfcWindowType.
IfcStructuralActivity, IfcStructuralItem These are useful for structural analysis. They hold data to describe an anaytical model, including members, nodes, connections, loads, and forces, as well as the results from the calculations. Example subclasses include IfcStructuralCurveMember, IfcStructuralPointConnection, and IfcStructuralPointReaction.
IfcActor, IfcControl, IfcProcess, IfcResource These are useful for scheduling information, describing responsibility, tasks, resources, and timelines for construction sequencing or project planning. Example subclasses include IfcTask, IfcConstructionMaterialResource, and IfcWorkSchedule.

Subclasses of IfcPropertyDefinition[edit]

The following non-exhaustive table describes common subclasses used to describe properties, which can later be assigned to objects.

IFC Class Description
IfcPropertySet These classes help store properties of other classes, such as IfcElement. For instance, it may store a fire rating associated with an IfcWall. Some properties names and values are standardised within IFC, but end-users can also create their own properties. See IFC attributes and properties for more information.
IfcQuantitySet This is similar to IfcPropertySet but focuses on calculated quantities (lengths, areas, volumes, weights, etc). Some quantity names and values are standardised within IFC, but end-users can also create their own quantities. See IFC attributes and properties for more information.
IfcPropertyTemplateDefinition If you don't want to actually to store the value of a proprety but instead want to describe a template of what properties exist, which are required, and what data is valid for the purposes of exchange requirements or company standards, then this template subclass allows you to do so.
IfcPreDefinedPropertySet For some reason, some properties to do with door and window linings are given a special status in the IFC schema and have their own category. This will likely disappear in the future and merge into IfcPropertySet.

Subclasses of IfcRelationship[edit]

Although there are many IFC subclasses, there are only a handful relevant to different BIM authors, and it is useful to provide a summary of them. Underneath these handful are many subclasses which go into more detail, but knowing these these broad categorisations exist help with an understanding of IFC data. The following table is not exhaustive.

IFC Class Description
IfcRelAssigns This relationship is used when a particular object supplies a resource or fulfills a task for another object. It is commonly used for resource management and construction sequencing, determining processes, resources, and actions performed by people. Example subclasses include IfcRelAssignsToResource, IfcRelAssignsToProcess, and IfcRelAssignsToProduct.
IfcRelAssociates This relationship is used when a particular object has a source of information associated with it, such as an external document, classification system like Uniclass, project library, or material definition. This is commonly used for facility management. Example subclasses include IfcRelAssociatesDocument, IfcRelAssociatesClassification, and IfcRelAssociatesMaterial.
IfcRelConnects This relationship is used when a particular object is joined physically or virtually to another object. This is usually used in analytical models, such as structural analysis where members and nodes connect to each other, MEP systems analysis where ports join together, or environmental analysis, where spaces have boundaries and are covered by particular material layers. Example subclasses include IfcRelConnectsStructuralMember, IfcRelConnectsPorts, and IfcRelSpaceBoundary.
IfcRelDecomposes This relationship is used when a particular object (physical or virtual) is built up of smaller object parts. Smaller parts may be simple aggregated into a larger whole, or projecting from a object, or embed itself within another object. Example subclasses include IfcRelAggregates, IfcRelProjectsElement, and IfcRelVoidsElement.
IfcRelDefines This relationship is used when a particular object can be defined by a common set of definitions, such as properties, manufacturer / construction types, or a template of definitions. This relationship is very commonly used, specifically to define properties (both buildingSMART standard properties, and custom user properties) to objects, and define construction types. Example subclasses include IfcRelDefinesByProperties, IfcRelDefinesByType, and IfcRelDefinesByTemplate.

A summary of non-rooted elements[edit]

There are far too many non-rooted elements to list in totality, however a curated selection as shown below give a indication of the types of data that are stored in an IFC file, which can be reused by rooted elements.

IFC Class Description
IfcMaterial A material may be named, and then have further non-rooted classes assigned to it, such has simple RGB colours, textures, and material properties for environmental simulations.
IfcCartesianPoint As you might expect, IFC can store 2 or 3 dimensional Cartesian coordinates. This is one of the building blocks of many other non-rooted classes, such as the ability to locate an object in space, or build up geometric representations.
IfcFacetedBrep A huge variety of geometric forms may be described in IFC. One commonly known format is a faceted BREP, or series of polygons that describe the surface of an object.
IfcPerson Information about people and organisations can be recorded, which is especially useful as some countries have legislation that requires this to be stored.
IfcPropertySingleValue This commonly used class can define a single property in terms of a property name and its associated value. In addition, there are other classes that allow more complex properties in tabular or calculated form to be stored.
IfcObjective This little-known class can store design intentions, strategies, and objectives to be then associated with objects or portions of the BIM model.
IfcRegularTimeSeries When scheduling, events may occur at predictable time intervals, which may be stored.

List of IFC classes[edit]

There are multiple versions of IFC in use in the industry, and each version has hundreds of IFC classes. This makes it impractical to describe them in their entirety in a separate community wiki. However, there are some resources available for those who do want a list: