A Systematic Review of the Trends and Advances in IFC Schema Extensions for BIM Interoperability

Abstract

Numerous studies have developed extensions to the IFC schema to meet the needs of specialized domains or represent nascent technologies, and in turn have expanded the scope of interoperability for BIM data exchanges. However, these studies used varying approaches for IFC extensions and validation, making it difficult to identify research gaps and agree on legitimate extension protocols. This study collected 64 studies of IFC schema extensions spanning over two decades, from 2001 to 2022. The analysis first focused on categorizing these cases with respect to their target domains and sectors, their purpose and extension approaches, as well as their methods for implementation and validation. Timeline analyses were also conducted to track the temporal trends over the specified period. The results revealed that architectural cases have recently shifted from process to product representations due to new technology adoptions, while infrastructure cases, initially centered on major sector elements, have transitioned towards operation and maintenance processes. The findings also showed the need for a more holistic and organized approach for extensions, as current ad hoc developments were limited to products and processes only applicable for specific sectors.

1. Introduction

With the increasing adoption of building information modeling (BIM) throughout the architecture, engineering, construction, and facility management (AEC/FM) industries, its applications are expanding beyond just modeling to include specialized fields, such as quantity take-off, energy analysis, code compliance checking, and structural analysis [1,2,3,4]. The rise in BIM adoption has significantly contributed to the shift from traditional construction project implementation methods towards a model-based collaboration approach, enabling better communication and information workflow [5,6,7,8]. Leveraging BIM model-based collaboration environments has also underscored the need for interoperability of data exchanges among the domain-specific BIM applications used by project stakeholders [9,10].

The industry foundation classes (IFC), an ISO 16739-1:2018 standard [11], offers a neutral and open data format for facilitating the seamless exchange of information between various BIM applications. The IFC provides a comprehensive schema to represent a broad range of concepts and information about objects, attributes, and relationships in BIM models [12]. This foundation allows it to represent not only physical elements in multiple domains including architecture, mechanical electronic plumbing (MEP), and infrastructure, as well as concepts and processes pertaining to the design, construction, and management throughout the life cycle of a construction project [13,14].

The IFC data schema is also under continuous refinement to better suit the evolving needs of the industry. buildingSMART International (bSI), a non-profit, multilateral organization, presides over the maintenance, upgrades, and distributions of IFC development. The technical committees within bSI strive to expand domains and concepts covered within the schema, in tandem with the growing needs of the AEC/FM industry [15]. However, adding and standardizing new domains and concepts involves a collaborative effort, requiring thorough reviews within bSI committees, followed by alignment with ISO standardization procedures. Meanwhile, in less common domains, using the IFCs required creating custom extensions to the schema as a temporary measure before official updates and upgrades were released [16].

Commensurately, numerous studies have suggested ways to extend the IFC schema to meet the needs of specialized domains or encompass nascent technologies. Extension of the IFC involves defining new physical elements or conceptual ideas and integrating them into the existing schema. It facilitates the inclusion of specific data or exchange requirements not initially accommodated by the base schema. These modifications serve to meet industry-specific or project-specific needs, thereby enhancing the effectiveness of data exchange for a wide range of construction and design purposes [17,18,19,20].

With the AEC/FM industry increasingly reliant on data from multiple domains and upcoming technologies, the need for IFC schema extensions has gained greater importance and urgency. A variety of extension approaches have been used throughout IFC’s history; however, a systematic collection and evaluation of these studies remain absent. Although refs. [21,22] have previously provided literature reviews concerning IFCs, they were limited to introducing the historical developments of the standard schema and did not explore in-depth studies related to IFC schema extensions. Different extension approaches, as well as their implementation and validation approaches, may be used depending on the domain of interest and objective, and yet such distinctions have not been evaluated and made explicit. Formalizations of these distinctions can be used as a valuable guide into how future extensions should be made.

This study collected and analyzed 64 cases pertaining to extending the IFC schema over the past two decades, from 2001 to 2022. The analysis focused on several key aspects: ‘the main domains and sectors targeted for extension’; ‘the approaches and purposes of the extensions’; and ‘the approaches adopted for implementation and validation’. Additionally, timeline analyses were conducted on these criteria to track and identify the temporal trends throughout the specified period. The objective was to perform these analyses with the goal of gathering insights that cover the current research gaps and provide specific directions for future extensions.

The structure of this paper is as follows: Section 2 presents the aim of this study and its methodology. Section 3 provides a summary of the evolution and core architecture of the IFC schema, while Section 4 discusses its limitations and introduces the main approaches available for IFC schema extensions. Section 5 presents the findings from the analysis for each of the defined classification criteria. Section 6 summarizes the findings, its implications, and future directions.

2. Research Objective and Methodology

This study conducted a comprehensive review of prior research cases for IFC schema extensions with the goal of determining the extension needs and trends for different domains, identifying the extension approaches used based on the type of requirements, and categorizing the implementation and validation approaches. Specifically, this study aimed to address the following research questions:

• What are the limitations of the existing standard IFC schema that the extension studies attempted to address?

Extension studies typically focus on representing products, processes, and their concepts for a specific domain and sector that were not available in the IFC schema at the time of their research. Thus, categorizing and quantifying these studies with respect to their domain and purpose (i.e., product versus process) would show relative deficiencies of the schema and also highlight the needs of the industry. Conducting a timeline analysis would also provide insights into the temporal trends of how these needs were addressed throughout the period.

• What are the main approaches used to extend the IFC schema with respect to their respective purposes?

The cases also use different extension approaches, e.g., by creating entirely new entities or extending the properties of existing ones. The cases were thus evaluated to determine an appropriate category for the extension approaches to be deployed and subsequently cross-referenced with the purpose of their representations. This would allow generalizations, if any, to be formalized. For example, when representing new products, it is most likely to require new entities, whereas processes may only require adding property sets.

• What are the main approaches used to implement and validate the IFC extensions?

The corpus of cases was evaluated to determine appropriate categories for their implementation and validation approaches. For example, some cases only provided conceptual diagrams of their extensions, while others presented full software implementations. Some cases were limited to demonstrating data interoperability, while others went so far as to show the utility of the achieved exchanges. The distinctions provide insights as to the necessary levels of implementation and validations for acceptance.

• What are the research gaps, insights, and their implications for future research?

Addressing these questions allows to determine which domain and purposes still need developing, and which extension approach should be used for these extensions. It also provides the basis for recommending valid implementation and validation approaches in future extensions.

To address these questions, this study collected publications from online academic publication databases, namely Web of Science and Scopus. The databases include the major journals in construction engineering and management, including ASCE’s Journal of Construction Engineering and Management, ASCE’s Journal of Computing in Civil Engineering, and KSCE’s Journal of Civil Engineering, as well as journals specific to BIM, including Automation in Construction, Advanced Engineering Informatics, and the Journal of Information Technology in Construction. Additionally, conference papers from forums such as CIB W78 and the International Conference on Computing in Civil and Building Engineering were also explored to review more cases. The search period was set from 2001 to 2022, and the search terms ‘IFC schema’ and ‘IFC schema extension’ were used in the keywords and titles to identify relevant papers.

This initial search resulted in a total of 84 papers. Of these, 20 papers were excluded, as these cases were not deemed qualified to be specific extension studies. Specifically, these were cases that discussed the limitations of the existing IFC schema and suggested recommendations generally without specificizing concrete new extensions. In addition, these were cases in which the same authors had published the extension, implementation, and validation processes in multiple papers. Conversely, only cases that made explicit suggestions for either new IFC entities, sub-types, or property sets were considered eligible. The application of these criteria resulted in a total of 64 papers to be included in the corpus used for this study.

Figure 1 outlines the overall research process. The first stage involved a review of the IFC schema itself, focusing on its evolution throughout the years, its basic architecture and inheritance framework, while also reviewing the recommended standard approaches for IFC data exchanges (i.e., the information delivery manual (IDM), and model view definition (MVD)). Following the review, the limitations of the schema and recommended approaches for extending the schema were identified from the relevant literature.

The second stage involved classifying and subsequently quantifying the full corpus of the extension cases. The cases were categorized according to their (1) domains and sectors, (2) extension purposes and approaches, and (3) implementation and validation approaches. A detailed content analysis, similar to [23], was also conducted for each of the combined categories to identify similarities and trends. Finally, the findings were used to derive recommendations for future extension strategies.

3. Evolution, Architecture, and Implementation of the IFC Schema

3.1. Evolution of the IFC Schema

The IFC is an open and neutral file format for the exchange of project lifecycle information within the AEC/FM industry. It is an international standard (ISO 16739-1:2018 [11]) designed to represent digital descriptions of the built asset industry, with the goal of promoting vendor-neutral, or agnostic, and usable capabilities across a wide range of hardware devices, software platforms, and interfaces for many different use cases [24].

To meet the ever-growing needs of the industry, the IFC schema has evolved to encompass new domains as well as related concepts, processes, and related technologies. Figure 2 shows the versions of the IFC schemas released to date. IFC 1.0 was initially released in 1997, while its most current version IFC 4.3 has been under ISO’s Draft International Standards (DIS) voting since 2021. Throughout this period, the schema has been revised multiple times. These revisions are marked by continuous updates that involve the major introduction of new entities and features, refinement of existing functionalities, as well as minor bug fixes.

The varying degrees of updates are represented through the ‘major-minor-addendum (Add1, 2, etc.)-technical corrigendum (TC1, 2, etc.) ((1) ‘Major release’ encompasses expansions or deletions in scope; (2) ‘Minor release’ includes feature extensions with guaranteed compatibility for core schema, but not for other definitions; (3) Addendum comprises improvements to existing features with guaranteed upward compatibility; (4) Technical corrigendum entails enhancements to documentation.)’ notation in which its constituents serve as ancillary qualifiers for the specific version. The revisions not only included additions but also rectifications, consolidations, and deprecations.

Decisions surrounding the official release of an update are reached via a consultation vote conducted by the bSI Standards Committee, the body responsible for schema revisions. An update that gains approval is termed ‘official’ and is rolled out for implementation. Conversely, if an update is deemed to require further enhancements and is thus omitted from the official version, it is classified as ‘withdrawn’.

IFC 1.0 was primarily focused on defining the architecture domain, together with the building services and the construction management domain. With IFC 2, new schemas were added for the structural domain (IfcStructuralAnalysis and IfcStructuralElement) and additional building services (electrical, heating, ventilating, and air conditioning (HVAC), etc.), cost estimation, and construction planning. By IFC 2X3 TC1 (2007), the IFCs started identifying ways to incorporate data with geographic information systems.

A major update occurred with IFC 2X3 to IFC 4 to support new geometric shapes, parametric functions, coordinate system information for GIS linkage, linkage with infrastructure models, etc. These additions and refinements were vital in eliminating structural ambiguities, reducing the complexity of the file format, and boosting the compatibility of the IFC schema [25].

The development continued with IFC 4.1, which enriched the schema with alignment expressions specifically designed for infrastructure structures. The subsequent version, IFC 4.2, expanded the scope of the schema to incorporate elements related to bridge structures. IFC 4.2 also defined a separate spatial hierarchy for infrastructure, specifically for bridges, by defining entities such as IfcFacility and IfcFacilityPart. However, these two minor updated versions were withdrawn to make room for a more comprehensive redevelopment, with an eye on the broader infrastructure domain. The most recent version, IFC 4.3, currently in its final stages of development and on the cusp of an official release, was a significant step forward. It has been designed to comprehensively integrate the infrastructure field, accommodating a diverse range of elements for domains that include rail, roads, ports, waterways, and bridges.

As such, the IFC is ever-evolving, consistently developing to adapt to the dynamic requirements of the AEC/FM industry. However, it is worth noting that there is often a considerable time lag between the development of these updates and their official release and eventual distribution. For instance, the IFC 4 Add2 TC1 update, announced in 2017, remains the most recent official version of IFC. The slow-paced updates mean that the official use of the upgrades may be delayed, but it also has its benefits: it provides time for the broad range of BIM applications to incorporate and operate with the most recent version of the IFC. More importantly, it provides stability for the extension cases, such as those investigated in this study, to explore the ideas and approaches for incorporating new products and processes. Such experiments ensure that new extensions are thoroughly tested and thought out, providing valuable insights into the future versions of the IFC.

3.2. Core Architecture

Conceptually speaking, the IFCs can be thought of as a set of agreements about the semantics, or more practically, an interface agreement to exchange data between software tools tailored for the industry. The IFCs have their roots in the Standard for the Exchange of Product (STEP) (ISO 10303-242:2022 [26]), which is a globally recognized standard for the exchange of product model data across different software applications and computer systems.

The IFCs provide the standard means to represent product models specifically for the AEC industry, by representing the definitions or concepts for products, processes, or resources of various domains through a conglomeration of multiple schemas. These schemas are realized using EXPRESS, a conceptual schema language which provides for the specification of entities belonging to a defined domain, the information or attributes pertaining to those entities, and the constraints on those entities (unique, exclusive, etc.).

The IFC schema is organized into four conceptual layers, i.e., domain, share/interoperability, core, and resource layers. Their definitions, scope, and example entities (which have IFC as prefixes) are provided below:

(1)

Domain layer:

This is the highest layer, which includes schemas containing entity definitions that are specializations of products, processes, or resources specific to a certain discipline. Hence, this layer consists of individual domains for architecture, structure engineering, facility management, etc.

It is noteworthy that each domain definition is typically utilized for intra-domain exchange and sharing of information. In other words, those entities are used exclusively for that domain. Entities within a domain that require sharing with other domains are defined in lower-level schemas.

For example, the IfcArchitectueDomain houses entities such as IfcDoorStyle and IfcWindowStyle, which are both specific door qualifiers exclusive to architectural entities. Similarly, the IfcStructuralAnalysisDomain defines parameters only used for structural engineering analyses, such as IfcStructuralLoadCase or IfcStructuralCurveAction.

(2)

Shared/Interoperability layer:

This layer consists of schemas with entity definitions specific to the general product, process, or resource specializations applicable across multiple disciplines. These definitions are commonly used for inter-domain exchange and where sharing of construction information among various disciplines is expected.

For example, the architectural elements require sharing between all domains and disciplines. Thus, IfcSharedBldgElements includes entities such as IfcWall, IfcSlab, IfcColumn, and IfcDoor, which are elements commonly shared among multiple domains. Similarly, IfcSharedFacilitiesElements includes entities such as IfcFurniture and IfcOccupant.

(3)

Core layer:

This layer incorporates the kernel schema and core extension schemas, housing the most general entity definitions. All entities defined within the core layer or higher layers possess a globally unique ID (GUID), unique reference number used to identify objects, and may optionally include owner and history information.

The schema IfcKernel defines the most abstract part or core part of the specification. It captures general constructs, that are basically founded by their different semantic meaning in a common understanding of an object model, such as an object, property, and relationship. These are, respectively, represented by the entities IfcObjectDefinition, IfcRelationship, and IfcPropertyDefinition, which are subtypes of IfcRoot.

Those are then specialized into non-AEC/FM specific constructs, such as a product, process, control, and resource, which form the main entry points for the next level within the schema architecture, the core extension layer. For example, the IfcProductExtension includes the abstract entities to represent a building element (i.e., IfcBuildingElement), which is then subtyped to the shared elements layer (e.g., IfcSlab). IfcProductExtension also defines entities to define the spatial hierarchical breakdown of project structures using the entities IfcSite, IfcBuilding, IfcBuildingStorey, and IfcSpace.

(4)

Resource layer:

This is the lowest layer and includes all individual schemas containing resource definitions, i.e., basic entities to define geometry, material, quantity, measurement, data, time, etc. Entities and types defined in this layer can be referenced by all entities in the layers above. As resource definitions do not have a concept of identity (such as a GUID), multiple objects referencing the same instance of a resource entity do not imply a relationship.

For example, IfcGeometricConstraintResource defines the resources used to determine the placement of the shape representation of a product within the geometric representation context of a project using entities such as IfcLocalPlacement and IfcGridPlacement.

3.3. Inheritance and Objectified Relations

The IFC schema uses inheritance and objectified relations to leverage the rich semantics defined in each of the layers to specify the properties and attributes of specific entities. Figure 3 provides an example through the entity IfcWallStandardCase. This entity defines a standardized wall with a constant thickness and is a subtype of IfcWall. Both entities, IfcWall and IfcWallStandardCase, are part of the IfcSharedBuildingElements in the shared/interoperability layer and are subtypes of the IfcBuildingElement, which in turn is an entity of one of the core extension layers (i.e., IfcProductExtension). The supertypes of the IfcBuildingElement, IfcElement, and IfcProduct are again subtypes of the kernel entities, IfcObject, IfcObjectDefinition, and IfcRoot.

Meanwhile, the material attributes of the IfcWallStandardCase entity are not encapsulated in the entity itself but specified using IfcMaterial, an entity in the resource layer. Their relation is made explicit using a third entity, IfcRelAssociatesMaterial, which objectifies their relationship. This objectified relation is specified as an inverse expression called HasAssociates and declared in the IfcObjectDefinition entity.

The inheritance structure and objectified relations are realized using rules and expressions defined in EXPRESS, which abide by the objected-oriented programming framework. EXPRESS-G, a graphical modeling notation developed within STEP and used for the definition of IFC, is used to graph the entities, the data attributes of entities, and the relationships that exist between entities.

3.4. IDM and MVD for Software Implementation

As seen in the example, the representation of basic physical elements, attributes, and their relations is mainly realized using three abstract entities, IfcObjectDefinition, IfcRelationship, and IfcPropertyDefintion, which are subclasses of the IfcKernal entity (Figure 4).

Physical elements are exclusive instances of the IfcObjectDefinition entity or its subclasses and mainly reside in the shared layer. The IfcRelationship entity has several predefined subclasses, as shown in

Table 1. Predefined subclasses of IfcRelationship [27].

Predefined Subclasses	Description
IfcRelAssigns	Expresses the relationships that are established when an object needs another object’s service
IfcRelAssociates	Establishes an association between objects or properties and associated information
IfcRelConnects	Defines connectivity relationships between objects
IfcRelDeclares	Establishes an association between one-to-many objects or property templates and the associated information
IfcRelDecomposes	Defines the general concept of elements being composed or decomposed
IfcRelDefines	Defines the relationships between property set and objects

, to qualify the different relational semantics. IfcPropertyDefintion uses a set of subtypes to subscribe needed attributes to the subject entities. Specifically, property sets are used to define a set of predefined properties, which have individual value types. For example, IfcWall has a predefined property set named Pset_WallCommon, which houses default parameters such as FireRating and LoadBearing. Quantities can be similarly defined using quantity sets.

Thus, in software implementation, i.e., implementing an IFC for data exchanges between BIM applications only employs partials or fragments of the IFC schema. In practice, most transactions involve a sender application (which creates a native BIM model) and a receiver application (which needs to receive specific data and information from the original application). Such data exchange requirements are more formally defined using the information delivery manual (IDM) and model view definition (MVD) (Figure 5).

The IDM presents a comprehensive strategy, outlining the specifics of data exchange requirements throughout varying phases of a construction project. It addresses key aspects focusing on the who, what, when, and why of the information needed. This standardization of the information delivery process bolsters inter-stakeholder communication and cooperation while curtailing inconsistencies, duplications, and errors. IDM, as a methodology, effectively segments the expansive IFC schema into smaller, manageable, yet interconnected segments, thus enhancing its usability [28].

The MVD delineates a specific subset of the IFC model specification, which is necessary for the information exchanges laid out in one or more associated IDMs. It crafts a tailored subset of the IFC schema in alignment with specific use cases or project prerequisites, thereby addressing the technical implementation considerations for an accurate representation in software applications. By identifying the requisite IFC entities, attributes, and relationships for each exchange scenario, MVD enhances the efficiency of information exchange. It ensures data compatibility and interoperability across diverse BIM applications [29].

4. Limitations and Extension Approaches for the IFC Schema

4.1. Limitations of the IFC Schema

Despite its evolution and upgraded implementation approaches throughout the years, the IFC still manifests limitations that hamper its active adoption in practice today. The following section summarizes the limitations mentioned in the collected papers as well as those documented in the research related to BIM interoperability and semantic enrichment.

(1)

Limited coverage:

The IFC schema has been progressively enriched by adding new entities via continuous version updates. However, its support scope remains confined to selected domains. For instance, since the original versions of IFC development started with the architecture domain, it was unable to support entities of other domains (e.g., infrastructure), nor specialized elements related to state-of-the-art technology, and information particular to regional or specific projects. Before the introduction of IFC 4.3, representing bridge elements in IFCs involved either selecting and temporarily using architecture domain IFC entities that resembled bridge elements (e.g., IfcSlab) or extensively utilizing IfcBuildingElementProxy elements, which represent nominal physical elements. These approaches provided a makeshift way to represent bridge elements in IFCs, but failed to represent the semantics sufficiently and exclusively for bridge element properties and their interrelationships. Such limitations created the potential for creating errors and omissions when exporting IFCs between bridge-specific BIM applications, ultimately failing to provide data interoperability in the infrastructure domain [30,31].

(2)

Lagging behind regional practices and evolving technologies:

The IFC schema, as distributed by bSI, is conceptualized as a ‘standard’ schema designed for general applicability. Consequently, it lacks the flexibility to account for the diverse laws, regulations, and standards that vary across different countries and regions. Moreover, the content and scope of support for each new iteration of the IFC schema are subject to elaborate discussion and voting by the bSI Standards Committee. This rigorous vetting process often results in considerable time lags before the official release, making it challenging to promptly integrate emerging technologies from the AEC/FM industry into the schema [17].

Conversely, depending on their local conditions and BIM maturity rates, the speed of adoption for new IFC releases typically varies across countries. Those parties or institutions that do not have the resources to upgrade local software and processes find it difficult to keep up with the latest updates, which can also lead to asynchronous use of the IFC standard.

(3)

Selective implementation of the schema in IFC-compliant software:

The major BIM authoring tools available today have different levels of support for MVDs. That is, these tools provide the most widely used MVDs (e.g., coordination view, design transfer view), but often do not provide the required export functions for the more specialized views [32]. Such restrictions make exporting IFCs inconsistent. The problem is compounded as these tools may incorporate different STEP functions for an IFC translation: Digital Project and Bentley Architecture have both adopted ST-Developer software as their underlying STEP toolkit for developing their IFC translators. Revit Building uses EURO-STEP, and ArchiCAD uses express data manager (EDM) from EPM Technology [33]. These varied implementations can result in different structures and entities used for the same type of information.

Moreover, even entities officially released and correctly used may not manifest in receiving software that is IFC-compliant. For instance, the entity IfcClassification is the official entity recommended to represent standard classification systems, such as UniClass and MasterFormat. However, several IFC viewers, such as the FZK Viewer and Open IFC Viewer, do not support the importation of the entity. Consequently, information entered into IfcClassification is not manifested in these receiving applications, leading to critical omissions in data exchanges.

(4)

Incomplete implementation of domain information needs:

Throughout their development, the IFCs have progressively added new specialties into their domain layers to meet the growing needs of the industry. For instance, early on, they added a structural element and an analysis domain, followed by domains for MEP disciplines, and most recently for infrastructure sectors (e.g., road and rail, etc.) (Figure 6). Unfortunately, even officially released domains and their relevant entities are, in many cases, not sufficient to properly represent the needed semantics and attributes required in that specialty. An illustrative case is the IfcStructuralLoad entity in the structural analysis domain. The entity is designated to house the output values of structural analysis results [34]. However, existing studies show that this entity’s specifications are not comprehensive enough to encapsulate the various structural analysis-related parameters routinely used in practice [30]. The incomplete representation of such needs limits its use and thus stipulates the need for custom IFC extensions.

4.2. Approaches for IFC Schema Extension

The IFC schema can be extended primarily using two approaches: either by creating entirely new entities or integrating and/or linking additional information to existing entities. Within the scope of this study, they are designated as an ‘entity extension’ and a ‘property extension’, respectively.

(1)

Entity extensions:

Entity extension is a method where users directly define new entities. This approach typically involves creating sub-entities to an existing schema or modifying the schema with grouped entities for a novel domain. When defining a new IFC entity, several key considerations come into play: object-oriented principles, inheritance mechanism, attributes, relationships, and compliance with the IFC specification. This approach offers the advantage of allowing users to express previously unsupported domains and inherent entities according to their specific definitions alongside corresponding specialized attributes with sub-typing, which means a methodology for adding specifications under IFC schema according to EXPRESS data modeling rules [35]. However, if these extensions are not registered as part of the standard schema, they can only be used by software that has been customized to recognize the new entities. Thus, for general applicability, the new entities have to be formally introduced into the IFC schema to be recognized in general software and their built-in MVDs [36].

(2)

Property extensions:

Property extension refers to the technique of adding and integrating new classifications, taxonomies, and attributes to further qualify existing entities. The IFCs enable property extensions mainly by using type entities or defining custom property sets. Type entities, such as element type (IfcElementType) or space type (IfcSpatialElementType), are used to qualify specific entities into more detailed classifications. For example, IfcBeam uses IfcBeamType, which is a subtype of IfcBuiltElementType in IfcElementType, to further denote beam types. These entities also allow custom types through the use of USERDEFINED attributes. For property sets, the IfcPropertySetDefinition, part of the property segment, is linked to the IfcObject from the object segment through IfcRelDefinesByProperties, a relational entity. Additionally, for widely used items, predefined entities for properties are established in advance to ensure the transparent conveyance of information. In such instances, IfcPreDefinedProperties are deployed. Compared to the entity extension method, this approach is advantageous in direct compatibility with general software, as it does not alter the IFC schema itself.

More recent developments allow linking external data using reference pointers or linking features. This approach offers enhanced usability as it links and integrates information into an already-existent entity, preserving the integrity of the schema. Three methodologies for implementing this latter approach have been proposed by bSI, which are detailed as follows [37]:

(1)

IfcClassification:

Classification is the systematic arrangement or categorization of objects or elements based on specific characteristics or criteria. The IfcClassification entity within the IFC schema symbolizes such classification systems, offering a conduit to reference an external classification system. It can establish associations with other entities in the IFC model, such as objects or property definitions, using IfcRelAssociatesClassification. This mechanism enables the application of diverse classification systems in conjunction with IFC, promoting a standardized and consistent classification of objects within an IFC model.

(2)

Linkage with the bSDD and OTL:

The buildingSMART Data Dictionary (bSDD) and other object-type libraries (OTLs) offer industry-specific terminology in a structured, computer-readable format. To facilitate this computer-readability, ontologies, which define concepts, properties, and relationships, are employed. The bSDD and OTLs are linked to each entity through either the previously described ‘classification’ approach or the forthcoming ‘Linked Data Approach’.

(3)

Linked Data Approach:

This method interlinks multiple datasets, each modeled in a different schema, with the entities embedded within the IFC schema. This procedure requires using semantic web technologies, notably the Web Ontology Language (OWL). In this context, bSI furnishes an ifcOWL schema, a direct manifestation of an IFC in the form of a OWL, thereby enabling such linkages.

Additionally, bSI emphasized the following point and recommended attempting information extension prior to entity extension:

“Once the best match in existing IFC class hierarchy has been found for a new concept, it should be considered if the existing entity type can be used as such, either (1) with associated external classification (and property definitions) for further specialization, or (2) by extending its definition and adding to its available predefined types and corresponding property sets. Only when neither of these approaches is satisfactory should a new subtype of an existing entity type be considered (or adding attributes to a leaf node type) [37]”.

5. Evaluation of IFC Schema Extension Cases

5.1. Overview of Extension Cases

Our corpus of papers includes a total of 64 publications that document the extension of the IFC schema to meet particular domain-specific engineering and management requirements. As per the data in Figure 7, a significant rise in publications was observed from 2013 onwards, and culminated in 2017. This increase is believed to be influenced by the release of IFC 4 in 2013, which highlighted the potential extensions in the infrastructure domain, thus spurring greater interest in exploring necessary extensions for the infrastructure sector in BIM.

The following sections introduce the trends identified in these extension efforts. Specifically, the studies were classified and evaluated with respect to (1) their domains and sectors, (2) product and process representations, and (3) implementation and validation approaches. Timeline analyses were also selectively performed for these criteria to determine the temporal trends over the defined period.

5.2. Analysis of Extension Cases via Domains and Sectors

Table 2. IFC extension cases categorized into domains and sectors.

Domain	Sector	No. of Cases	Total
Architecture	General building	18	20
	MEP	2
Infrastructure	Tunnel	11	46
	Bridge	11
	Road	7
	Railway	6
	General structure	4
	Dam	1
	Earthworks	1
	Foundation construction	1
	Georeferencing	1
	Harbor	1
	Plants	1
	River facility	1

Some cases addressed two sectors simultaneously.

presents the number of IFC schema extension cases categorized into domains and sectors. A total of 20 of the cases were in the architecture domain, while the other 46 cases were in the infrastructure domain. The number of IFC schema extension cases for the infrastructure domain was more than double that of those in the architecture domain. The difference reflects the historical need of the industry to extend the IFC schema for representing products, processes, and related concepts in the infrastructure domain. Conversely, it also reflects the lack of representation for the infrastructure domain in the IFCs, which only started being partially addressed with version 4.0.

Within the architecture domain, most extensions targeted the general building sector, followed by a few extensions for MEP. The extension cases for infrastructure mainly focused on the tunnels, bridges, and roads sectors, followed by more specific sectors such as dams and harbors, as well as specific subsectors such as foundations and earthworks.

5.3. Analysis of Extension Cases by Product and Process Representations

As discussed in Section 4.2, the extension cases can be broadly categorized as either ‘entity’ or ‘property’ extensions. The extension studies were also classified as either ‘product’ or ‘process’ representations to distinguish their purpose or the target of their extensions. Product representations refer to cases that mainly focus on the representation of physical elements previously undefined in the existing version of IFCs. Process extensions refer to cases that focus on representing conceptual work and management procedures as well as the properties required in designing, constructing, and maintaining the built facilities. This distinction allows to further elicit the industry’s needs in IFCs as well as to provide insights into the evolving development of IFC extensions through trend analyses.

Table 3. Objectives, main purposes, extension approaches of existing cases.

Domain	Sector	Objective	Main Purpose		Extension Approach
			Product Oriented	Process Oriented	Entity Extension	Example	Property Extension	Example
Architecture	General building	Define components for RFID [38]	O		O	IfcRfidSystem	O	Pset_ElectricalDeviceCommon
		Define space [39,40]	O		O	IfcBuildingPropertyUnit	O	Representation, BoundedBy
		Define fire [41]			O	IfcFireSafetyElement	O	Pset_FireSpread_F
		Link 2D drawing information [42]		O	O	IfcPresentRepresentation	O	Symbol color, text style
		Link structural analysis information [34]		O	O	IfcStructuralActivity	O	Material, profile
		Incorporate design changes [43]		O	O	IfcRelElementChange
		Define the concept for the point cloud model [44]		O	O	IfcPointCloud	O	Vector, colors
		Define features for modular buildings [45]		O	O	IfcConnectionPointJointType	O	PointOnRelatingElement
		Link design guideline information [46]		O			O	Pset_SiteCommon
		Define concepts and taxonomies for construction cost [47]		O			O	Pset_in-situ concrete wall
		Link O&M information [48,49,50]		O	O	IfcMaintenanceHistory	O	MaintenanceType
		Define a structure for building code compliance [51,52,53,54]		O			O	Pset_BuildingCodeChecking
	MEP	Define the type of sensor components [55]		O			O	Temperature sensor, Flowrate sensor
		Define control function for HVAC [56]	O		O	IfcThermodynamicTemperatureMeasure	O	Pset_HeatingCurve
Infrastructure	Tunnel	Define components for NATM tunnel [57,58]	O		O	IfcConcreteLiningProfileDef	O	PSET_ConcreteLining
		Define components for the TBM tunnel and excavation machine [59,60,61,62,63,64]	O		O	IfcRingSegmentElement	O	tbmHeadType
		Define alignment concept [65,66,67]		O	O	IfcHorizontalAlignmentLine	O	Space type (FullTunnelSpace, Interior space)
	Bridge	Define elements for bridge components [68]	O		O	IfcBridgeElement	O	ConcreteProperties, RebarProperties
		Define components for steel bridge [69,70,71]	O		O	IfcBridgeProfileDef	O	Characteristic information of bridge
		Define the parametric geometry concept [72,73]		O	O	IfcParametricProfileDef	O	OverallHeight
		Link asset management information [74]		O	O	IfcTransportationNetwork	O	Pset_TransportationNetworkCommon
		Link inspection information [75,76,77]		O	O	IfcMeasuredRegion	O	RelatingRegion
		Incorporate finite element analysis information [30]		O	O	IfcBridgeSpan	O	Continuity
	Road	Define road component [78]	O		O	IfcRoadSpatialElement	O	Partial type
		Define components for drainage facility [79]	O		O	IfcGutter	O	Pset_GutterCommon
		Define components for subsidiary facility [80]	O		O	IfcSubsidiaryFacility	O	Pset_RoadSignEquipmentCommon
		Define alignment concept [81]		O	O	IfcAlignment2DVertical	O	TangentialContinuity
		Link asset management information [74]		O	O	IfcTransportationNetwork	O	Pset_TransportationNetworkCommon
		Link O&M information [82]		O	O	IfcTechnicalSolution	O	Pset_ProcessDescriptionCommon
		Define quantity take-off concepts [83]		O			O	Pset_CulvertCommon, Qto_CulvertCustomQuantities_2WayWaterwayType _K
	Rail	Define components for rail tracks and ties [84,85]	O		O	IfcTrackStructureElement	O	PSET4RMODEL
		Define components for subgrades [86]	O		O	IfcSubgrade	O	SubComponent
		Define alignment concept [87]		O	O	IfcTrackTurnout	O	IfcTrackTurnout TypeEnum
		Define semantic and parametric concepts [88]		O	O	IfcCurveSegment2D	O	StartPoint, SegmentLength
		Link inspection information [77]		O		IfcTrackFastening	O	Pset_RailCommon
	General structure	Link structural health monitoring information [14]		O	O	IfcSensorNetwork	O	NetworkTopology
		Define the concept for project performance evaluation indicator of PPP [89]		O			O	PSet_ Performance evaluation during construction period
		Link product information and work control information for rebars [90]		O	O	IfcReinforcingSpiralType	O	SpiralLength, SpiralDiameter
		Define the concept for the finite element model [91]		O			O	Pset_AppraisalResult
	Dam	Define components for 3D tiles [92]	O		O	IfcDamElement	O	Functions, materials
	Earthworks	Define components for earthworks [93]	O		O	IfcEarthWorkElement
	Foundation construction	Link schedule and quality information [94]		O	O	IfcQualityManagement	O	Inspection time, design code
	Georeferencing	Link georeferencing information [95]		O	O	IfcGeographicCRS	O	GEODETICDATUM
	Harbor	Define components for quay walls [18]	O		O	IfcQuay	O	Link predefined properties in bsDD
	Plants	Define components for wastewater treatment plants [19]	O		O	IfcTank	O	SludgeVolumeIndex
	River facility	Define components for river facilities [96]	O		O	IfcRiverElement

shows the extension cases classified according to the following criteria. Each case was classified with respect to its purpose (i.e., product or process representation), together with the extension approach used (i.e., entity or property extension). Examples of the newly defined entities and properties in each case are also provided. The subsequent sections present a detailed discussion of these analyses, segmented into specific domains and sectors.

5.3.1. Detailed Analysis of Extension Approaches in the Architecture Domain

Table 4 shows extension cases in the architecture domain classified according to representations and extension approaches. Four cases defined new entities and their related properties to represent new elements (i.e., products), while the other eleven cases involved defining entities and properties to represent newly defined processes. There were no cases in which property extensions were used exclusively for products, whereas five cases existed for process representations. The following details the cases in the resultant groupings:

(1)

Product-oriented representations:

-

Using entity and property extensions.

Refs. [39,40] extended entities to define spaces either for space application support or legal conformance analysis. Ref. [38] extended entities required to represent sensing devices, such as RFID and IoT, while ref. [41] defined entities and their related attributes for novel firefighting systems. These cases also naturally used sub-typing using object types and/or property sets to represent different categories within these devices and systems.

(2)

Process-oriented representations:

-

Using entity and property extensions.

Refs. [42,51] defined entities to represent sketches and 2D drawing information that would enhance the parametric modeling capabilities of BIM models. Ref. [34] extended entities and relationships to bolster the representation of structural engineering models and refs. [48,49,50] to facilitate O&M data management. Furthermore, with the increased availability of point cloud data in the architecture domain, ref. [44] created a new schema, named IfcPointCloud, to incorporate point cloud models within the IFC schema. Similarly, ref. [45] formulated entities and related properties to characterize feature relationships intrinsic to module design processes, catering to the growing interest in modular buildings.

Another characteristic of process representation was to extend entities via subtypes of IfcRelationships (to IfcObjectDefinition) to specify new procedures. For example, ref. [43] introduced new relationship entities, such as IfcRelElementChange and IfcRelFeatureChange, to monitor changes in BIM models during the design phase, thereby facilitating version management during IFC information exchanges.

The MEP sector was also addressed by [56], who introduced entities and defined specific properties to facilitate control functions, such as managing heating curves and setting time schedules for air handling.

• -

  Using property extensions (exclusively).

Six of the studies only extended the schema by defining property sets and/or using sub-typing. Ref. [46] incorporated architectural design guideline details as property sets and ref. [47] formulated property sets to capture concepts for construction cost estimation. Likewise, refs. [52,53,54] introduced supplemental property sets for building code compliance. Similarly, ref. [55] expanded the schema to incorporate sensor data from IoT sensor networks into the BIM model. Instead of defining additional property sets, they further delineated enumeration types for the IfcSensor entity to link with existing property sets more precisely.

These cases did not create new entities but focused on extending the properties or defining additional enumeration types of existing entities in the IFC schema.

In summary, the majority of the cases in the architecture domain were developed for process representations. These extensions mostly utilized ‘entity and property extension’ approaches to represent concepts and processes for the analysis or management of data in specific fields, such as structural analysis, MEP and O&M procedures, and module design. A few select cases for cost control and code compliance exclusively used property extensions to define the required values and attributes of existing entities.

The rest of the cases did extend to product representations but were used for integrating new technologies or systems. The focus on processes in the architecture domain is understandable, as most building elements had already been defined and formalized in earlier versions of the IFC schema.

Table 4. Extension cases by approach type in architecture domain.

Extension Approach	Sector	Product Oriented	Number of Cases	Process Oriented	Number of Cases	Total
Entity + Property	General building	[38,39,40,41]	4	[34,42,43,44,45,48,49,50,51]	9	13
	MEP	-	-	[56]	1	1
Property only	General building	-	-	[46,47,52,53,54]	5	5
	MEP	-	-	[55]	1	1
Total		-	4	-	16	20

Table 4. Extension cases by approach type in architecture domain.

Extension Approach	Sector	Product Oriented	Number of Cases	Process Oriented	Number of Cases	Total
Entity + Property	General building	[38,39,40,41]	4	[34,42,43,44,45,48,49,50,51]	9	13
	MEP	-	-	[56]	1	1
Property only	General building	-	-	[46,47,52,53,54]	5	5
	MEP	-	-	[55]	1	1
Total		-	4	-	16	20

5.3.2. Detailed Analysis of Extension Approaches in the Infrastructure Domain

Table 5 presents the cases of extensions in the infrastructure domain, categorized based on their representations and extension approaches. A total of 22 cases utilized entity and property definitions to represent new products, whereas 21 cases defined entities and related properties to represent new processes. No cases relied on property extensions for product representations, although three cases defined properties exclusively for introducing new processes. The following provides detailed analysis results according to the specified criteria:

(1)

Product-oriented representations:

-

Using entity and property extensions.

Entity and property extensions were used heavily to represent the major types of structures in the infrastructure domain. In the bridge sector, efforts were marked by [68,69,70], who devised approaches to represent the basic types, components, and related properties of bridges. The road sector was also addressed by [78], who delineated entities representing spatial elements and further refined them to depict curvilinear features. Subsequently, ref. [79] developed entities for drainage facilities, followed by [80] who introduced additional entities to capture details of elements in auxiliary facilities.

Several studies were directed towards improving the representation of tunnels and their construction methods. Early on, ref. [59] established entities to represent the soil layers and conditions required for shield tunneling as well as entities for caves and caverns. Refs. [60,61] expanded upon this study by proposing supplementary entities to facilitate multi-scale representations of shield tunnels. Ref. [57] centered their efforts on representing NATM tunnels as well as on introducing new entities of IfcTunnelElement and its related subtypes and attributes. Similarly, ref. [64] designed entities for TBM tunnel boring machines. Ref. [58] went further to encapsulate various aspects of TBM tunnel elements, such as ground and boring machine models. Ref. [63] suggested new entities, such as IfcStation, to be used exclusively for underground metro stations.

A string of studies was also conducted for the rail sector. Ref. [84] introduced entities that distinctly outlined tracks and ties. This was later expanded by [87], who continued to innovate this topic by incorporating alignment concepts and thus enabling differentiations between physical and spatial elements. Recently, ref. [86] crafted entities to represent rail track drawing details and distinguish between multiple layers present in rail subgrades.

Other studies worked on representing entities for specialized sectors: ref. [92] defined entities for 3D tiles in dams, ref. [18] for quay walls of harbor facilities, and ref. [19] for elements in wastewater treatment plants. A few notable cases focused on representing entities for different types of civil works: ref. [93] introduced entities required for earthworks, while ref. [96] defined new entities to represent work in rivers (e.g., dredging).

(2)

Process-oriented extensions:

-

Using entity and property extensions.

Numerous cases involved using both entity and property extensions to integrate various engineering analysis and management approaches in infrastructure BIM models.

For bridges, refs. [72,73] defined entities such as IfcParametricProfileDef and IfcParametricSketch to enable the addition of geometric and dimensional constraints, consequently enabling parametric modeling in bridge BIM models. Ref. [30] designed specific entities tailored to facilitate finite element analysis of bridge models. Other cases involved expanding the schema to incorporate processes for bridge inspection and maintenance. Ref. [76] extended the schema by introducing new entities to encapsulate bridge inspection data and explored methodologies for converting this new schema into ontologies to enhance information management. Ref. [75] established entities to systematically catalog degradation and data gathered during bridge inspection tasks. Ref. [74] broadened entity definitions to encompass asset management, creating schemas for various supplementary facilities. Ref. [77] crafted entities to store and utilize sensor readings in bridge O&M.

Cases in the tunnel and road sectors were similar in defining entities to represent alignment and for operations and management. Specifically, refs. [65,66] defined entities specifically for tunnel alignment, while ref. [67] focused on designing entities for tunnel O&M information. For the roads sector, refs. [74,81] also defined separate entities for road alignment, while ref. [82] defined entities for road operations management.

Studies were also performed in the rail sector exclusively for set requirements. Ref. [88] proposed new entities to represent rail geometry, such as transition curves and chainage systems, while ref. [85] defined entities and related properties to represent alignment concepts of railways. Ref. [76] developed entities to represent sensors affixed to railway facilities, which were used to collect O&M data.

Several studies have focused on creating representations for entities within specialized fields. Ref. [94] developed entities to encapsulate critical scheduling and quality data generated during the foundation construction phase, while ref. [95] introduced supplemental entities to effectively represent georeferencing data. Three cases were sector-agnostic: Ref. [14] created the ‘IFC Monitor’ extension to facilitate the transfer of BIM-based structural health data, introducing unique entities for sensors and their network structures. Ref. [89] devised extensions to incorporate concepts and processes in public–private partnerships (PPP) projects, while ref. [90] developed extensions tailored to steel reinforcement product details and manufacturing information.

• -

  Using property extensions (exclusively).

Three cases existed in which property extensions were solely utilized to represent processes. Ref. [71] utilized property sets to describe the semantics for the physical and spatial components in a steel box girder bridge. Ref. [83] defined property and quantity sets to describe the protocols for quantity take-off of road facilities. Ref. [92] used properties and IfcProxy to streamline finite element analysis on IFC-standard geometric models. It is worthwhile to note that these cases appropriated entities from the architecture domain as substitutes or proxy entities, as formal IFC entities for their respective sectors did not exist at the time of their research.

In summary, most cases in the infrastructure domain utilized ‘entity and property extension’ approaches to develop both product and process representations. Product representation efforts mainly focused on defining elements to cover the sectors missing in the standard schema with respect to infrastructure. Meanwhile, process representations predominantly aimed to illustrate information critical for alignment representation, asset management, and O&M, or devised extensions to enable engineering-centric analyses, such as finite element analysis. A few cases exclusively adopted ‘property extension’ approaches for process representations, using architectural domain entities as proxies.

Furthermore, sectoral differences were marked in extension objectives: bridge sector cases largely focused on process representations, whereas the tunnel sector primarily targeted product representations. This divergence is attributed to the different structures of bridges and tunnels. Bridges allow the utilization of entities from the architectural domain due to their components, such as IfcSlab, IfcColumn, and IfcBeam, while tunnels, with their variety of unique components, necessitate independent representation and definition.

Table 5. Extension cases by approach type in infrastructure domain.

Extension Approach	Sector	Product- Oriented	Number of Cases	Process Oriented	Number of Cases	Total
Entity + Property	Tunnel	[57,58,59,60,61,62,63,64]	8	[65,66,67]	3	11
	Bridge	[68,69,70]	3	[30,72,73,74,75,76,77]	7	10
	Road	[78,79,80]	3	[74,81,82]	3	6
	Rail	[84,86,87]	3	[76,77,85,88]	3	6
	Other	[18,19,92,93,96]	5	[14,89,90,94,95]	5	10
Property only	Tunnel	-	-	-	-	-
	Bridge	-	-	[71]	1	1
	Road	-	-	[83]	1	1
	Rail	-	-	-	-	-
	Other	-	-	[91]	1	1
Total		-	22	-	24	46

Table 5. Extension cases by approach type in infrastructure domain.

Extension Approach	Sector	Product- Oriented	Number of Cases	Process Oriented	Number of Cases	Total
Entity + Property	Tunnel	[57,58,59,60,61,62,63,64]	8	[65,66,67]	3	11
	Bridge	[68,69,70]	3	[30,72,73,74,75,76,77]	7	10
	Road	[78,79,80]	3	[74,81,82]	3	6
	Rail	[84,86,87]	3	[76,77,85,88]	3	6
	Other	[18,19,92,93,96]	5	[14,89,90,94,95]	5	10
Property only	Tunnel	-	-	-	-	-
	Bridge	-	-	[71]	1	1
	Road	-	-	[83]	1	1
	Rail	-	-	-	-	-
	Other	-	-	[91]	1	1
Total		-	22	-	24	46

5.3.3. Extension Trends Comparison between Architecture and Infrastructure Domain

Figure 8 shows the timeline for the number of extension cases performed for the architecture domain between 2001 and 2022. The red and blue lines show the trends for product and process representations, respectively. The trend lines show that most of the extensions comprised process representations throughout the period. However, this trend started to change starting in 2018, and there were more extensions for product representations in 2022. The trendlines reinforce the evaluations discussed in Section 5.3.1. That is, as the initial IFC schema already had comprehensively defined elements in the building domain, most extension efforts focused on representing concepts and processes required for engineering analysis and project management procedures. The increase in product representations near the end of the period represents the recent trend of initiatives to integrate information from new technologies (e.g., IoT, point cloud data, etc.) and building systems into the IFC schema.

Figure 9 shows the corresponding timeline for the infrastructure domain. The trend lines show that extensions initially focused on product representations, which were later followed by a rise in process representation cases. Although product representation cases remained steady, there was a notable uptick in the cases focusing on process representations. Specifically, from 2019 onwards, the number of process representation cases began to overtake those of product representation cases. As discussed in Section 3.1, this shift can be primarily attributed to version 4.0 of the IFC schema, which introduced base entities for infrastructure, which were provided in part by the preceding extension studies in product representations. Such trends are similar to those observed in the architectural domain. That is, as the core of entities for products matured, there was an escalated interest in representing process information, encompassing areas such as structural analysis, inspections, O&M, and design details.

5.4. Detailed Analysis of Extension Implementation and Validation Approaches

5.4.1. Analysis of Implementation Approaches

The corpus of extension cases used different approaches to implement their extensions, and these approaches could also be largely categorized by the extension approaches, i.e., entity or property extensions.

For entity extension cases, the main approach for implementation was the use of STEP toolkits. As delineated in Section 4.2, integrating new entities requires associating their geometry and relations in accordance to the existing entities of the IFC schema while conforming to object-oriented principles and inheritance hierarchies. STEP toolkits facilitate this process. For example, ST-Developer enables the creation of class libraries for geometry and associated information pertaining to new entities using either C++ or Java. The class libraries can be subsequently compiled and added into the IFC export functions of BIM authoring tools, enabling BIM elements to be mapped to the new entities. Extension cases conducted by [30,87] used STEP toolkits for such purposes. They first designed new entities utilizing EXPRESS, which were subsequently translated into Java/C# class libraries using ST-Developer and added into the Revit API as part of its IFC translator.

Cases limited to property extensions predominantly used mapping functions directly supplied by major BIM authoring tools. As mentioned in Section 4.1, these tools provide export functionalities that allow the mapping of parameters to IFC properties. For instance, Revit allows property extensions by enabling users to define new parameters and then subsequently to provide mapping functionalities prior to exporting an IFC. The process can be semi-automated by loading predefined text-based mapping tables. This method was employed by [83] to define additional properties required for representing cost information in road construction.

Other cases did not document their implementation approach but expressed their design using EXPRESS-X or EXPRESS-G, which are extensions of the EXPRESS language. EXPRESS-X is a model mapping language developed for the purpose of transforming models defined according to ISO 10303 standards. For IFC extensions, it facilitates the provision of mapping information during the transition of a BIM model to an IFC physical file (IPF). For instance, ref. [95] documented entities, relationships, and attributes in EXPRESS-X to articulate georeferencing data. Alternatively, EXPRESS-G offers a graphical notation syntax for a visual representation of the extended entities and properties within the context of the existing standard schema. Ref. [96] introduced the necessary entities for the product representation of river facilities and exclusively outlined the conceptual relationships between entities using EXPRESS-G. Although both approaches represent the extensions in legitimate formats, they differ in their depth and detail: EXPRESS-X cases not only presented the conceptual framework but also depicted the structural mapping of properties associated with entities. EXPRESS-G cases were slightly more abstract, focusing only on defining semantic mappings between models, foregoing a deeper structural representation.

5.4.2. Analysis of Validation Approaches

The validation approaches used by the mentioned studies had varying degrees in their approaches to verify their extensions. The first and basic approach, termed ‘representation-centric’, was used to demonstrate the interoperability of the extensions. That is, these studies implemented the extensions in a BIM modeling tool and, after export, showed that the entities and properties were correctly manifested in the receiving BIM application. The second approach, termed ‘utility-centric’, went one step further by demonstrating that the imported entities and properties could be used properly in the receiving application to conduct relevant analyses. This latter approach was deemed a more exhaustive validation as it also demonstrated the utility and purpose of their extensions. Other studies did not provide a validation of their extensions and were classified as ‘not implemented’.

Table 6. Validation approaches by extension purposes.

Validation Approaches	Extension Approach		Total
	Entity + Property Extension	Property Extension
Representation centric	25	2	27
Utility centric	13	7	20
Not implemented	17	-	17
Total	55	9	64

presents the corpus of cases classified in accordance with these validation approaches and also further categorized based on the aforementioned extension approaches, i.e., entity and property versus property extensions. The table shows that for entity and property extension cases, ‘representation-centric’ approaches outnumber those of ‘utility-centric’ validations. As these cases focused on defining novel products currently absent in the IFC schema, they focused on demonstrating that the new extensions could be correctly exported and represented in receiving BIM applications. For instance, ref. [64] introduced new entities to represent detailed parts of a tunnel boring machine and then verified that these entities and related properties were correctly displayed in open IFC tools, an open source IFC viewer.

In contrast, cases limited to property extensions adopted more ‘utility-centric’ approaches for their validations. As noted in Section 5.3.1, these cases involved defining properties to enable process representations, including inspections, operation and maintenance procedures, or engineering and management analyses. Thus, these studies demonstrated the use and results of the specific properties exported to the receiving applications. For example, ref. [52], who extended processes pertaining to code compliance, demonstrated that actual code compliance checking became possible once the extensions were realized in ArchiCAD, a BIM authoring tool.

6. Discussion

6.1. Summary of the Results and Suggestions for Future Work

From 2001 to 2022, numerous cases advocated for extending the IFC schema, with a marked increase observed from 2013 onwards. This surge can be largely attributed to the introduction of base entities for the infrastructure domain in version 4.0 of the IFC schema. The following sections describe the main findings from this review, in relation to the research questions posed in Section 2.

6.1.1. Main IFC Extension Areas Developed and Extension Approaches Used

Within the architecture domain, the main focus was on process representations, employing ‘entity and property extension’ techniques to represent essential concepts and processes for data management and analysis in areas such as structural analysis and module design. While there was some emphasis on product representations, especially in integrating emerging technologies, the primary emphasis remained on processes, given that comprehensive building element definitions were already defined in earlier IFC schema versions.

In contrast, the infrastructure domain extensively employed ‘entity and property extension’ methods for both product and process representations. Product-focused efforts sought to define elements absent from the standard schema, while process representations were geared towards concepts crucial for alignment representation and asset management. Interestingly, the following sectoral differences were evident: the bridge sector leaned towards process representation, whereas the tunnel sector prioritized product representation, underlining the distinct structural and component disparities between the two.

6.1.2. Trends Identified through Timeline Analyses

A subsequent timeline analysis revealed changing trends within each domain over the discussed period. The architectural domain, which initially emphasized process representations, showed increases in product representations around 2018, with a significant spike in 2022. This shift aligns with recent endeavors to incorporate insights from innovative technologies and building systems into the IFC schema, building upon the pre-established definitions of the initial IFC schema. Conversely, the infrastructure domain transitioned from an initial focus on product representations to a rising interest in process representations from 2019 onwards. Version 4.0 of the IFC schema seems to have played a pivotal role in this transition.

6.1.3. Main Approaches Used for IFC Extensions and Validation

Implementation approaches for translating the extended IFC schema to an IPF varied based on the extension’s intent. Entity extension cases typically utilized STEP toolkits, while property extensions directly used BIM authoring tools. Other cases showcased extension ideas without an actual IPF implementation, representing these ideas in textual form through EXPRESS-X, or visually via EXPRESS-G.

For entity and property extension cases, validation was primarily performed through demonstrations of interoperability between export and import applications. In contrast, property extension cases targeting process representations not only verified their interoperability but also needed their extensions by demonstrating their utility in receiving applications.

6.1.4. Research Gaps, Implications, and Future Steps

Although a significant number of studies have addressed the needs of the industry, there are still many gaps in each domain that are not properly represented. The infrastructure domain provides a poignant example. As shown in Table 3, most developments were biased towards bridges and tunnels. Even within these sectors, only subsectors (e.g., drainage, a subsidiary facility for bridges [68,69,70,71,72,73]) have been partially modeled. Other sectors, such as dams and harbors, have even more limited representations (e.g., 3D tiles and quay walls [18,92]). This is also true for processes, where the extensions created for project management and construction methods are only applicable to specific subsectors. This is because the studies have been developed separately in an ad hoc and haphazard fashion. Thus, future developments need to be organized more systematically for IFCs to be accepted and used across the full AEC spectrum.

Specifically, we recommend the following directions for future works:

In the architectural domain, given the extensive entity definitions already in place for products, the primary emphasis should remain on process representations. However, as new technologies and advanced building systems emerge, related products and their processes will also need to be represented into the schema. Such needs should see an increasing shift towards ‘entity and property extensions’. Furthermore, the extension for these new technologies would need to be validated more rigorously using ‘utility-centric’ validation approaches to justify their inclusion in future schemas upgrades.

For the infrastructure domain, additional product representations are required for less addressed sectors, such as dams, harbors, plants, river facilities, etc. More importantly, a systematic and holistic approach needs to be employed, preferably by bSI’s technical committee to develop a long-term strategy and roadmap to fill in the gaps of this domain. Moreover, processes related to design, project management, and inspection should also be developed for general use throughout the entire domain and independent of specific sectors as much as possible.

6.2. Future Initiatives for the IFC

The review of the extension cases in this study showed various solutions in which limitations of the IFC schema were improved to meet the interoperability needs of the AEC industry using extension approaches outlined in Section 4.2. Despite these efforts, recent studies have highlighted more innate and fundamental limitations of the schema that may not be resolved via extensions alone.

For example, ref. [97] pinpointed key limitations in the current IFC standard schema, notably its reliance on the EXPRESS modeling language. This limited the IFC’s adaptability to newer use cases and technologies, especially those requiring partial BIM data updates, significant data filtering, quick exchanges, and AI or machine learning applications. In response, the IFC 5 initiative emerged, aiming to modernize the IFC standard schema. Distinct from its predecessors, IFC 5 emphasizes modularity, normalization, and language independence (Figure 10). It aims for a broader compatibility and flexibility in representations. Another concern was that the existing IFC standards, rooted in EXPRESS and SPF, are not easily modeled with modern frameworks such as UML, XML, or JSON. IFC 5 aims to enhance compatibility with these frameworks, simplifying IFC integration with contemporary systems.

Ref. [98] addressed interoperability issues that cannot be resolved using IFCs alone. The authors focused on issues particular to multi-domain collaborations, specifically the semantic disconnect existing between architecture–structure–MEP domains during BIM modeling processes. As a solution, they introduced cloud-based BIM (CBIM), which employs converting BIM models into RDF graphs and unifying them into a single, integrated ontology. Within CBIM, the BIM model functions as a cloud object, establishing inter-domain connections, and allowing seamless synchronization of changes between the models. The authors also developed inter-domain constraint classes to represent cross-disciplinary ties and a clash detection mechanism to ensure consistency. A prototype implementation of CBIM, illustrated using a hospital building case study, successfully detected and addressed clashes, ensuring consistency across multiple domains.

These studies propose more fundamental changes to IFC schema development and provide insights into the future initiatives required going forward.

7. Conclusions

This study performed a comprehensive review of preceding IFC schema extension cases within the AEC/FM literature, with the objective of pinpointing research gaps and informing future enhancements in schema extension strategies. Prior to this review, the architecture and implementation methods of the IFC schema were examined, which revealed its inherent limitations. A total of 64 publications conducted over the recent two decades were collected and classified with the goals of identifying the trends with respect to the domains and sectors addressed, their purpose in terms of products and processes, the methods used for extensions, and their implementation and validation approaches.

In both the architecture and infrastructure domains, most cases involved creating extensions to represent new processes, although product representation was initially predominant for the infrastructure domain. Defining properties served as the main extension method, with entity extension frequently being utilized concurrently in product-oriented cases. Trend-wise, the architecture domain was initially centered on process representations and later transitioned to product representations, which stemmed from recent efforts to include new technological advancements and building systems into the schema. Comparatively, the infrastructure domain initially included cases focusing on product representations and later transitioned to processes. The initial efforts seem to have catalyzed the inclusion of entities and properties exclusively for infrastructure products, especially in the latter versions of the IFC. These advancements, in turn, were followed by extensions for defining concepts and processes specific to select sectors in the domain.

The approaches for implementing the extensions varied depending on the extensions’ purpose and correspondingly utilizing either STEP or BIM authoring tools. Many cases were limited to documenting their extension designs using EXPRESS-X or EXPRESS-G without the implementation of actual software. Validation methods differed depending on the extension approach used, as follows: entity and property extension cases were limited to demonstrating interoperability, while property extensions went a step further by demonstrating the utility of the extensions post-export into other software applications.

Based on these findings, strategies for future extensions were outlined. In the architectural domain, a sustained focus on process representation is recommended, in line with the growing trend of adopting ‘entity and property extensions’ to incorporate emerging technologies and advanced building systems. Moreover, these extensions should be subjected to rigorous ‘utility-centric’ validation processes to validate their incorporation in forthcoming schema updates. For the infrastructure domain, it is suggested to shift focus towards underrepresented sectors, such as dams and airport facilities, which require specific definitions within the schema. Conversely, for well-established sectors, such as bridges and tunnels, it is recommended to enhance process representations, drawing insights from the historical developments in the architectural field.

This study concentrated on structuring and classifying IFC schema extension cases to derive insights and trends from which future directions in this research area could be derived. Thus, in addition to the findings, the methodology also provides a template for conducting similar analyses and formulating strategies for future works in IFC schema extensions. Together with the initiatives for modernizing the IFC, the findings are hoped to expedite the development of BIM-based collaboration frameworks in the AEC/FM industry.