Storing environmental impact values in IFC

Activities & Projects Sustainability
1

As a Strategic Sustainability Group of buildingSMART, we faced the challenge of storing tabular values in IFC models. While this is possible with IFC, we encountered problems with the usability of such data given the limitations of software implementation and user awareness.

In EPDs (environmental product declarations) there is usually a table with value for each of 13 indicators (GWP, AP…) and for each of 9 modules (A1, A2…). That means over 100 numbers.

image
image779×164 17.5 KB

Let’s take as an example a property called ‘GWP’ and only two modules: ‘A1’ and ‘A2’.

We have identified 7 options for how this information can be represented:

A) name concatenation

#1=IFCPROPERTYSINGLEVALUE('GWP_A1',$,IFCREAL(304.00),$);
#2=IFCPROPERTYSINGLEVALUE('GWP_A2',$,IFCREAL(14.50),$);

B) list as a string

#1=IFCPROPERTYSINGLEVALUE('GWP',$,IFCTEXT('[304.00,14.50]'),$);

C) IfcList

#1=IFCPROPERTYLISTVALUE('GWP',$,(IFCREAL(304.00),IFCREAL(14.50)),$);

D) IfcTable

#1=IFCPROPERTYTABLEVALUE('GWP',$,(IFCTEXT('A1'),IFCTEXT('A2')),(IFCREAL(304.00),IFCREAL(14.50)),$,$,$,$);

E) separate Property Sets

#1=IFCPROPERTYSINGLEVALUE('GWP',$,IFCREAL(304.00),$);
#2=IFCPROPERTYSET('3...i',#9,'A1',$,(#1));
#3=IFCPROPERTYSINGLEVALUE('GWP',$,IFCREAL(14.50),$);
#4=IFCPROPERTYSET('2...x',#9,'A2',$,(#3));

F) ComplexProperty

#1=IFCPROPERTYSINGLEVALUE('GWP',$,IFCREAL(304.00),$);
#2=IFCPROPERTYSINGLEVALUE('Information module',$,IFCTEXT('A1'),$);
#3=IFCPROPERTYSINGLEVALUE('GWP',$,IFCREAL(14.50),$);
#4=IFCPROPERTYSINGLEVALUE('Information module',$,IFCTEXT('A2'),$);
#5=IFCCOMPLEXPROPERTY('GWP_A1',$,'',(#1,#2));
#6=IFCCOMPLEXPROPERTY('GWP_A2',$,'',(#3,#4));
#7=IFCCOMPLEXPROPERTY('GWP',$,'',(#5,#6));

Options A and B are simple and easily achievable with any BIM authoring tool. But A is not using consistent, standard property name, and B depends on interpretation agreements. Options C and D are technically designed for such a use case in IFC, but we didn’t find any authoring tool capable of creating list or table properties. Option E is possible to achieve with most software, but the logic of defining modules as property set names is not commonly used. Option F is the most technically advanced and closest to the idea of ‘connected properties’ from the ISO23386 standard which is recommended by the EPD-BIM standard ISO22057:2022.

Since none of the solutions is perfect, but we want to provide recommendations, we are seeking your feedback. Let us know what solution you are using or what option you find best. This will be further discussed with the group.

Out of scope in this discussion is whether the environmental impact values should be:

  • referenced or copy-pasted from EPDs to the BIM model
  • static (as declared) or dynamic (calculated based on geometry)
  • per functional unit (e.g. 1m3) or adjusted to actual product
  • in object instances or their types
  • calculated according to any specific LCA standard
  • named in a specific way
1 Like
2

My preference is D).

  • Table values are used rather frequently in the spec. This could be a priority for actual implementation of them in software.
  • It’s the most semantically fit, because we have labels and the types are homogeneous. It is really a mapping.
  • It’s easiest to spot the equality of PropTableValues between the labels as a sequence of IfcIdentifier entries. In case of complex properties it’s harder to see that the information structure is identical. In later edition of the spec we can maybe externalize the ‘header’ (DefiningValues) so that these are shared and consistent among all properties (analogous to the case of PropEnumerationValue).

2nd preference C)

3

To slightly complicate matters: sometimes the values of A1, A2 and A3 are combined into A1A3…

I prefer the tabular approach, but I wouldn’t know how to manage this in Archicad or Revit while preparing a model. As you said, flat IfcPropertySingleValue entries are the easiest, but I fear that this way we will never get to the actual tabular, list or complex properties in implementation.

4

I agree with both of you, in the ideal world the D) is also my favourite solution. And in the case of combined A1-A3, that could be just another column in the table.

While most tools I tried can read List and Table properties (see below), I don’t know any that can author them. That would require a more advanced user interface that allows adding rows and columns. Do you know of any such tool?

Revit:
image

BIM Vision:
image

ACCA usBIM:
image

PS, as you see, given the same input IFC, they all present the IfcTable differently, so even reading is not implemented well enough.

5

Hi All,

I would prefer option F, as it could be easilly expanded in the future. The tabular form may loose the context upon the change of specification. And maybe just follow the CamelCase naming scheme, for GwpA1, GwpA2, GwpC15, …

6

@ejs, do you know any software able to define the complex properties and export to IFC file? I wonder what the interface looks like. From a user’s point of view, it doesn’t seem the most friendly solution.

7

At least BIM Vision 2.25.2, released in 2021. But this is a viewer, not the authoring tool.

See eg. Pset_MaterialWoodBasedPanel for reference. I would prefer this way of storage, as it more robust against future changes.

8

BIMvision indeed can display such properties, but as far as I know it can’t create them, which is the key issue. Of course we could say that this is primarily going to be automatically populated by dedicated LCA software, not BIM authoring tools.

For reference, I paste here a sample IFC4.3 file with all ways to store this information, and below a screenshot from BIMvision. The IfcTable seem not to be displayed correctly, but I do prefer the tabular option (D).
Sample_wall_IFC4x3_all_properties.ifc (13.7 KB)

image

I haven’t asked that before, but do you think grouping should be per environmental indicator or information module? In other words, should it be like I presented on the screenshot, or should A1 and A2 be the higher-level grouping, and GWP be a sub-property? Of course it would make more sense if we had more indicators (ODP, AP, etc.)

9

I think GWP_[ A1| A2 | … ] is sufficient information, the lower level is redundant.
I would see the benefits of more elaborated tree structure if the required information be stored there, eg. GWP->GWP_A1->GWP_A1_InitialData

10

‘Information module’ is the official property of the ISO22057 standard. The intermediate "GWP_A1’ complex property is only to aggregate single-value properties. If you want to rely on this intermediate name, then this solution (F) doesn’t differ much from the (A), as it replies on the name concatenation. To me, there are many difficulties with IfcComplexProperty for almost no added value.

11

What is the current state of this topic/discussion in the Strategic Sustainability Group? Any decissions made?