EN 15804+A2, chapter 7.1, i), variability of results

[RobertSpang]

Implementation status:

• [x] schema
• [x] examples
• [ ] reviewed & approved internally
• [ ] documentation
• [ ] validation rules

I raise this change request because...

-- [ ] the ILCD+EPD format lacks compliance with regualtions. -- [X] the ILCD+EPD format lacks conformaty with standards. -- [ ] the ILCD+EPD format needs to be improved regarding existing format or master data elements. -- [ ] there is another problem or use case I´m trying to address.

Problem description

"in the case where an EPD is declared as an average environmental performance for a number of products a statement to that effect shall be included in the declaration together with a description of the range/ variability of the LCIA results if significant"

Solution description

Could be included in the following existing fields:

• A1.4 General comment on data set
• B2.2 Use advice for data set

Partly covered by B1.2 "subtype"

Relevance or added value

Medium relevance

[RobertSpang]

In the field "subtype" we already specify whether something is an average or not. However, the term "variability" is not defined --> maybe EN 15941 has a definition. We would prefer a machinereadable solution if feasable.

[okworx]

Suggestion: use the same systematic as defined in ISO 22057, ideally amalgamate the variants given there for EN15804 and ISO21930 in order to have a unified and universal approach.

We need an enum for describing the type on manufacturer level

• valid for one production site
• valid for a manufacturer with several production sites
• valid for several companies with several locations

as well as optionally a number for the variation (in %) if described.

And we need an enum for describing the type on product level

• valid for a single product
• valid for a range of products where variability is described

as well as optionally a number for the variation (in %) if described.

Add a freetext comment field (e.g. with explanations on the method how the variability has been calculated).

[okworx]

Let's consider a significant variation to be one that is larger than 10% (following ISO 14044). We're looking at multiple indicators and multiple modules, so there is no single variation per se. It would first need to be defined which variation exactly. Let's assume for now that there is an agreed approach to this.

[okworx]

How is variability defined? How is "product" defined? EN15804 differentiates b/w manufacturers and groups of manufacturers, maybe this is something to be considered as well. -> this is covered

[okworx]

@ domain experts (@EmilieBrisson @RobertSpang @szwerenz): please review and approve (by giving a thumbs up 👍) or else comment

[RobertSpang]

so this is a conditional field: if average, then it´s mandatory. if mandatory, lets add the "classes" of ISO 14044 Annex B to identify the variability. this way we can also make it machine readable. Ok from your side?

[1aun]

I would advise against it.

This, to me, is a feature request for the business or presentation layer of a software application, because it can easily be derived from the given value.

So, in regard of persistence, it seems redundant.

[RobertSpang]

no - variablity of an average cannot be derived from declared values. Variability is determined by the underlying data (= foreground data, recipes etc.). So we could use the classes from ISO 14044 to declare variability: <=2,5% neglectible variation

2,5 - 10% minor or "normal" variation 10% - 25% relevant variation 25% - 50% significant variation Makes sense?

[1aun]

Thanks for the quick response!

The suggested implementation would look like this:

<variability>
   <manufacturerVariability type="Single production site" variation="5"/>

   <productVariability type="Range of products where variability is described" variation="20"/>

   <variabilityDescription xml:lang="en">... desc ...</variabilityDescription>
</variability>

I was referring to the variation value here, which in both instances holds the numerical value for variation in percent.

I think this covers it without locking us into ISO 14044?

[RobertSpang]

This needs explanation; please set up a meeting to explain this to me. thx.

[szwerenz]

I also dont understand the statet solution a meeting would help. Otherwise i dont see the necessity to have it as a machine readable informaiton. I think a describtion in an existing field should be sufficient.

@EmilieBrisson what do you think, do you need that information on building level?

[EmilieBrisson]

I agree (sort of) with @szwerenz. As of right now, we do not use variability. But it might come. I do not think the ide above is a bad idea, but maybe with some more explanation for the group here, would be nice. Though I would maybe suggest UUID for the specific identified cases, from the screenshot @RobertSpang did. Othrwise we might get a lot of unusefull entries.