Loadshedding Background
In recent years, South Africa has faced an ongoing electricity supply crisis, leading to the implementation of controlled loadshedding, as a method of equitably distributing available electricity to all customers of Eskom, South Africa's utility company.
Essential principles of the loadshedding method:
Loadshedding Stages: Eskom declares load shedding stages ranging from 1 to 16, which are implemented nationwide. A higher stage indicates a more severe reduction in power supply and a larger number of outages. Municipalities have the authority to override the national stage, allowing them to adjust for power supply shortages and declare a lower stage.
Suburban Division: The country is divided into suburbs, each with a unique monthly schedule detailing expected outages for every stage. For instance, if Eskom declares stage 2, each suburb has a specific outage schedule for that stage.
Frequency and Duration: Each suburb may experience up to three daily outages, with durations varying between a minimum of 1 hour and a maximum of 4.5 hours.
Galooli's Solution
Galooli's solution comprises several key components:
Loadshedding Schedule Integration: Enable our clients to access the loadshedding schedule by integrating a third-party API. Thereby providing a clear view of upcoming outages and integrating the planned outage data into various analyses.
Grid Availability Analysis: Receive notifications and analyze the grid availability status regarding planned outages, to detect and address both malfunctions and unplanned grid failures effectively.
Battery Autonomy Notifications and Analysis: Receive notifications and analyze battery autonomy in relation to the planned outage duration. This ensures that the site's storage capabilities can serve as a backup for the entire outage period, thereby preventing downtime or reliance on inefficient energy sources.
Fuel Autonomy Analysis - If generators serve as the primary backup to the grid, the system can monitor and predict the duration for which the generator can supply power to the site without requiring refueling. This ensures uninterrupted operation during loadshedding outages.
Automated Generator Control: Implement a remote mechanism to start the generator a few minutes before an expected outage, thereby preventing downtime and unnecessary site visits.
Loadshedding Schedule Integration
The system actively tracks the national loadshedding stage and the schedule for each suburb for the upcoming week per stage. The system updates the stage every hour, while the suburb schedules refresh every 24 hours. Consequently, the number of API requests depends on the number of suburbs (different sites can be part of the same suburb), along with 24 requests to query the stage. It is possible that the system will trigger additional queries if, for example, the location of the unit has changed.
To facilitate this, a new "Load Shedding" group has been added to relevant organizations, where schedules are stored for each site based on its suburb (below Additional Information - Load Shedding). Each schedule includes:
Suburb ID: Identifies the suburb where the site is located, obtained from the API reply, based on the site’s latitude and longitude. The user can override the API query by specifying the id in the following format: 'subrub_id@Manual'.
Stage Municipality - In certain instances, cities or municipalities may override the national stage and declare a different stage for the suburbs they supply power to. This field will be populated by the API to determine the specific municipal stage applicable to the unit's suburb.
API Status - the status of the API requests. Can include the following results:
Last updated: [update time] - The API query was successful, and the information for the unit was last updated at the specified time.
Invalid suburb ID - The API query failed due to an invalid suburb ID format. This issue typically happens if the suburb ID was entered manually.
Invalid location - The API query failed because the unit does not have location data.
Suburb ID not found for location (Lat, Lng) - The API query failed because the suburb ID could not be determined from the provided location data.
Non-stationary unit - No API query was made as the unit is no a stationary unit, therefore not relevant to the loadshedding schedule.
Off-Grid unit - No API query was made as the unit is off-grid, therefore not relevant to the loadshedding schedule.
Schedule: Highlights the next anticipated outages based on declared stages and the suburb weekly schedule. In the absence of any relevant declaration by Eskom or no outages expected during the declared stages, these fields will remain empty.
For example, on 19/10, there is no load shedding from 00:00 to 16:00, but stage 2 is expected from 19/10 16:00 to 20/10 05:00. According to the suburb's schedule for stage 2, an outage is anticipated from 19/10 22:00 to 20/10 00:30. In this case, the load shedding fields will display only this particular outage, as there are no other planned outages before 20/10 at 05:00 and no declarations for the subsequent stage.
To store the real-time status of the national stage and the municipalities stages, a new "Load Shedding" group has been added to the Organizational Information.
Relevant Displays and Reporting Fields
Live Display - The unit's live display (Panorama, mobile app) will show the current load shedding status:
If the unit has an active planned outage, it will display the currently applied stage.
If there is no active load shedding, it will show the start time of the next planned outage based on the load shedding schedule.
If there are no planned outages according to the declared stages, it will indicate 'No Upcoming Load Shedding'.
Additionally, the 'Grid Fail' digital alarm will specify if the outage is caused by the schedule.
Reports - The complete schedule and the stages, as obtained from the API, can be accessed in the 'My Units' Information tab or be included in any report or dashboard, using the fields:
Outage Window 1..3 Start Time - the time the next outages are expected.
Outage Window 1..3 Duration - the duration of each one of the expected outages.
Organizational KPI - Current stages for the national and other municipalities stages. The national stage can be overridden by municipalities. Supported municipalities for overrides include Cape Town and eThekwini.
Required Settings
Unit's location - To receive the unit's suburb ID and schedule, the unit's data must include the location's coordinates (latitude and longitude). Alternatively, users can upload the suburb ID directly using the 'Manual' format (e.g., 'tshwane-12-montanatuineext47@Manual').
Grid Availability Analysis
Monitoring and analyzing grid availability with respect to planned outages is critical for effectively masking these scheduled events from operators' alerts and analyses. This approach optimizes response times and resource allocation, enhancing overall reliability and minimizing downtime due to unforeseen events. The Galooli Solution has been upgraded with the following features to tackle this issue:
'Is Planned Grid Fail' - A new digital field has been added to the system to specify if the unit is currently experiencing an active planned outage according to the loadshedding schedule.
The field is being updated when the unit transmits data. Therefore, if the unit is disconnected, the field might not be updated even though the planned outage has begun.
This field can be included in reports or dashboards to monitor the status of planned failures as part of asset and detailed reports.
Avail. Time Grid - Planned Failures Included - A new summary field has been introduced for grid availability to account for planned outages. During times when the grid fails due to a planned outage as per the load shedding schedule, this time will be considered as available. Regarding the fields used in aggregation, a grid is defined as available if the 'Grid Available' digital is true or if the 'Is Planned Grid Fail' digital is true.
NOC alarm - Mains Failure - The 'Mains Failure' alarm, triggered by a grid failure (the field 'Site Global Grid Fail' is true), will not be activated if the outage is planned according to the schedule. This updated logic activates the alarm only when 'Grid Fail' is true and 'Is Planned Grid Fail' is false.
Required Settings
Third-party API integration to receive the loadshedding schedule, as specified in the 'Loadshedding Schedule' section above.
Battery Autonomy Analysis and Notifications
An analysis of the battery autonomy includes an assessment of the battery discharge time, which is based on the site's battery model and capacity, state of health, state of charge, and the actual load of the site's consumption. This parameter can be compared to the planned outage duration, to ensure that the site's storage capabilities can serve as a backup for the entire outage period, thereby preventing downtime or reliance on inefficient energy sources.
The loadshedding solution includes several automations, that implement the battery autonomy analysis and send notifications to the configured users if necessary.
Live Battery Autonomy Notification Script
The automation should be executed every 5-10 minutes.
The automation calculates the real time battery autonomy for each unit which meets all the conditions below:
Unit is connected.
Unit has an active planned outage (according to 'Is Planned Grid Fail').
Unit has smart batteries configured.
Unit has the values for the parameters detailed below 'Required Settings' section.
Unit has not been notified of battery autonomy issues in the current outage window.
The automation will estimate the battery's discharge time based on the unit's parameters:
Real-time SOC - average of all smart batteries.
Minimal discharge SOC (SOC at LVD) - according to the battery model: 43% for Polarium and AmoGreenTech, 46% for LG-Chem.
Real-time SOH - the minimal value for all smart batteries.
Battery Capacity - Maximum value between X-RAY.Rectifier-1..5.Battery Total Capacity, and Additional info → Battery Capacity.
Nominal Voltage - according to the battery model: 50.8V for Polarium and LG-Chem, 48V for AmoGreenTech.
Real-time consumption - Site Global Consumers Load Power.
The automation monitors if the battery autonomy falls below the remaining time of the outage and sends a notification if this condition occurs consecutively twice. The result will also specify if the solar is currently available and contributing to the site's energy production, so the battery might not need to supply the entire load.
Predicted Battery Autonomy Notification Script
The automation should be executed once a day.
The automation calculates the predicted battery autonomy for each unit which meets all the conditions below:
Unit has an upcoming loadshedding (according to the schedule - Outage Window 1 Start Time).
Unit has smart batteries configured.
Unit has the values for the parameters detailed below 'Required Settings' section.
The automation will estimate the battery's discharge time based on the unit's parameters:
Max possible SOC - according to the battery model: 93% for Polarium and LG-Chem, 100% for AmoGreenTech.
Minimal discharge SOC (SOC at LVD) - according to the battery model: 43% for Polarium and AmoGreenTech, 46% for LG-Chem.
Real-time SOH - the minimal value for all smart batteries.
Battery Capacity - Maximum value between X-RAY.Rectifier-1..5.Battery Total Capacity, and Additional info → Battery Capacity.
Nominal Voltage - according to the battery model: 50.8V for Polarium and LG-Chem, 48V for AmoGreenTech.
Predicted consumption for the loadshedding timing - The average consumption of the previous week, specifically for hours the outage is planned for.
The automation monitors if the battery autonomy falls below the expected duration of the next outage and sends a notification if this condition is met.
Required Settings
Battery autonomy calculations apply only to smart batteries (LIB).
Battery capacity - can be read as part of the X-Ray mechanism ('Rectifier 1..5 - Battery Total Capacity'), or filled manually in the unit's additional information, below the 'Battery' section.
Site consumption monitoring - the consumption of the site must be monitored and stored below 'Site Global Consumers Load Power'
Third-party API integration to receive the loadshedding schedule, as specified in the 'Loadshedding Schedule' section above.
Fuel Autonomy Notifications and Analysis
If generators serve as the primary backup to the grid, the system can monitor and predict the duration for which the generator can supply power to the site without requiring refueling. This ensures uninterrupted operation during loadshedding outages.
Predicted Fuel Autonomy Notification Script
The automation should be executed once a day.
The automation calculates the predicted fuel autonomy for each unit which meets all the conditions below:
Unit has an upcoming loadshedding (according to the schedule - Outage Window 1 Start Time).
Unit has a fuel tank configured.
The automation will estimate the time before refuel is required based on the unit's parameters:
Real-time fuel level - the generator's actual fuel level.
The generator average consumption rate - according to the calculation of Generator Load Based Consumption. This field is estimating the generator's consumption if it is not rational according to the generator KVA, based on an algorithm that takes into account the generator's average load power.
The automation monitors if the autonomy falls below the expected duration of the outage and sends a notification if this condition is met.
Optional Settings
To ensure an accurate estimation of fuel consumption rate, configure the generator KVA and monitor its power output. This allows for validation of fuel sensor data based on the generator's parameters.
Third-party API integration to receive the loadshedding schedule, as specified in the 'Loadshedding Schedule' section above.
Automated Generator Control
Galooli has implemented a remote mechanism to start the generator a few minutes before an expected outage, thereby preventing downtime and unnecessary site visits.
The mechanism is implemented as an automation script that users can save in their account and customize further based on their preferences. The automation will switch the generator's operating mode to manual and send a start command to the generator X minutes before the scheduled load shedding time. After the outage begins, it will switch the generator back to auto mode Y minutes later.
Automation Configuration
The automation should be executed every 2 minutes.
The user can configure the number of minutes before the outage, and the number of minutes after the outages have begun, that will affect the commands timing.
If commands are sent to the generator but there is no change in the generator parameters (working mode or running status has not been changed), the script will attempt another command. The automation allows for up to 5 retries before stopping further commands to the unit. Users have the option to configure the number of retries as per their preference.
Required Settings
The unit must be equipped with a compatible generator panel that Galooli has integrated with.
Third-party API integration to receive the loadshedding schedule, as specified in the 'Loadshedding Schedule' section above.