Other formats overview:
Introduction
Industry Foundation Classes (IFC) history began in 1994. The intention behind its creation was to provide a neutral and open specification for the exchange of design data in construction and structural engineering applications. There's a term Building Information Modeling (BIM) which describes a paradigm where software is used to model and keep track of all information and processes that pertain to the construction of a particular civil engineering structure. Much like PLM in the mechanical CAD space, it is meant to encompass the entirety of the process, from the initial design stage to construction, acceptance, and building operation.
BIM as a concept isn't new, but the software implementations and data storage mechanisms have historically mostly been proprietary. The vendors naturally used proprietary formats for their AEC applications, and although they did provide some means for neutral data exchange (mainly through general CAD formats such as STEP), the scope of data in such exchange is way smaller than what the applications typically manage. IFC's intent is to fill that void and enable BIM-specific neutral data exchange that keeps track of all the data important for this area. It's been developed by an industry consortium, currently named buildingSMART, and has been an ISO standard since 2005.
Technical details
IFC appears to be inspired by STEP in a few ways. IFC uses the STEP Physical File format described by ISO 10303-21 standard (same as used in STEP). It can also be expressed as XML, as well as a few other esoteric representations, but the STEP Physical File is by far the most common one. An example of IFC file contents is shown below:
The HEADER and DATA sections are present too, with DATA containing the actual model's contents, again as a list of numbered entities, each with a name and a list of parameters.
The IFC scope, although growing with each version, is not nearly as huge as STEP. This mostly has to do with the intention of the format - while STEP aims to be the all-in-one solution for many industries, IFC focuses on BIM. But BIM itself is rather large, so there's still a space for modularity in IFC. The modularity is provided in the form of Model View Definitions (MVDs). They define subsets of IFC entities related to specific use cases, such as:
- design coordination (between architectural, structural, and building services designers);
- structural analysis;
- energy analysis;
- handover to facility management;
- and more.
MVDs allow the creating and receiving software to implement the portions of IFC that are strictly necessary for their purposes and the workflows they provide.
Strengths and weaknesses
IFC provides many entities specific to the architecture and construction domain. For example, there are entity types for structural elements (beams, slabs, etc.) and building elements (walls, columns, doors, etc.), entities for wiring, piping, and HVAC systems. Each carries both generic data, such as geometric representation, which can be read by virtually any software claiming to support IFC, and the element-specific attributes, which express the domain semantics.
IFC models are typically full of metadata and there are a few ways to express it in the format. IFC files can attach properties to building elements in the form of familiar key-value pairs, where values can be text, numerical measurement values with units, lists, enumerations, tables, etc. There's a capability to bundle the individual properties into groups, called property sets. The IFC specification provides a few standard property sets but the authoring applications commonly set up their own to facilitate the transfer of application-specific information. The receiving software can thus expect these properties and use them to provide a richer experience. IFC also provides a special type of properties, called quantities, which can express a certain set of measurable properties of an element together with the description of the measurement method. These act kind of like validation properties encountered in CAD formats.
IFC also provides facilities to model not just the structure being built, but also the processes pertaining to that structure - like design, costing, construction, and operation. It has entities to describe individual steps of processes and to express the sequences of steps, as well as to describe the resources associated with these steps: for example for the construction process these are labor, materials and equipment.
IFC's representation of geometry is another area that has been heavily influenced by STEP. However, naturally, there are peculiarities. Out of two currently used versions of IFC - 2x3 and 4 - the former's range of geometric representations is somewhat limited. IFC 2x3 doesn't support BRep, and most commonly represents the objects with polyhedra, sweeps, or basic CSG shapes (see Fig. 4). While this bounds the potential complexity of individual parts, it has a side effect where rather detailed models with even thousands of parts can be pretty lightweight. IFC 4 removes that restriction by providing support for full BRep shapes, but quite often the previously existing facilities are enough. Furthermore, it'll still be some time until IFC 4 is the dominant version in the real world.
The facilities to represent the model structure in IFC are tailored to buildings. There are entities to represent a site, a building, a building floor, etc. When it comes to parts, there are no instancing capabilities. Conversely the focus is the identity of each element, as well as establishing hierarchical decomposition. This proves it difficult to transfer generic CAD models with parts and subassemblies shared between different assemblies to IFC (which sometimes is required due to the nature of conversion workflow). Technically there are opportunities for data sharing in IFC, but they exist at the level of geometry. On one hand, this is actually rather brilliant - we both get to express the identity of each multiply instanced element, but on the other hand, we save on the geometry duplication. But once again, when expressing the non-BIM data in IFC, the break-up of the part from the geometry for the needs of sharing requires a conceptual rearrangement. Another consequence is that some IFC-producing software does not bother with data sharing at all and simply copies the geometry for every element instance, inflating the model size.
In summary, IFC is a great initiative for making BIM data exchange possible between the software of different vendors. Choosing it is a no-brainer if you operate in architecture or construction space. The same goes for bridging the gap between BIM and another area, like mechanical CAD, though in that case one should be careful to thoroughly test the exchange workflow as some loss of information is possible here.
Example model:
Further reading