_SolarEnergySystem

[RomainNouvel]

In the Energy ADE 0.6:

1. the SolarEnergySystem present only the geometrical information "collectorSurface", "panelAzimuth" and "panelInclination", and not a given geometrical surface.
2. Furthermore, it is linked only to BoundarySurface with an optional double relations: a) The "installedOn" relation from SolarEnergySystem to BoundarySurface is the mostly used case, where we want to calculate the photovoltaic electricity production of a given PV system, in particular to cover the electrical demand. This relation should be mandatory. b) The "equippedWith" relation from BoundarySurface to SolarEnergySystem has been originally designed for Photovoltaic Potential study, where the SolarEnergySystem is a floating object not related to an EnergyDemand. This relation could be avoid if the SolarEnergySystem is related in a way with a Building (which is possible with the relation "has" from AbstractBuilding to EnergyConversionSystem.
3. The case of tilted PV panels on flat roof is not considered in our Schema (here, the SolarEnergySystem MUST be laid on a Roof/facade)
4. The attribute area of SolarEnergySystem should be detailed (aperture area, module area, gross area?).
5. The present schema does not allow to integrate Hybrid PVT panels

Propositions for Energy ADE 0.7:

• It should be possible to relate SolarEnergySystem with a (outer) BuildingInstallation instead of a _BoundarySurface
• An optional attribute surfaceGeometry , type GM_MultiSurface[0..1], would be required in the case that the solar panels do not correspond 1-to-1 to the BoundarySurface
• the attribute panelAzimuth and panelInclination are not necessary/relevant, from the moment that a relation exist between SolarEnergySystem and BoundarySurface, respectively BuildingInstallation (or if the optional attribute surfaceGeometry is indicated).
• the relation "equippedWith" from BoundarySurface to SolarEnergySystem could be deleted.
• the relation "installedOn" from SolarEnergySystem to BoundarySurface, respectively BuildingInstallation, should have the cardinality 0..1 (if a Solar installation covers really several BoundarySurface, then it should be divided in several SolarEnergySystem).
• The SolarEnergySystem should be distinguished between "PhotovoltaicSystem" (with only attributes moduleArea and cellMaterialType, since installedNominalPower (=peak power) and nominalEfficiency (=performance ratio) are already the attributes of EnergyConversionSystem), "SolarThermalSystem" (with attributes apertureArea, eta0, a1, a2 and technologyType) and "PhotovoltaicThermalSystem" (with all attributes of the two latters).

[RomainNouvel]

• technologyType (or rather CollectorType) of SolarThermalSystem and PhotovoltaicThermalSystem is an enumeration: "FlatPlaneCollector", "EvacuatedTubeCollector".
• cellMaterialType (or rather cellType since cellmaterial = silicon often) of PhotovoltaicSystem and PhotovoltaicThermalSystem is an enumeration:"Monocrystalline", "Polycrystalline", "Amorphous"...

[mlauster]

@jaykae26, can you comment on that and if @RomainNouvel made a good proposal, label this as ready for ADE Core?

[gioagu]

I am not so sure about adding a surfaceGeometry to the SolarEnergySystem. I understand and agree with the need, but I wonder whether it is the right approach. As a matter of fact, any SolarEnergySystem (installed on a building) is per definition already an outer BuildingInstallation. Therefore, it is already possible to model it geometrically (though from LoD2). As long as a SolarEnergySystem is a semantic object, ok, but so we may add a geometrical attribute to something that has already a geometry.

On the other hand: how would you model a solar panel that is not "mounted" on a building, e.g. like in solar power plant? So I agree that simply extending a BuildingInstallation would not suffice or cover all the cases.

[JoachimBenner]

I mostly agree with the proposal of Romain. The only exception is the topic

The relation "installedOn" from SolarEnergySystem to BoundarySurface, respectively BuildingInstallation, should have the cardinality 0..1 (if a Solar installation covers really several BoundarySurface, then it should be divided in several SolarEnergySystem).

In existing CityGML data, the division of e.g. a building wall or roof into WallSurface / RoofSurface objects is sometimes a little bit arbitrary. Thus, in some cases it might be difficult to divide a solar installation among different boundary surfaces. We should leave the cardinality 0..*, but add an (informal) restriction, that all referenced BoundarySurfaces must have the same orientation (azimuth and inclination).

We can make the _SolarEnergySystem attributes optional, but then we must clearly state that

• either a relation to a BuildingInstallation or to BoundarySurfaces must be available, and
• the solar installation covers the total area of the BuildingInstallation or BoundarySurfaces.

Because the latter condition may not always be fulfilled, I thik we need an extra geometry property surfaceGeometry of _SolarEnergySystem

[RomainNouvel]

The original (and, I think, only) purpose of the relation "installedOn" is to get the solar irradiance (in W/m²) incoming on the BoundarySurface or BuildingInstallation on which the SolarEnergySystem is installed, in order to calculate ist Energy yield (based on the area of the solar System). Then, in the case that a Roof is divided in several small BoundarySurface with the same orientation, the incoming solar irradiance of all of them will be identical (unless if there is a very close obstruction object). Then, no need to have a cardinality 0..* of "installedOn" in this case, just mentioning that the "SolarEnergySystem" is "installedOn" the mostly covered BoundarySurface.

[mlauster]

@RomainNouvel, @JoachimBenner, is there an agreement on this? DOes core takes care of implementation?

[RomainNouvel]

Request of Change:

• new relation "installedOn" from _SolarEnergySystem to BuildingInstallation
• new optional attribute surfaceGeometry in _SolarEnergySystem, type GM_MultiSurface[0..1]
• delete attributes panelAzimuth and panelInclination in _SolarEnergySystem
• delete relation "equippedWith" from BoundarySurface to _SolarEnergySystem.
• replace ADEElement<_AbstractBuilding> as source of the "has" relation to the _EnergyConversionSystem by a ADEElement<_CityObject> (example: case of a PV installation on a agricultural field)
• new attributes moduleArea (AreaType) and cellType (enumeration) in PhotovoltaicSystem. The elements of cellType are "Monocrystalline", "Polycrystalline", "Amorphous". Delete cellMaterialType.
• new attributes apertureArea (AreaType), eta0 (double), a1 (double), a2 (double) and collectorType (enumeration) in SolarThermalSystem. The elements of collectorType are "FlatPlaneCollector", "EvacuatedTubeCollector". Delete technologyType.
• new class PhotovoltaicThermalSystem which inherits from _SolarEnergySystem (Definition : hybrid photovoltaic and solar thermal system), with the attributes of both PhotovoltaicSystem and SolarThermalSystem.
• relation "installedOn" from _SolarEnergySystem to BoundarySurface, respectively BuildingInstallation, should have the cardinality 0..1 (if a Solar installation covers really several BoundarySurface, then it should be either divided in several SolarEnergySystem, or a unique representative Buildinginstallation/BoundarySurface covered by the System should be considered).

[JoachimBenner]

I made the following additional changes:

• For consistancy reasons, the relation "installidIn" points from EnergyConversionSystem to _CityObject
• The attribute "collectorSurface" of _SolarEnergySystem is deleted, because it is replaced by the more specific attributes "apertureArea" / "moduleArea" in the derived classes.
• The two new enumeration properties (cellType / collectorType) are specified as mandatory attributes, all other new properties are optional. Is this o.k.?

[mlauster]

Sounds good for me. @RomainNouvel, do you have something to add?

[RomainNouvel]

Hi Joachim, Ok for your reported changes. Do you plan to implement also the further requested changes of this issue in the new Energy ADE 0.7? Do you have some remarks about them?

[oliviertournaire]

Implemented in latest version of the UML model. @JoachimBenner Just a short comment: attributes a1, a2, apertureArea, collectorType and eta0 can be moved to an abstract class. Thus, SolarThermalSystem and PhotovoltaicThermalSystem would inherit this class (just a refactoring issue). Issue cand be reopened later based on this comment