An Industry Foundation Classes (IFC) Schema Extension for Building Information Modelling (BIM)-Based Description of Building Integrated PV

Abstract

Integrating Building-integrated Photovoltaics (BIPV) in nearly zero-energy buildings (nZEB) has gained importance due to its dual role as a renewable energy generator and building material. However, adoption is hindered by the lack of digital product data representation in Building Information Modelling (BIM). This study aims to establish a structured approach for representing BIPV products within the Industry Foundation Classes (IFC) schema to facilitate efficient information exchange. A systematic comparison of existing BIPV representation methods in BIM was conducted. The study then developed new BIPV property sets and classification options within the IFC schema. A validation process assessed the feasibility of the proposed classification and properties. The study identified key gaps in the digital representation of BIPV within the current IFC 4.3 schema and proposed a refined classification framework. The newly defined property sets and categorisation enhance interoperability, ensuring accurate data exchange across BIM platforms. The findings support the seamless integration of BIPV in digital building workflows. This research advances the digitalisation of BIPV products by addressing gaps in BIM compatibility. The proposed BIDM framework provides a structured method for representing BIPV in IFC, contributing to standardisation efforts and promoting wider adoption of BIPV in the construction sector.

1. Introduction

The pursuit of energy efficiency and greenhouse gas emissions reduction in the building sector has increased the importance of Building-integrated Photovoltaics (BIPV) as a key technology for achieving nearly Zero Energy Buildings (nZEB) [1]. BIPV systems integrate photovoltaic (PV) technology directly into the building envelope, serving simultaneously as an energy-generating technology and a construction component. According to [2], “a BIPV module is a PV module and a construction product together, designed to be a building component.” By fulfilling both functions, BIPV can reduce the need for conventional building materials while generating renewable electricity. Despite increasing technological maturity and market potential, BIPV remains a relatively niche segment of the global PV market. A recent review reported that BIPV accounts for less than 1% of installed PV power globally, although Switzerland represents a notable exception where BIPV has achieved a substantially higher market share [3,4]. A recent IEA PVPS analysis across seven countries, including Australia, similarly indicates that BIPV markets remain niche, with integrated roof systems currently the leading application in most countries, while applications such as curtain walls and windows remain largely at the demonstration stage in Australia [5]. These studies identify limited collaboration between the PV and construction sectors, insufficient technical knowledge, and the lack of recognition of BIPV as a standard construction product as important barriers to wider adoption. One of the barriers to wider BIPV deployment is the limited digitalisation of BIPV products, particularly the lack of structured product data representations and digital product models that can be readily integrated with Building Information Modelling (BIM) platforms [6].

The need for comprehensive digital representations is further reinforced by the lifecycle challenges associated with BIPV systems. Recent research has highlighted that climate conditions and environmental exposure can influence BIPV degradation, reliability, and long-term performance. Nur-E-Alam, et al. [7] investigated climate-driven degradation and lifecycle reliability of BIPV systems, identifying key integration and deployment challenges affecting their long-term operation. These findings indicate that BIPV information requirements extend beyond geometric and product characteristics at the design stage to encompass lifecycle performance, degradation, reliability, maintenance, and operational information. However, existing BIM- and IFC-based approaches have predominantly focused on geometric representation and design-stage information interoperability, with comparatively limited consideration of these lifecycle requirements. Consequently, there is a need for more comprehensive digital representations that can accommodate BIPV-specific information throughout the asset lifecycle and provide a foundation for lifecycle information management, maintenance planning, and long-term digital asset management.

Building Information Modelling (BIM) has become increasingly important in the architecture, engineering, construction, and operation (AECO) industry by facilitating structured information management and exchange across project stakeholders. Within BIM workflows, the Industry Foundation Classes (IFC) standard provides an open and vendor-neutral data schema for exchanging information between different BIM applications [8]. IFC, therefore, plays an important role in enabling interoperability among stakeholders using different software platforms. However, because the IFC schema encompasses a broad range of asset types and industry domains, including buildings, infrastructure, and industrial facilities, its complete schema is not necessarily implemented within individual software applications. Instead, Model View Definitions (MVDs) are typically developed to identify and implement the subset of IFC entities and relationships required for a particular use case or workflow [8].

Despite its role as an open standard for BIM information exchange, the current IFC 4.3 schema provides limited support for the comprehensive representation of BIPV products and their associated information. In particular, the representation of BIPV-specific product characteristics and lifecycle-related information remains insufficiently developed. This creates challenges in consistently classifying BIPV products and exchanging their relevant properties across BIM platforms. Enhancing the digital representation of BIPV within IFC is therefore important for improving interoperability and supporting the broader digitalisation of BIPV systems.

Accordingly, this study investigates existing approaches for representing BIPV products within BIM and IFC environments, critically compares their capabilities and limitations, and identifies the information requirements necessary for more comprehensive BIPV representation. Based on this analysis, new property sets and appropriate classification options are proposed for representing BIPV products within the IFC schema. The proposed representation is subsequently validated to assess the suitability and functionality of the identified classifications and properties within an IFC-based workflow. Through this approach, the study aims to improve BIPV information interoperability and establish a foundation for extending BIPV digital product representations to support more comprehensive lifecycle information management.

2. Literature Review on IFC Scheme Extension

The IFC schema has been progressively extended to address information requirements not adequately covered by the standard schema, particularly in specialised domains, emerging technologies, and project-specific applications. A systematic review by Yu, et al. [9] shows that IFC extension research can be broadly categorised as introducing new entities, reusing existing entities through proxy mechanisms, or extending existing entities by adding properties and property sets. These approaches offer varying levels of semantic richness and implementation flexibility, but they also entail trade-offs among representational detail, interoperability, compatibility with existing IFC implementations, and the likelihood of adoption in future IFC releases. For BIPV, these trade-offs are particularly important because BIPV products combine characteristics of photovoltaic systems and building components and therefore require both building-related and PV-specific information. This review explores methodologies for extending the IFC schema to represent BIPV in BIM systems. It evaluates existing extensions for infrastructure and emerging materials, focusing on three approaches: creating new entities, using proxy elements, or defining property sets.

Creation of new entities or types: Creating new entities or types within the IFC schema provides the highest level of semantic specificity, as a specialised component can be explicitly defined within the IFC object hierarchy. This approach is particularly appropriate when an emerging domain contains objects whose characteristics and relationships cannot be adequately represented by existing IFC entities. However, custom entities also introduce greater complexity because authoring and viewing applications must recognise the extended schema to preserve the additional semantic information. Yu, et al. [9] reported that schema extensions involving new entities have been widely used to address specialised domains, but noted that extensions developed outside the official IFC schema may have limited interoperability unless they are incorporated into standardised implementations. Recent IFC extension research similarly identifies the trade-off between the detailed representation enabled by new entities and their compatibility with existing BIM software such as Autodesk Revit or ArchiCAD [10,11,12].

Utilisation of proxy elements: A less intrusive approach is to represent specialised components using existing generic IFC entities, particularly IfcBuildingElementProxy. The IFC specification defines this entity as a mechanism for representing building elements for which it does not provide a specific semantic definition. This makes proxy elements useful for emerging or specialised products that are not yet explicitly represented within the standard schema [10].

Definition of property sets: Property-set extension provides an alternative approach that retains the existing IFC entity structure while adding domain-specific information through IfcPropertySet and related mechanisms. This approach is particularly suitable when the existing IFC hierarchy can adequately represent the physical nature of an object but lacks the attributes required for a particular application [13].

Table 1 summarises approaches from previous studies across domains and highlights their rationale. Many studies extend the IFC schema by adding new entities to address specific needs, such as IfcRoad, which introduces road-related entities and properties that are absent from the current schema. There are some ongoing studies that propose new entities for future IFC implementation: Söbke, et al. [14] proposed IfcWWTPStructure, specifically designed for BIM-based planning of wastewater treatment plants. Pu, et al. [11] extended IFC for multi-component subgrade modelling in a railway station. They created a new entity as IfcRailwaySubgradeElement under the standard’s IfcCivilElement and a new entity of IfcSubgrade under IfcSpatialStructureElement. Further, they use the IfcRelAggregates relationship to connect different components, such as IfcSubgradeCrossSection, IfcSubgradeComponent, IfcSubgradeFillerSection, and IfcSubgradeFillerLayer, of the subgrade. Theiler and Smarsly [15] explored the IFC schema extension for modelling structural health monitoring systems (SHMS). They created a new entity, IfcSensorNode, under IfcDistributionControlElement and a new entity, IfcSHMSystem, under IfcSystem. Zhiliang, et al. [10] investigated the extension of IFC for construction cost estimating in China. However, in contrast to previous studies, they did not create new entities; instead, they created new property sets to satisfy the requirements of cost estimating in accordance with Chinese standards.

IFC extensions have also been applied to emerging building materials, such as prefabricated building materials and BIPV products. To enable the determination of energy consumption data of prefabricated components in the manufacturing stage, Xu, et al. [16] chose to extend the IFC schema by defining new property sets and properties, as the entities required for representing the components already existed, but use-case relevant properties were not yet defined in the standard. Xu et al. [13] published another IFC extension proposal for product quality information of prefabricated components to better store the obtained quality information of prefabricated components. This extension was again based on property sets, as adding new properties for entities already defined in the standard was only necessary. Further, Xu, et al. [17] added a prefabricated building entity (IfcPrefabricatedBuilding) to achieve a simplified assembly model to support the design of prefabricated buildings, which focused on IFC extensions for the new entities, attributes, and association relations of assembly models.

Few studies have focused on BIPV products, which are regarded in this study as prefabricated building products with both structural and electrical properties. It is necessary to manage these intersectional characteristics of BIPV products and classify BIPV in a suitable domain under the IFC schema. Franz, et al. [18] proposed adding IfcActiveBuildingElement under IfcElement for BIPV and solar collector products, but did not detail BIPV classifications. Given BIPV’s dual building and electrical properties, careful classification in the IFC schema is crucial. Challenges in integrating new entities into the official IFC standard often make proxy elements or property sets more viable. The approach depends on project needs, balancing standardisation, customisation, and domain-specific requirements [14].

Table 1. Comparison of different IFC extension types.

Literature	Application Area	Defining New Entities or Types	Using Proxy Elements	Using the Property Sets or Types	Reasoning
IFC 4.3.1 [19]	IfcRoad	X		X	IFC standard lacks the required entity and corresponding properties.
IFC 4.3.1 [19]	IfcBridge	X		X	IFC standard lacks the required entity and corresponding properties.
IFC 4.3.1 [19]	IfcRailway	X		X	IFC standard lacks the required entity and corresponding properties.
Vilgertshofer, et al. [20]	IfcTunnel	X		X	IFC standard lacks the required entity and corresponding properties.
Söbke et al. (2021) [14]	IfcWWTPStructure	X		X	IFC standard lacks the required entity and corresponding properties.
Theiler and Smarsly [15] (2018)	IFC Monitor extension	X			IFC standard lacks the required entity, but required properties can use predefined property sets.
Zhiliang, et al. [10]	Construction cost estimating		X	X	IFC standard has required entities but needs proxy elements (temporary products) and property sets.
Pu, et al. [11]	Multi-component subgrade in a railway station	X			IFC standard lacks the required entity.
Xu, et al. [16]	Energy consumption			X	IFC standard has required entities but lacks required properties/property sets.
Xu et al. (2020) [13]	IfcPrefabricatedWall			X	IFC standard has a predefined entity but lacks required properties/property sets.
Xu, et al. [17]	IfcPrefabricatedBuilding	X		X	IFC standard lacks the required entity and corresponding properties.
Franz, et al. [18]	Create IfcActiveBuildingElement to cover IfcBIPV products	X			IFC standard lacks the required entity.

Table 1. Comparison of different IFC extension types.

Literature	Application Area	Defining New Entities or Types	Using Proxy Elements	Using the Property Sets or Types	Reasoning
IFC 4.3.1 [19]	IfcRoad	X		X	IFC standard lacks the required entity and corresponding properties.
IFC 4.3.1 [19]	IfcBridge	X		X	IFC standard lacks the required entity and corresponding properties.
IFC 4.3.1 [19]	IfcRailway	X		X	IFC standard lacks the required entity and corresponding properties.
Vilgertshofer, et al. [20]	IfcTunnel	X		X	IFC standard lacks the required entity and corresponding properties.
Söbke et al. (2021) [14]	IfcWWTPStructure	X		X	IFC standard lacks the required entity and corresponding properties.
Theiler and Smarsly [15] (2018)	IFC Monitor extension	X			IFC standard lacks the required entity, but required properties can use predefined property sets.
Zhiliang, et al. [10]	Construction cost estimating		X	X	IFC standard has required entities but needs proxy elements (temporary products) and property sets.
Pu, et al. [11]	Multi-component subgrade in a railway station	X			IFC standard lacks the required entity.
Xu, et al. [16]	Energy consumption			X	IFC standard has required entities but lacks required properties/property sets.
Xu et al. (2020) [13]	IfcPrefabricatedWall			X	IFC standard has a predefined entity but lacks required properties/property sets.
Xu, et al. [17]	IfcPrefabricatedBuilding	X		X	IFC standard lacks the required entity and corresponding properties.
Franz, et al. [18]	Create IfcActiveBuildingElement to cover IfcBIPV products	X			IFC standard lacks the required entity.

Research into IFC extensions shows efforts to adapt the schema to advancements in materials and construction techniques. Recent updates have improved infrastructure representation (e.g., roads, bridges, railways) but reveal a significant gap for BIPV products. As hybrid materials bridge construction and renewable energy, BIPV systems lack adequate representation, highlighting the need for targeted extensions to fully integrate them into BIM workflows ([17,18,21]). Developing new entities, using proxy elements, and defining property sets are key to integrating BIPV into the IFC schema. Accurate representation will be crucial for BIPV adoption as the industry embraces sustainable practices.

3. Research Methodology

This research adopted a literature review and semi-structured stakeholder interviews to identify BIPV product use cases, required product attributes, and requirements for developing a digital BIPV product model. The literature review used Web of Science, Google Scholar, and the RMIT Library as the primary search sources, focusing primarily on journal articles, conference papers, and industry reports from the past 10 years. Selected earlier studies were also included where they provided important foundational knowledge, particularly for the Australian context. Reports from IEA PVPS, BIPV Boost, and SUPSI were also reviewed to capture recent developments in BIPV practice.

To complement the literature findings, 27 stakeholders from 11 professional groups participated in semi-structured interviews. Participants were recruited through professional networks and LinkedIn using purposive sampling. A minimum of two years of relevant professional experience was required. In total, 27 stakeholders from 11 stakeholder groups participated, covering architecture, engineering, construction, development, facility management, and related fields. Two additional experts with specialist expertise in IFC/BIM and BIPV digitalisation were interviewed to validate the findings. Interviews were conducted online, lasted approximately 30 min, and followed a semi-structured interview guide. Participants discussed their professional responsibilities, building product information requirements, BIPV use cases, and additional information needed for BIPV products. Where participants had limited direct BIPV experience, BIPV was explained as a building product incorporating both building and photovoltaic/electrical characteristics. All interviews were audio-recorded with consent and transcribed manually. Thematic analysis following Braun and Clarke [22] was conducted using NVivo. Initial codes were developed around building-product information, BIPV-specific information, professional duties, software, procedures, and standards. These codes were reviewed and consolidated into themes representing BIPV use cases and information requirements. BIPV attributes were identified by combining requirements from the literature review and stakeholder interviews, followed by review and validation through the two expert interviews. The consolidated requirements were subsequently used to inform the attributes included in the proposed IFC representation.

To integrate BIPV product information into the IFC schema and enhance their BIM representation, a structured methodology was followed, consisting of five key steps:

• Identifying potential BIPV extensions: Exploring viable BIPV extension options within the IFC schema.
• Comparative analysis of property sets: Comparing existing property sets with BIPV attributes to determine the best extension option.
• In-depth BIPV extension analysis: Examining each extension option for alignment with IFC criteria.
• Development of new property sets: Creating additional property sets to fill gaps in BIPV representation.
• Validation of BIPV extension: Ensuring the extension adheres to IFC standards through rigorous validation.

This approach aims to develop a comprehensive BIPV schema extension for broader industry adoption.

4. A Comparative Analysis of BIPV Extension in the IFC Schema

4.1. Potential BIPV Extension Identification

Figure 1 illustrates the IFC structure for BIPV products within IFC 4.3. BIPV products can be classified as a building element (IfcBuiltElement) or an electrical product IfcDistributionElement). If considered a building product, BIPV is represented as IfcBuiltElement or an electrical product under IfcDistributionElement. Both are subtypes of IfcElement. IfcBuiltElement includes construction components, while IfcDistributionElement deals with distribution systems. BIPV systems could be modelled under IfcSolarDevice or IfcEnergyConversionDevice to highlight energy conversion.

Figure 1. IFC structure relevant to BIPV product extension [19].

This section offers eight classification options for BIPV integration:

New Entities Under IfcBuiltElement: Introduce BIPV-specific entities within IfcBuiltElement.

New Entities Under Specialised Building Classes: Create specialised BIPV classes (e.g., IfcBIPVCurtainWall under IfcCurtainWall).

New Entities Under IfcSolarDevice: Create entities under IfcSolarDevice for solar energy conversion.

New Entities Under IfcEnergyConversionDevice: Define BIPV entities under IfcEnergyConversionDevice for energy conversion.

High-Level New Entities Under IfcElement: Create broad entities within IfcElement to avoid limitations.

Proxy Elements for BIPV: Use IfcBuildingElementProxy for flexible representation.

New Property Sets for BIPV: Develop BIPV-specific property sets and relationships.

IfcRelAggregates for BIPV: Use IfcRelAggregates to describe BIPV as a composite of materials and components.

Figure 2 summarises the characteristics of each option, highlighting their potential for enhancing BIPV representation in BIM environments.

Figure 2. Key characteristics of BIPV classification in different options.

4.2. Comparative Analysis of Property Sets

Before delving into the specific details of each option, a comparative analysis of the existing property sets within each classification approach is conducted to assess both commonalities and variations across the options. This endeavour provides insights into the extent to which existing property sets are leveraged when introducing a new entity under each option. Notably, 21 property sets are shared across the options, necessitating the creation of a new entity. These shared property sets can be found under Ifc4.3 IfcBuiltElement. These property sets are universally inherited from IfcElement, thereby forming a common baseline for all options that mandate new entity creation. Table 2, Table 3, Table 4, Table 5, Table 6 and Table 7 list IFC 4.3 property and quantity sets relevant to BIPV, with essential BIPV attributes highlighted in bold. Non-essential but available properties are in regular fonts.

Table 2. Property sets and quantity sets under IfcWindow.

IfcWindow:
Pset_WindowCommon:
Reference Status AcousticRating FireRating Infiltration SecurityRating		ThermalTransmittance IsExternal GlazingAreaFraction HasSillExternal HasSillInternal HasDrive		WaterTightnessRating MechanicalLoadRating WindLoadRating SmokeStop FireExit
Qto_WindowBaseQuantities
Width Height			Area Perimeter
Pset_DoorWindowGlazingType
GlassLayers GlassThickness1 GlassThickness2 GlassThickness3 GlassColour VisibleLightReflectance VisibleLightTransmittance		SolarReflectance SolarTransmittance SolarHeatGainTransmittance ShadingCoefficient ThermalTransmittanceSummer ThermalTransmittanceWinter SolarAbsorption		IsLaminated IsCoated IsWired IsTempered FillGas

Table 3. Property sets and quantity sets under IfcCurtainWall.

IfcCurtainWall:

Pset_CurtainWallCommon: Reference                                                                                                                                                                             AcousticRating FireRating Status                                                                                                                                                                                       Combustible SurfaceSpreadOfFlame                 ThermalTransmittance                                                                                                     IsExternal

Qto_CurtainWallQuantities:

Length                                                                                 Height Width                                                                    GrossSideArea NetSideArea

Table 4. Property sets and quantity sets under IfcCovering.

IfcCovering:
Pset_CoveringCommon: Reference                                                                                                                                                                                                    Status AcousticRating FireRating                                                                                                                                                                                       Combustible SurfaceSpreadOfFlame ThermalTransmittance                                                                                                                                                                      IsExternal Finish FlammabilityRating                                                                           FragilityRating
Qto_CoveringBaseQuantities
Width Net area			Gross area
Pset_Tiling:
Permeability TileLength TileWidth Pset_CoveringFlooring HasNonSkidSurface HasAntiStaticSurface Pset_CoveringTypeMembrane NominalInstallationDepth NominalTransverselnclination

Table 5. Property sets and quantity sets under IfcRoof.

IfcRoof

Pset_RoofCommon

Reference                                                                                                                                                                        Status AcousticRating FireRating                                                                                                                                         ThermalTransmittance IsExternal LoadBearing

Qto_RoofBaseQuantities

GrossArea                                                                                                                                                                   NetArea ProjectedArea

Pset_ConcreteElementGeneral: AssemblyPlace                                                                                                                                                   CastingMethod StructuralClass StrengthClass                           ExposureClass                                                                       ReinforcementVolumeRatio ReinforcementAreaRatio                  DimensionalAccuracyClass                                 ConstructionToleranceClass ConcreteCoverAtMainBars               ConcreteCoverAtLinks                                         ReinforcementStrengthClass Pset_PrecastConcreteElementFabrcation        TypeDesignation                                             ProductionLotld SerialNumber                                                                                                                        PieceMark AsBuiltLocationNumber ActualProductionDate                                     ActualErectionDate Pset_PrecastConcreteElementGeneral: TypeDesignation                                                      CornerChamfer      ManufacturingToleranceClass FromStrippingStrength                                             LiftingStrength                                        ReleaseStrength MinimumAllowableSupportLength                        InitialTension                                                TendonRelaxation TransportationStrength               SupportDuringTransportDescription                   SupportDuringTransportDocReference HollowCorePlugging                                       CamberAtMidspan                                              BatterAtStart BatterAtEnd                                                                                                                          Twisting Shortening PieceMark                                                    DesignLocationNumber

Table 6. Property sets and quantity sets under IfcRailing.

IfcRailing

Pset_RailingCommon:

Reference                                                                                                                                                         Status Height Diameter                                                                                        IsExternal

Qto_RailingBaseQuantities

Length

Pset_ConcreteElementGeneral: AssemblyPlace                                                                                                                                 CastingMethod StructuralClass StrengthClass                                                                                                                                 ExposureClass ReinforcementVolumeRatio ReinforcementAreaRatio                        DimensionalAccuracyClass                             ConstructionToleranceClass ConcreteCoverAtMainBars                        ConcreteCoverAtLinks                             ReinforcementStrengthClass Pset_RoadGuardElement: IsMoveable                                                                                                                                                     Isterminal Is the transition TerminalType

Table 7. Property sets and quantity sets under IfcShadingDevice.

IfcShadingDevice

Pset_ShadingDeviceCommon: Reference                                                                                                         Status ShadingDeviceType MechanicalOperated                                                                             SolarTransmittance solar reflectance  ThermalTransmittance                                                                                        external VisibleLightTransmittance VisibleLightReflectance                            Roughness

Pset_ShadingDevicePHistory: TiltAngle                                                   Azimuth

Each applicable building element is associated with its specific core property set, such as Pset_CurtainWallCommon, Pset_WindowCommon, and Pset_CoveringCommon. These shared properties, integral to each relevant building element, generally play a vital role in describing BIPV products when applied to that element. Furthermore, individual applicable building elements have distinct methods for describing quantities, exemplified by Qto_CurtainWallQuantities and Qto_WindowBaseQuantities. Beyond the common properties, the Pset_DoorWindowGlazingType includes a range of attributes for describing BIPV products.

Table 8 summarises the property and quantity sets for IfcEnergyConversionDevice and IfcSolarDevice, including electrical domain properties such as RatedCurrent and RatedVoltage relevant to BIPV products. While most property sets overlap, IfcSolarDevice includes two additional sets: Pset_SolarDeviceCommon and Qto_SolarDeviceBaseQuantities. However, these sets lack key attributes for BIPV and traditional solar panels, such as module efficiency and short-circuit current. Thus, categorising BIPV under either entity offers limited differentiation in property set coverage.

Table 8. Property sets belonging to IfcEnergyConversionDevice and IfcSolarDevice.

IfcEnergyConversionDevice	IfcSolarDevice
Pset_ElectricalDeviceCommon	Pset_ElectricalDeviceCommon
RatedCurrent	RatedCurrent
RatedVoltage	RatedVoltage
NominalFrequencyRange	NominalFrequencyRange
PowerFactor	PowerFactor
ConductorFunction	ConductorFunction
NumberOfPoles	NumberOfPoles
HasProtectiveEarth	HasProtectiveEarth
InsulationStandardClass	InsulationStandardClass
IP_Code	IP_Code
IK_Code	IK_Code
EarthingStyle	EarthingStyle
heat dissipation	heat dissipation
Power	Power
NominalPowerConsumption	NominalPowerConsumption
NumberOfPowerSupplyPorts	NumberOfPowerSupplyPorts
Pset_ElectricalDeviceCompliance	Pset_ElectricalDeviceCompliance
ElectroMagneticStandardsCompliance	ElectroMagneticStandardsCompliance
ExplosiveAtmosphereStandardsCompliance	ExplosiveAtmosphereStandardsCompliance
FireProofingStandardsCompliance	FireProofingStandardsCompliance
LightningProtectionStandardsCompliance	LightningProtectionStandardsCompliance
Pset_ElementSize	Pset_ElementSize
NominalLength	NominalLength
NominalWidth	NominalWidth
NominalHeight	NominalHeight
Pset_EnergyRequirements	Pset_EnergyRequirements
EnergyConsumption	EnergyConsumption
PowerDemand	PowerDemand
EnergySourceLabel	EnergySourceLabel
EnergyConversionEfficiency	EnergyConversionEfficiency
Pset_EnvironmentalEmissions	Pset_EnvironmentalEmissions
CarbonDioxideEmissions	CarbonDioxideEmissions
SulphurDioxideEmissions	SulphurDioxideEmissions
NitrogenOxidesEmissions	NitrogenOxidesEmissions
ParticularMatterEmissions	ParticularMatterEmissions
NoiseEmissions	NoiseEmissions
Pset_MaintenanceStrategy	Pset_MaintenanceStrategy
AssetCriticality	AssetCriticality
AssetFrailty	AssetFrailty
AssetPriority	AssetPriority
MonitoringType	MonitoringType
AccidentResponse	AccidentResponse
Pset_SoundGeneration	Pset_SoundGeneration
SoundCurve	SoundCurve
	Pset_SolarDeviceTypeCommon
	Reference Status
	Qto_SolarDeviceBaseQuantities
	gross weight GrossArea

Most property sets (21) are shared by all proposed options for creating a new entity. Creating a new entity for each building element option provides properties similar to those in the electrical domain. However, IfcWindow offers more properties for describing BIPV product attributes. Some IFC properties (e.g., Reference and Status) are designed for the IFC context. A BIPV attribute, such as glass thickness, can be described by multiple IFC properties (e.g., GlassLayer, GlassThickness 1, GlassThickness 2, GlassThickness 3). Thus, we must transfer the BIPV attributes we collect to IFC context properties.

4.3. Detailed Analysis of Different BIPV Classification Options

Eight potential approaches for representing and classifying BIPV products within the IFC schema were identified and examined. The alternatives include creating new IFC entities, using proxy elements, extending existing entities with dedicated property sets, and using existing IFC relationships to represent BIPV components. Rather than quantitatively ranking the alternatives, this study adopts a structured qualitative assessment to examine their suitability against the research objectives.

Four evaluation criteria were established based on the research aim and the requirements identified from the existing IFC and BIPV literature [14]. These criteria were applied consistently to all eight classification options to provide a systematic basis for comparison:

Criterion 1—Applicability and comprehensive representation: The extent to which the approach can represent the building-integrated and photovoltaic characteristics of BIPV products and accommodate the required BIPV information.

Criterion 2—Practical adoption: The extent to which the approach can be implemented within existing IFC-based BIM workflows with limited modification, implementation effort, and disruption to existing industry practices.

Criterion 3—Maximisation of existing IFC resources: The extent to which the approach can reuse existing IFC entities, relationships, classifications, and property sets rather than introducing unnecessary schema modifications.

Criterion 4—Future adaptability: The extent to which the approach can accommodate emerging BIPV applications, technologies, properties, and evolving information requirements without requiring substantial restructuring of the IFC schema.

The criteria were subsequently used as a common analytical framework for examining each of the eight options. For each option, its underlying IFC structure, information representation capability, advantages, limitations, and implications for the four criteria were examined. This approach enables a consistent comparison of the alternatives while recognising that IFC schema design involves technical and semantic considerations that cannot always be meaningfully expressed through numerical scores or objective weighting.

4.3.1. Option 1: Define New Entities Under IfcBuiltElement

Option 1 is to create an entity of IfcBIPVElement under IfcBuiltElement (Figure 3). IfcBuiltElement is a subtype of IfcProduct or IfcTypeProduct; IfcBuiltElement comprises all elements primarily part of constructing a built facility. Typical examples of IfcBuiltElement include “built elements within a space separation system”, “built elements within an enclosure system (such as a façade)”, and “built elements within a fenestration system”. Under IfcBuiltElement, there are 30 types of entities [19]. The next step is categorising different BIPV application types as IfcBIPVElementTypeEnum under IfcBIPVElement. For example, users can choose the type of BIPV application, such as a rain-screen façade or double skin façade, under IfcBIPVElementTypeEnum. This approach makes minimal changes to the current IFC schema by adding only one new entity under IfcBuiltElement, simplifying the IFC extension compared to adding new entities under multiple building elements.

Figure 3. EXPRESS-G diagram for BIPV classification in IFC representation Option 1.

However, IfcBIPVElement can only inherit properties from its superclass, IfcBuiltElement, lacking properties specific to certain building elements like IfcCurtainWall, which are relevant to curtain wall BIPV products. This means it only inherits general building properties (e.g., Pset_Warranty, Pset_EnvironmentCondition) and not properties from elements like IfcCurtainWall or IfcWindow. For example, IfcCurtainWall’s property set Pset_CurtainWallCommon includes BIPV-relevant properties such as AcousticRating and FireRating, which would not be available to IfcBIPVElement in this option [17]. Property sets covering these properties must be included to meet building design requirements. A viable solution is to assign these specific existing property sets from the respective building elements to the newly introduced IfcBIPVElement. Regarding criteria evaluation, Option 1 partially meets Criterion 1 (applicability and comprehensive representation) by creating a new entity, but it requires more property sets for different building elements and solar devices. It excels in Criterion 2 (practical adaptation) by making just one entity within the existing IFC framework. However, it falls short in inheriting properties from specific building elements, missing a comprehensive solution. For Criterion 3 (maximising utilisation of existing IFC resources), this option performs poorly due to the absence of properties from specific building elements. However, it excels in Criterion 4 (future adaptability), as new Enums can be easily added to cover new types of BIPV applications. Maintenance is simple, as this option only adds one entity to the existing IFC schema.

4.3.2. Option 2: Create an Entity as “IfcBIPVxxxx” Under Each Applicable Building Element

As a second option, we can match BIPV application types to the corresponding IfcBuiltElement entities to categorise BIPV products by the building element they are applied to. Figure 4 shows the classification of new BIPV entities under different IfcBuiltElement categories. Each new entity is named IfcBIPV “builtelement”, where “builtelement” indicates the application type. We examine the definitions of each IfcBuiltElement entity to select the most suitable one. Figure 5 shows an EXPRESS-G diagram of the BIPV classification under different building elements. This option requires creating six new entities to cover various BIPV application types, with potential future extensions for new BIPV technologies. It meets Criteria 1 and 3 but falls short on Criteria 2 and 4. Criterion 2 highlights practical challenges in creating six new entities for each building element, such as time, resources, and industry acceptance. The lack of consensus on BIPV application types may lead to regional disagreements, complicating the development of global standards. Criterion 4 raises concerns about the evolving nature of BIPV applications, with new types (e.g., BIPV doors) requiring further extensions to the classification to account for future developments.

Figure 4. Match BIPV application type with IfcBuiltElement.

Figure 5. EXPRESS-G diagram for BIPV classification in IFC schema Option 2, Source: Authors’ own work.

4.3.3. Option 3: Defining a New BIPV Entity Under IfcSolarDevice

The third option is to define a new BIPV entity under IfcSolarDevice that represents devices converting solar radiation into energy. Since BIPV products generate electricity from the sun, we can create “IfcBIPVSolarDevice” under IfcSolarDevice. This class includes photovoltaic panels, solar water heaters, and solar air heating systems. BIPV panels can inherit properties such as Pset_ElectricalDeviceCommon from IfcSolarDevice. The advantage of this option is that it requires minimal changes to the current IFC schema: adding one BIPV entity under IfcSolarDevice and inheriting PV panel properties, as shown in Figure 6. However, it limits the building-component characteristics of BIPV products and lacks building-property characteristics. Classifying BIPV products under IfcSolarDevice requires adding building-related and missing electrical properties, as the current IFC schema lacks a comprehensive set of electrical properties for PV panels. This classification meets Criteria 1, 2, and 4. Adding one new entity to the IFC schema is easier for the industry to implement and adapt to, offering future adaptability. However, BIPV products have more building properties than electrical ones, as they are building components. Classifying BIPV under IfcSolarDevice loses its semantic value, limiting the distinction between different building-element applications, such as BIPV curtain walls and roofs.

Figure 6. EXPRESS-G diagram for BIPV classification in IFC Option 3.

4.3.4. Option 4: Defining a New BIPV Entity Under IfcEnergyConversionDevice

IfcEnergyConversionDevice represents energy-conversion or heat-transfer devices in a flow distribution system. It includes subclasses like IfcSolarDevice, IfcHeatExchanger, and IfcEvaporator. Creating a BIPV entity under IfcEnergyConversionDevice allows IfcBIPVDevice to inherit properties from IfcEnergyConversionDevice. The EXPRESS-G diagram is shown in Figure 7. The property sets under IfcSolarDevice are like those under IfcEnergyConversionDevice, with IfcSolarDevice adding Pset_SolarDeviceTypeCommon and Qto_SolarDeviceBaseQuantities. Adding these to the IFC schema would make it advantageous to classify BIPV under IfcSolarDevice for representing BIPV products. However, defining a new BIPV entity under IfcEnergyConversionDevice has its benefits. The more general IfcEnergyConversionDevice allows BIPV products to incorporate future advancements in energy conversion, ensuring long-term adaptability within the IFC schema. Classifying BIPV under IfcEnergyConversionDevice performs similarly to IfcSolarDevice in criteria evaluation but excels in Criteria 1 (practical adoption) and 4 (future adaptability). This distinction separates BIPV products from traditional IfcSolarDevice categories, enhancing practical adoption and future adaptability.

Figure 7. EXPRESS-G diagram for BIPV classification in IFC schema Option 4.

4.3.5. Option 5: Defining New Entities Under IfcElement

To accommodate BIPV products with both electrical and building properties, Option 5 is to create a new entity specifically for them, such as introducing a category called IfcActiveBuildingElement under the IfcElement domain, as shown in Figure 8, as proposed by Franz, et al. [18]. This approach allows for including BIPV products and building-integrated solar thermal and thermal hybrid solar collectors within a single entity class.

Figure 8. EXPRESS-G diagram for BIPV classification in IFC Option 5.

A high-level entity may not align well with the IFC schema’s structure and semantics, leading to inconsistencies and adoption challenges. A better approach is to adapt existing IFC properties and structures, making minor adjustments for BIPV integration to ensure smoother compatibility. Regarding criteria evaluation, this option does not perform as well as previous approaches in practical adoption, utilising existing IFC resources, and future adaptability. Introducing a new entity, such as IfcActiveBuildingElement, could overlap with or conflict with existing entities within the IfcElement hierarchy. The primary issue might be the inability to store a required BIPV attribute, leading to incorrect modelling and the need to delete and recreate the element as an IfcActiveBuildingElement.

4.3.6. Option 6: Using Proxy Elements for BIPV Products

The IfcBuildingElementProxy is a versatile entity within the IFC schema that offers the same functionality as subtypes of IfcBuildingElement, still, without a predefined semantic meaning for the specific type of building element it represents [19]. One of its applications is representing voids, in which a requested volume of space may be accepted or rejected. If accepted, it can be transformed into a void within a building element, such as a wall opening or slab opening, and exchanged as an IfcBuildingElementProxy with the PredefinedType = ProvisionForVoid. The IfcBuildingElementProxy is also utilised to exchange special building elements not covered by the current specification or when participating software applications cannot provide a semantic definition [19]. This option is a temporary solution until buildingSmart creates a proper BIPV entity. Currently, BIM platforms default to categorising user-created elements under IfcBuildingElementProxy. However, IfcBuildingElementProxy is unsuitable in the long term, as BIPV products require a dedicated entity to reflect their specific semantics and properties.

4.3.7. Option 7: Creating New Property Sets for BIPV Products and Utilise with Suitable IfcRelationship Under Relevant Entities

The current IFC property sets cannot fully capture BIPV attributes. Creating dedicated BIPV property sets allows stakeholders to assign them to building or electrical entities without introducing new entities. While this offers flexibility, it may lead to inconsistencies in information exchange due to differing categorisations. Adapting the IFC schema to include new BIPV property sets enhances data exchange and future-proofing, but it also presents challenges. It risks non-standardised information exchange and interoperability issues if classifications vary across organisations or software. Standardisation is crucial for uniformity. Compatibility concerns may arise as the IFC schema evolves, requiring updates for seamless integration. Custom property sets demand ongoing maintenance to align with industry standards, regulations, and technological advancements, necessitating proper governance to ensure relevance and longevity.

Regarding criteria evaluation, creating property sets without adding new entities is a clear advantage in Criteria 2 and 3: practical adaptations among all options. This option allows for a shorter implementation period and can be seamlessly integrated using officially designed methods such as the BuildingSMART Data Dictionary (bSDD). By leveraging existing property sets and standardised data definitions, this approach minimises the need for extensive modifications to the IFC schema while ensuring compatibility and ease of adoption. This option lacks future adaptability, as inconsistent BIPV classification may cause data inconsistencies and interoperability issues. Evolving IFC schema updates could impact custom property compatibility, requiring adjustments for seamless exchange.

4.3.8. Option 8: Using IfcRelAggregates to Describe BIPV Products

IfcRelAggregates is a special type of the general composition/decomposition (or whole/part) relationship IfcRelDecomposes. The aggregation relationship applies to all subtypes of IfcObjectDefinition. For example, a roof aggregates roof elements such as roof slabs, rafters, and purlins. Theiler and Smarsly [15] used IfcRelAggregates to decompose object entities into “smaller” components: In their research, every sensor node can be decomposed into several elements, such as sensors and actuators, which are entities derived from the IfcProduct entity.

“A BIPV module is the smallest (electrically and mechanically) non-divisible photo-voltaic unit in a BIPV system that retains building-related functionality. If the BIPV module is dismounted, it must be replaced by an appropriate construction product.” [2]. A BIPV module is a building element that incorporates solar panels and related accessories. For example, if a BIPV module is applied to a roof element, it can be represented as shown in Figure 9. This representation method has several advantages, including the ability to display the components of the BIPV module without creating new entities. The BIPV product can also inherit property sets from building elements, solar devices, junction boxes, and cable components.

Figure 9. BIPV representation with IfcRelAggregates.

However, this approach also has its limitations. The representation of BIPV products in IFC is not explicit, as the composition of several components indicates a BIPV product without semantically linking them into a single one. For instance, it might be challenging to distinguish a BIPV roof from a roof with a mounted solar panel.

This method effectively utilises existing IFC resources by inheriting properties and distinguishing BIPV components via IfcRelAggregates. However, it lacks comprehensive representation and adaptability, as BIPV is modelled through multiple IFC elements rather than a distinct entity. It is worth noting that the IfcRelAggregates option can be made more useful by adding BIPV semantics through various means, such as using an IfcClassificationReference or adding an indicator as a note. However, stakeholders may use different names, leading to inconsistencies in information exchange.

4.4. Proposed New Property Sets in the Current IFC Schema

This research included a literature review and interviews with 29 stakeholders involved in BIPV design, supply, and adoption. The study aimed to gather essential BIPV product attributes for design and lifecycle management, identifying 115 attributes crucial for building system design. These attributes form the basis for developing an enhanced IFC schema to comprehensively and functionally represent BIPV systems within BIM processes. After comparing properties in the current IFC schema, we found that it lacks several properties needed to fully describe BIPV products. Therefore, new property sets must be created regardless of the classification option chosen. The current IFC 4.3 standard offers many building-related properties but lacks electrical and safety-related properties for conventional solar panels. Since BIPV products are a type of solar panel, the proposed new property aims to cover these missing properties for both traditional solar panels and BIPV products, regardless of their classification in the IFC schema. Table 9 lists the four proposed new property sets relevant to BIPV products.

Table 9. Proposed property sets to describe conventional solar devices and BIPV products.

Definition of the New Property Sets for BIPV Products
Property Set Names	Application Entities	Description
Npset_SolarDeviceElectricalCommon	IfcSolarDevice	Property set to store the electrical properties of solar devices
Npset_SolarDeviceSafety	IfcSolarDevice	Property set to store the safety-related properties of solar devices
Npset_ConstructionCertificate	IfcBuiltElement	Property set to store the construction certificate for BIPV products
Npset_BIPVCommon	IfcBIPVElement	Property set to store the typical BIPV properties which are not included under IfcSolarDevices

A new property set, Npset_SolarDeviceElectricalCommon, is proposed to address missing electrical properties for both solar panels and BIPV products, as shown in Table 10. It is recommended that it be added under IfcSolarDevice. Additionally, Npset_SolarDeviceSafety is proposed to store essential safety-related properties, as shown in Table 11, for both conventional solar panels and BIPV products. It is also recommended that this property set be added under IfcSolarDevice.

Table 10. Properties under Npset_SolarDeviceElectricalCommon.

Definition of Npset_SolarDeviceElectricalCommon
Name	Property Type	Data Type	Description
MaximumOverCurrentRating	IfcPropertySingleValue	IfcElectricCurrentMeasure	The maximum current that a device or circuit can handle without damage or failure
MaximumReverseCurrent	IfcPropertySingleValue	IfcElectricCurrentMeasure	The highest amount of current that can flow in the reverse direction through a photovoltaic (PV) cell or module
MaximumPowerVoltage	IfcPropertySingleValue	IfcElectricVoltageMeasure	The optimal operating voltage at which a solar panel generates its maximum power output
ModuleEfficiency	IfcPropertySingleValue	IfcPositiveRatioMeasure	The ratio of the electrical power output of a photovoltaic module to the power of the sunlight that strikes the module
NominalOperatingCellTemperature	IfcPropertySingleValue	IfcThermodynamicTemperatureMeasure	The temperature at which a solar cell is designed to operate under standard test conditions
OpenCircuitVoltage	IfcPropertySingleValue	IfcElectricVoltageMeasure	The voltage across the terminals of a photovoltaic cell or module when it is not connected to any external load
OperatingModuleTemperature	IfcPropertyBoundedValue	IfcThermodynamicTemperatureMeasure	The temperature of a photovoltaic module during operation
PowerTolerance	IfcPropertyBoundedValue	IfcRatioMeasure	The allowable deviation of the electrical power output of a photovoltaic module from its rated power output
ShortCircuitCurrent	IfcPropertySingleValue	IfcElectricCurrentMeasure	The current that flows through a photovoltaic cell or module when it is short circuited
TemperatureCoefficiency Isc	IfcPropertySingleValue	IfcReal	The rate at which the short-circuit current of a photovoltaic cell or module changes with temperature
TemperatureCoefficiencyPmax	IfcPropertySingleValue	IfcReal	The rate at which the maximum power output of a photovoltaic cell or module changes with temperature
TemperatureCoefficiency Voc	IfcPropertySingleValue	IfcReal	The rate at which the open-circuit voltage of a photovoltaic cell or module changes with temperature
Degradation	IfcPropertyReferenceValue	IfcNormalisedRatioMeasure	The reduction in the performance of a photovoltaic module over time due to various factors such as exposure to sunlight, temperature, humidity, and mechanical stress
Mismatch	IfcPropertySingleValue	IfcRatioMeasure	The difference in performance or output between two or more components or elements that are intended to work together,
CellEfficiency	IfcPropertySingleValue	IfcRatioMeasure	The effectiveness of a PV cell in converting incident sunlight into electricity

Table 11. Properties under Npset_SolarDeviceSafety.

Definition of Npset_SolarDeviceSafety
Name	Property Type	Data Type	Description
ModuleComponentCombustibility	IfcPropertySingleValue	IfcBoolean	The ability of the components of the BIPV module, such as encapsulant, back sheet, and frame, to resist combustion and the spread of fire in case of a fire incident
MountingCombustibility	IfcPropertySingleValue	IfcBoolean	The ability of the mounting system used to install the BIPV product to resist combustion and the spread of fire in case of a fire incident
HailstoneResistantCertificate	IfcPropertyTableValue	IfcLabel	The BIPV product has been tested and found to withstand hailstones of a specific size and velocity without sustaining damage that would affect its intended function.
CorrosionResistant	IfcPropertySingleValue	IfcBoolean	The ability of a building element or material to resist corrosion or degradation over time, which can be caused by exposure to environmental factors such as moisture, chemicals, or salt

Table 12 introduces Npset_ConstructionCertificate, a new property set to address construction-related properties for BIPV products, filling gaps in the IFC 4.3 schema. Table 13 presents Npset_BIPVCommon, which supplements the missing properties to support comprehensive BIPV system design. It is recommended to classify this set under IfcBIPVElement.

Table 12. Properties under Npset_ConstructionCertificate,.

Definition of Npset_ConstructionCertificate
Name	Property Type	Data Type	Description
DeadLoadBearing	IfcPropertySingleValue	IfcPressureMeasure	The maximum dead load that the BIPV product can bear without failure
LiveLoadBearing	IfcPropertySingleValue	IfcPressureMeasure	The maximum live load that the BIPV product can bear without failure
WeightedSoundReductionIndex	IfcPropertySingleValue	IfcSoundPowerMeasure	The sound insulation of a building element, such as walls, floors, and ceilings, by calculating the sound attenuation provided by the component across different frequency bands
SeismicResistance	IfcPropertySingleValue	IfcBoolean	A building or structure can withstand seismic activity, such as earthquakes, by resisting lateral loads and preventing structural damage or collapse
DesignFrictionDragForce	IfcPropertySingleValue	IfcForceMeasure	The force acting on a building element, such as a wall or a roof, due to wind or other fluid flow, which is used in the design of the building to ensure stability and safety

Table 13. Properties under Npset_BIPVCommon,.

Definition of Npset_BIPVCommon
Name	Property Type	Data Type	Description
CellMaterial	IfcPropertySingleValue	IfcLabel	The raw material which is used to manufacture PV cells (e.g., crystalline, CIGS)
CellTechnology	IfcPropertySingleValue	IfcLabel	The specific technology or manufacturing process used in the production of a PV cell
CellColour	IfcPropertySingleValue	IfcLabel	The visual colour or colour representation of a solar cell
CellPattern	IfcPropertySingleValue	IfcLabel	Refers to any recognisable or repeating design, arrangement, or pattern on a PV panel surface
CellDimension	IfcPropertySingleValue	IfcPositiveLengthMeasure	The physical size or dimensions of a PV cell
ModuleColour	IfcPropertySingleValue	IfcLabel	The specific colour or hue of a BIPV module; it defines the visual appearance of the module
ModuleRigidity	IfcPropertySingleValue	IfcBoolean	Indicating how stiff or rigid a BIPV module is; it quantifies the structural integrity and resistance to deformation of the module.
ModuleTransparency	IfcPropertySingleValue	IfcNormalisedRatioMeasure	The degree to which light can pass through a BIPV module; it is a numerical representation of the module’s transparency or translucency
CustomizableOption	IfcPropertySingleValue	IfcBoolean	Indicating whether a BIPV module can be tailored or adjusted to meet specific design or functional requirements
IntegratiionMethod	IfcPropertyEnumeratedValue	IfcLabel	The technique or approach used to incorporate a BIPV module into a building structure; it specifies the method employed for seamless integration
ApplicableBuildingElement	IfcPropertyEnumeratedValue	IfcLabel	The specific building component or element to which a BIPV module can be integrated; it indicates the suitable elements within a building’s structure for installing the module

The proposed four new property sets and their properties cover the missing properties to describe a BIPV system from both building and electrical perspectives in the current IFC schema (IFC 4.3). With the proposed new properties in IFC4.3, a BIPV product can be described more comprehensively and satisfy users’ requirements in different use cases.

4.5. Validation of BIPV Extension

To validate the proposed BIPV classifications and property sets, this study adopts an Information Delivery Specification (IDS)-based model validation approach. Recommended by buildingSMART [23], IDS provides a standardised method for defining and automatically checking information requirements within IFC models [23]. It enables the proposed BIPV classifications and properties to be formally specified and subsequently verified against an IFC model.

An IDS file (.ids) contains structured information requirements that can be interpreted by software for automated model checking. Each IDS specification consists of three main components: (1) description, which explains the purpose and context of the information requirement; (2) applicability, which defines the IFC objects to which the requirement applies; and (3) requirements, which specify the properties, classifications, or other information that must be provided for the applicable objects [23].

In this study, the IDS requirements were derived from the identified BIPV use cases and associated product attributes. The proposed BIPV classifications and properties were subsequently incorporated into the BIM workflow using the buildingSMART Data Dictionary (bSDD). The enriched BIM model was then subjected to IDS validation to determine whether the required BIPV information was correctly represented and complied with the defined requirements.

The validation process comprised five main stages: (1) defining the required BIPV classifications and properties, (2) developing the corresponding information definitions in bSDD, (3) enriching the BIM model with the proposed BIPV information, (4) applying IDS specifications to automatically identify missing or inconsistent information, and (5) correcting identified inconsistencies and repeating the validation to confirm compliance. The detailed implementation and validation of the selected BIPV classification are presented in Section 4.6. This approach provides practical verification of whether the proposed BIPV extension can be implemented and machine-checked within an IFC-based information workflow. However, the IDS validation is intended to assess information compliance and representation, rather than quantitatively benchmark interoperability performance across different BIM authoring platforms.

4.6. Validation of Classifying BIPV Products Under IfcBuiltElement

This validation classifies BIPV products under IfcBuiltElement for curtain walls in the pre-technical consideration use case. IDS requirements cover integration method, module colour, dimension, shape, transparency, and cell material type for architects and ESD consultants, with optional customisation for architects. Because the proposed BIPV classifications and properties are not natively available in Revit, bSDD was used to define and enrich the required BIPV information before conducting IDS validation.

To meet the requirements of the identified use cases and associated BIPV properties, the required BIPV classifications and properties were defined in the buildingSMART Data Dictionary (bSDD) using usBIM and uploaded to the bSDD server. The defined information was then accessed through the bSDD service and integrated into the Revit model. IFC classifications and BIPV-specific properties were assigned to the corresponding building elements, as illustrated in Figure 10. The yellow elements represent the BIPV curtain walls, with the relevant BIPV properties assigned to these elements. Following this enrichment process, IDS validation was conducted to verify that the assigned classifications and properties aligned with the specified information requirements.

Figure 10. Implement the best enrichment to the Revit model.

Figure 11 and Figure 12 present the IDS requirements used for validation, including the detection of the newly defined IfcBIPVCurtainWall classification. The validation checks the required BIPV properties, including module colour, integration method, dimensions, shape, transparency, and cell material type, against the specified requirements.

Figure 11. IDS description for BIPV classification check.

Figure 12. IDS description for the architects’ requirement check.

The IDS validation was then performed on the bSDD-enriched Revit model. As shown in Figure 13, the validation identified inconsistencies between the model information and the defined IDS requirements. Failed specifications were highlighted in red, with the corresponding reasons provided in the IDS validation results (Figure 14). This enabled missing or incorrectly assigned information to be identified and corrected.

Figure 13. IDS test and highlight faulty specifications in red, Source: Authors’ own work.

Figure 14. The explanation of the faulty specification.

The constraints within bSDD impose that data types be confined to Boolean, character, integer, real, string, and time categories [23] This presents a challenge when integrating with IFC4.3, encompassing a more extensive range of 113 value types under 8.11 IfcMeasureResource. Consequently, newly introduced properties in the bSDD description might not consistently align with the exhaustive list of data types stipulated within IDS. This discrepancy complicates the comprehensive validation of product data types and values through IDS against bSDD. Nonetheless, the primary focus of this validation is to verify the proposed classifications and properties against the IDS requirements. After checking all errors and mistakes, the Revit model is complete and meets the IDS requirement, and the validation process is complete.

The IDS validation provides practical evidence that the proposed BIPV classification and property sets can be implemented and automatically checked within an IFC-based workflow. The process demonstrated both the detection of missing or incorrect information and the subsequent verification of compliance after correction. However, this validation does not quantify interoperability improvements between different BIM authoring platforms. Rather, it demonstrates the practical feasibility, consistency, and machine-checkability of the proposed BIPV information representation. A quantitative cross-platform interoperability assessment is beyond the scope of this study and is identified as a future research direction.

5. Results and Discussion

This paper has comprehensively evaluated different BIPV classification options in the IFC 4.3. These classification methods can be divided into two categories: “create new entities” and “no new entities.” Both categories require creating new property sets to address the absence of BIPV characteristics in the existing IFC schema. Within the “create new entities” category, a shared characteristic is the extension of the IFC schema with new entities (excluding Option 6, which is unsuitable for BIPV products). A notable advantage of this category is that it explicitly identifies BIPV products in the IFC schema. This clarity facilitates information exchange among diverse stakeholders, streamlining the process by reducing manual efforts in selecting relevant properties and attributes.

Each entity in the IFC schema has designated property sets and attributes. Integrating new entities is time consuming and requires significant effort from organisations and the industry, making it a long-term solution. Conversely, the “no new entities” approach leverages existing IFC entities to represent new products, enabling swift implementation. However, this method lacks explicit indication of the BIPV entity, requiring users to manually select property sets and attributes. This can increase file size during exchanges and complicate maintenance as the IFC standard evolves. Thus, this approach is seen as a short-term solution due to these limitations. Both Option 1 and Option 2 classify BIPV under IfcBuiltElement, aligning with BIPV as a building component. Option 1 lacks specific attributes, such as IfcCurtainWall, which requires multiple property sets to meet BIPV needs. Option 2 allows for the inheritance of building properties but faces challenges in consensus and adaptability, as it needs six new entities, making it complex. Option 1 is preferable for practical adaptation and future standards despite needing more property sets. Option 3 classifies BIPV as an IfcSolarDevice, while Option 4 uses an IfcEnergyConversionDevice. IfcSolarDevice has additional property sets (Pset_SolarDeviceCommon, Qto_SolarDeviceBaseQuantities) and proposed sets (Pset_SolarDeviceElectricalCommon, Pset_SolarDeviceSafety), making it a strong candidate. Option 4 distinguishes BIPV from standard PV panels, but Option 3 is preferred for its comprehensive attributes. Option 5 suggests placing IfcActiveBuildingElement under IfcElement, but it risks overlap and conflict, making it impractical. Options 7 and 8 offer short-term solutions without creating new entities. Option 8 is better, showing BIPV components and property sets from building elements, solar devices, junction boxes, and cables using tools like bSDD. Option 1 (IfcBuiltElement) is a better long-term solution than Option 3 (IfcSolarDevice). Option 1 integrates building-related property sets and attributes, offering 39 relevant attributes compared to 22 in IfcSolarDevice. It also depicts interrelationships between BIPV and building elements. Option 1 (a new entity under IfcBuiltElement) is recommended for long-term solutions, and Option 8 (IfcRelAggregates) is recommended for short-term implementation. Option 1 offers future adaptability and mitigates consensus challenges by effectively using existing and new property sets.

6. Conclusions

The classification of BIPV within the IFC schema presents various challenges and considerations. The discussion focuses on classification methods, highlighting two primary categories: “create new entities” and “no new entities.” Within these categories, each option is analysed for its suitability, advantages, drawbacks, and implications for both short-term implementation and long-term adaptability. In the “create new entities” category, explicitly identifying BIPV products in the IFC schema is acknowledged as advantageous for streamlining information exchange among stakeholders. However, the time-consuming nature of integrating new entities and the associated challenges in consensus building are noted. Option 1, which establishes a new entity under IfcBuiltElement, emerges as preferable due to its practical adaptation and future adaptability despite the need to assign numerous property sets. Option 2, while allowing BIPV to inherit building properties, faces challenges in consensus and industry acceptance due to the lack of clarity in BIPV application classification. Options 3 and 4 approach BIPV classification from an electrical standpoint, with Option 3 (IfcSolarDevice) being favoured for its ability to describe BIPV products effectively through newly proposed property sets. Option 5’s proposal of creating a high-level entity (IfcActiveBuildingElement) is deemed impractical due to potential conflicts and overlaps with existing entities, hindering consensus and adoption. Options 7 and 8 provide short-term solutions without adding new entities to the IFC schema. Option 8 stands out for its precise representation of BIPV components and inherent property sets from existing entities, making it a viable short-term implementation choice. The choice between Option 1 and Option 3 is pivotal for a long-term solution. While IfcSolarDevice offers some electrical properties, BIPV’s integration into buildings necessitates access to building-related properties, favouring Option 1. A comparison of attributes further underscores Option 1’s comprehensive utilisation of existing IFC properties, enhancing the interrelationships between BIPV products and building elements. In conclusion, after a thorough evaluation, Option 1 (establishing a new entity under IfcBuiltElement) is recommended as a lasting resolution, ensuring future adaptability and mitigating consensus challenges in the BIPV application. Option 8 (utilising IfcRelAggregates) is endorsed for short-term industry implementation, offering practicality without extending the BIPV schema. By distinguishing BIPV application types and assigning properties to existing building elements and newly devised property sets, Option 1 demonstrates its merit in addressing the multifaceted requirements of BIPV classification within the IFC schema.