.BuildingSystems.Fluid.HeatPumps.ModularReversible.Controls.Safety.BaseClasses.PartialOperationalEnvelope

Information

Model to check if the operating conditions are inside the given boundaries. If not, the heat pump or chiller will switch off.

This safety control is mainly based on the operational envelope of the compressor. Refrigerant flowsheet and type will influence these values.

Limitations

• Only three sides of the real envelope are implemented (Figures 2 and 3). The real operational envelope implies continuous operation. This means start-up from e.g. a cold heat pump supply temperature is possible. To avoid additional equations for startup and continuous operation, we neither implement the lower boundary for heating nor the upper boundary for cooling devices. This avoids the situation where the device can never be turned on.
• From all the influences on the real envelope, the compressor frequency impacts the possible range of operation. However, the compressor speed-dependent envelopes are typcially not provided in datasheets. Further, including a third dimension requires 3D-table data. This is currently not supported by BuildingSystems or Modelica Standard Library.

Existing envelopes

Technical datasheets often contain information about the operational envelope. The device records for heat pumps ( BuildingSystems.Fluid.HeatPumps.ModularReversible.RefrigerantCycle.TableData2DData) and chillers ( BuildingSystems.Fluid.Chillers.ModularReversible.RefrigerantCycle.TableData2DData) contain typical values. Older devices typically have lower limits while new refrigerant machines based on propane or advanced flowsheets are able to achieve temperature over 70 °C for heating.

Parameterization from datasheets

Depending on the underlying datasheet in use, you have to think thoroughly if you need inlet or outlet conditions, and if you are modelling a heat pump or chiller. Figure 1 depicts possible upper and lower boundaries as well as what variables the boundaries are defined with. Depending on your setup, you may have to transpose existing boundaries. For instance, when using an envelope designed for a heat pump in a chiller model, the useful side (column 2 of the data) is not the condenser but the evaporator. Thus, you have to switch columns 1 and 2. The following examples aim to explain how to obtain the envelopes:

If the model in use is a heat pump, the useful side is always the side of TConOutMea and TConInMea. In the chiller, the useful side is always the side of TEvaOutMea or TEvaInMea.

1. The envelopes for air-to-water heat pumps often contain water supply temperature (TConOutMea) on the y-axis and ambient temperatures (TEvaInMea) on the x-axis. In these cases, tabUppHea is based on the y-axis maximal values and tabLowCoo based on the y-axis minimal values. Figure 2 depicts this setup.
2. The envelopes for air-to-air devices often contain ambient inlet (TConInMea) as y and room (TEvaInMea) inlet temperatures as x. In these cases, tabUppHea is based on the x-axis maximal values and tabLowCoo based on the x-axis minimal values. Figure 3 depicts this setup.
3. Compressor datasheets often provide evaporating and condensing temperatures or pressure levels. Those are not avaiable in the simpified model approach. Thus, you have to assume pinch temperatures to convert it to either in- or outflow temperature levels of the secondary side temperatures (i.e. TConOutMea, TConInMea, TEvaInMea, TEvaOutMea).

Figure 1: Possible upper and lower boundaries as well as temperature specifications in datasheets

Figure 2: Example for an air-to-water heat pump or chiller. The supply temperature is the temperature leaving the device into the hydraulic circuit of the building. Red crosses indicate the point to write into the 2D table in Modelica.

Figure 3: Example for an air-to-air heat pump or chiller. The room temperature acts as an inflow to the device. Red crosses indicate the point to write into the 2D table in Modelica.

Revisions

• November 26, 2018 by Fabian Wuellhorst:
  First implementation (see issue AixLib #577)