System Behaviour

[G. Mckoy & E. Madaha]

CHP

[E. Madaha]

OperationThe way the CHP works is more as a part of a larger system rather than just a simple generator; since the CHP is also involved with the heating of the building. This makes the CHP directly dependent on the heat storage, mainly when the water in the heat storage goes beyond critical temperatures. When the heat storage is at a critically low temperature,

5. Implementation 60

it triggers the CHP to turn on. Once on the CPH Will run until the heat storage has reached a critically high temperature where it then triggers the CHP to turn off.

The heat storage avoids staying in a critical low temperature to ensure that the building can always be heated. Hence, it automates the running of the CHP to prevent a situation where the heat demand is high and the heating system needs to wait for the CHP to turn on. Adversely the heat storage also avoids overheating to keep some parts of the heating infrastructure from being damaged or malfunctioning as that would compromise the heating system as a whole.

To simply simulate the normal operation of this device, it is required to study the heat demand and create a similar type of characteristic from this data, this is the focus of the work done in the heat demand aggregation 5.3.2. As concluded in this section, the module built for running the forecast was not ready at that time, so instead a simple heat simulation with a linear behaviour was used, following the average change in the heat storage’s temperature throughout the day.

The code for the simulation at the end is just a linearly growing heat demand where once the set critical low temperature is reached the simulated CHP is changed to an ’ON’ state.

Once the CHP is on the temperature starts to rise linearly by the estimated average based on the historical behaviour, eventually it is turned to the ’OFF’ state once the threshold for the high temperature is reached. The code was written as a simple JavaScript functional node in separate Node-RED flow.

PV & Converter [G. Mckoy]

The PV Converter simulation has two modes. The first is a script that generates random values depending on the time of day. The program generates values ranging from 30 to 80 percent of the maximum kW value produced by the PV between the hours of 9:00 and 17:00 to simulate daylight. For the remaining hours of the day the values are between 0 and 5 percent. The second version of the PV simulation makes use of the communication module 5.1.1 to receive actual readings from a real PV system. These values are sent to the Raspberry Pi over Modbus where they are processed and written to a file, PV_output_file.txt.

The following is a description of the PV_output_file.txt file:

MODE: REAL_PV CHARGE_RATE: 11 DISCHARGE_RATE: 0 CHARGING_BAT: True

5. Implementation 61

SUPPLYING_GRID: True

The MODE is used to tell if the system providing the values is a real or simulated one.

CHARGE_RATE is the kW value being produced by the real or simulated system. DIS-CHARGE_RATE is the amount of energy in kW to be supplied to the grid. The CHARG-ING_BAT indicates if the battery is charging or discharging while SUPPLYING_GRID indi-cates if the converter is outputting to the grid.

Battery [G. Mckoy]

To simulate the charging and discharging of the battery, a Python script was created that makes use of the communication module described in section 5.1.1. The script works by reading the contents of the converter output file and the Modbus register assigned to it in an infinite loop to know its current mode of operation.

The battery has three modes of operation:CHARGING,DISCHARGINGandNone. The state of the battery is stored in a text file so that the data is not lost on reboot of the Raspberry Pi.

Below is a description of the construct of this file:

CHARGING: None CHARGED: 1800000 CAPACITY: 1800000

Upon running the script the values of the battery file are stored in memory to be used to help determine its mode of operation. To charge the battery a charge signal can be sent to the Pi over Modbus from Node-RED. This signal is in the form of a byte with each bit representing a different behaviour. Once the mode has been determined, the program checks the current state of the battery to see if it is fully charged or not. If the battery is fully charged, the charge command is ignored. If the battery is not fully charged, the program reads the value of the file to which the converter stores its output, PV_output_file.txt. After successfully reading the CHARGE_RATE value from the PV_output_file it is added to the state-of-charge of the battery. Should this value be larger than that of the remaining storage then the state-of-charge is set to that of the capacity.

To discharge the battery, a discharge signal similar to that of the charge signal can be sent from Node-RED. The program then checks, if the battery has a state-of-charge to meet the value stored in the discharge file. If the state-of-charge is more than the discharge value,

5. Implementation 62

then it is subtracted and the new state-of-charge stored. If the value is less, then it is set to zero. Once the state-of-charge value is set to zero the discharge command is ignored.

For the lab test, the controls of the battery are rooted into the state of the converter. The converter will charge the battery as long as the PV is producing more energy than the grid demands and the battery is not fully charged. If the energy being produced is less than the demand then the battery will automatically fill this gap. A slight increase can be seen in the output of the battery from time to time resulting from rounding during the conversion process.