Building Key Performance Indicators (KPI)

[RomainNouvel]

Key Performance Indicators may be important for energy analyses at urban scale, helping for example to understand building consumptions, plan an energy refurbishment strategy, or compare different energy planning variants.
They are generally intermediary/final outputs, deduced from other geometry and physical parameters of the 3d city model.

Some useful KPI:

• surfaceAreaToVolumeRatio (index of compacity)
• meanUValue (global envelope insulation level)
• specificPrimaryEnergyDemand (global efficiency of the building)

This issue is a general question: do we want to include some KPIs in our ADE Energy? If yes, they would be parameters of _AbstractBuilding.

[Fouly]

Hi Romain,

In fact I'm working on a General Indicator Model (GIM) that allows expressing indicators and indexes which consistently show sophisticated functions on the elementary data and indexes representing simple functions for different domains. The domain that we're using as a proof of concept of our work at this very moment is the energy domain. @Maryamzk was quite exposed to this model and framework during her Master thesis?

Generally, including KPIs in the ADE Energy ought to be a necessity for the decision making process. I do agree with the concept that we need some attributes that can be used later as an indicator in the decision making process. But i'm not sure if I got it right, why do these attributes have to embedded in the _AbstractBuilding? Why can't we represent them in their corresponding classes (if possible)?

[RomainNouvel]

Hi Mostafa,
The described KPIs should be related in a way with Abstract Building. However, it must not be integrated as class attribute. Your solution could apply here. Can you precise how you will technically relate your KPI object class of GIM to Abstract Building? Do you have any implemented example?

[Fouly]

Hi Romain,
Can't agree more, KPIs ought to be linked to the geospatial application schema (e.g. AbstractBuilding), but not as an attribute.

Basically when we think of GIM we see it as more of standardised kind of indicators where you've to conform to it if you'd like to implement domain-independent indicators. In our case here we apply it on energy-related domain indicators. Indicators are decided on the domain-specialist side.

On the one hand we've the domain-specialist (e.g. energy planner) deciding on which indicators he/she would like to consider. On the other hand the geospatial application schema model (e.g. city modeller) provides us with the geodata required to perform our analysis. How to connect these two is our question and our point of research. I would like to attach a pdf file explaining this point further but unfortunately attaching documents requires write permission which apparently I dont have. So maybe I just send it to you over your email.

[Fouly]

1. 'meanUValue' , should be related to the wall surface? or the attribute should be set directly at the _AbstractBuilding class?
2. 'surfaceAreaToVolumeRatio' is indeed a useful indicator, but can't we calculate it from the current attributes we have? If so, I don't see a necessity of adding it as an attribute.
3. 'specificPrimaryEnergyDemand' is closely related, as you mentioned, to issue Energy Performance Certification #46, and I think it has been covered by the solution you and pg suggested.

[RomainNouvel]

1. meanUvalue is to be related with the _abtractBuilding (is the sum of all Uvalue x Wall Surface / Sum Wall Surface)
2. This ratio is naturally a result from current attribute (exactly like meanUvalue, volume or specific Heating Demand). The question here is: can't we store calculation results in the city model? Actually all your KPI are calculation results. For trivial calculation, I agree with you that this is not necessary. I don't think that the calculation of the SA2V ratio is so trivial however
3. this is not a Bulding Performance Certification but a result allowing to achieve such a certificate. Therefore, I wouldn't include it in the issue 46 but in the GIM here.

[JoachimBenner]

Leaves open, no part of version 0.7.0. KPI's shall be no part of the Energy ADE.

[JoachimBenner]

Decision og Energy ADE plenum at December 6th, 2017: Issue will not be handled in Version 1.0