Additional attribute status in EnergyDemand

[JoachimBenner]

The featureType EnergyDemand can be used either to provide input data for energy demand simulations or to represent the output data of these simulations. At the moment, EnergyDemand has no property to indicate whether the property energyAmount carries input data or simulation results.

Proposal

1. Introduce a new (mandatory?) property status of EnergyDemand with property values defined by an enumeration
2. Introduce a new enumeration EnergyDamandStatusValue with items: Simulated, Measured, Estimated, Unknown (must be discussed)

[RomainNouvel]

Through "input data", I guess you're thinking about measured data, in particular for validation purpose... This issue is actually not specific to EnergyDemand but also EnergySource, OccupancySchedule (use of sensor vs. occupation hypothesis), and possibly many other time series.

The existing parameter "acquisitionMethod" of TimeValuesProperties aims at giving this information, as a String type ("Simulated with software X", "Measured in 2011 with heat meter at the outlet of the gas boiler" "). The present purpose of this parameter is to give a mere description of the data acquisition. However, if it is judged that this parameter should be automatically used in a process, an enumeration type would be then very welcome. To be discussed...

[JoachimBenner]

I agree that the information I miss is not specific for EnergyDemand and seems always be related with time series. Thus, it is a good idea to specify an additional property of TimeValueProperties which can be automatically interpreted by software.

[RomainNouvel]

Do you have an example where a software should be able to automatically "interprete" this information? Do you have such a software? Sorry, but i don't understand presently the purpose of such a function...

[JoachimBenner]

I think, it is quite natural that a time series of values has a machine interpretable meta datum, indicating whether the values have been measured, calculated, or anything else. We are actually working to implement the Energy ADE in our software IfcExplorer / FZKViewer, in combination with the energy simulation software of our industry partner. Hopefully, sometime in the future we will have data sets with measured and calculated time series of the same property, and then we need the requested attribute, e.g. for automatic labeling of diagrams.

[RomainNouvel]

I just fear that a list of fixed values (e.g. "Measured", "Simulated") do not represent the diversity of the acquisition methods (e.g. "Measured on the period 2005 - 2010", "Simulated with CitySim"). En Enumeration is for sure not a good idea. What about a codelist extendable by every user, replacing the String type of Acquisition method...

[JoachimBenner]

Agree, as long as we have at least "Measured" and "Simulated" as core of this Codelist

[RomainNouvel]

Agree (+ calibrated Simulation)

[mlauster]

@RomainNouvel , @JoachimBenner, do you have an agreement on this? If so, does the core team takes care of the implementation?

[JoachimBenner]

From my side, this is o.k.

[mlauster]

Proposal: Change of type of the parameter "acquisitionMethod" of TimeValuesProperties to CodeList with values:

• Measurement
• Simulation
• Calibrated Simulation
• Estimation
• Unknown

[oliviertournaire]

Implemented in latest version of the UML model