HOW TO LEVERAGE SMART METER EVENTS TO DECREASE CUSTOMER OUTAGE TIMES
image credit: Leon Maruša - Elektro Celje
- Sep 21, 2020 10:33 am GMTSep 20, 2020 10:04 am GMT
- 406 views
Electricity is one of the most important commodities in our daily lives, yet we give so little thought to it. We’re used to just plug in the devices and go on with our daily routine, but what about when the lights go out?
Luckily these events have decreased significantly in Europe in the recent years. A study conducted by CEER (Council of Europeean Energy Regulators) in 2018 shows that SAIDI and SAIFI indices have decreased in the recent years, particularly due to the investments in power grid infrastructure and leveraging new OT technologies which enable more secure power delivery.
Figure 1: Unplanned SAIDI with exceptional events (i. e. icing, storms, wildfires…) .
As today’s consumers expect to have a sustainable power supply with minimum outage time it’s up to the DSOs to deliver that, because they are the final link between the end consumer and produced electricity in the electric energy value chain.
In Elektro Celje (Slovenian DSO) we have started to think on how to additionally improve power delivery to our customers. Our grid is well maintained, and grid reinforcements are planned ahead where we expect to see increased loads, but what about power restoration once the outage already happens?
The power could be out because something happened on MV gird or in the MV/LV transformer station or on the LV feeders in which cases more consumers are out of power. Due to that fact the power can sometimes be quickly restored. For example, if relay protection on MV feeder has tripped, a SCADA operator can quickly restore power by remotely re-closing the circuit breaker (if there is no permanent failure). For other events that happen from MV/LV transformer station downstream, the cause for power outages are most often burned fuses, either at the consumer side, at LV feeder or in transformer station bay, if such an event happens we get a call from consumers that they are out of power, but we still don’t know where the fuse was burned.
To tackle this issue, we have decided to leverage smart meter technology. Currently our grid has around 90% smart meter coverage, which is expected to be completed in a few years. Besides providing accurate billing information and recording load, voltage and current profiles smart meters also log additional information in so called event registers. In here everything that happens on the LV grid where consumers are connected is recorded, from overvoltages, wrong phase sequences, phase leakages and most importantly power outages. Now one important note here is that right now we get smart meter events with 1-day delay (e. g. today we will get events for yesterday), since most of our smart meters communicate on PLC technology they send events to the local concentrator, which sends them in our database once a day. PLC technology is not particularly suitable for real-time communications especially on grids where there is a lot of harmonic distortions. But despite that we still wanted to design some sort of analytical methodology that would prepare us for the day when smart meters will communicate in real time.
To get a better understanding of what caused the smart meters to log power outages we had to look at the broader picture. In the process we have developed a Python application which is the core of our methodology and uses information about power outage calls recorded in our call center together with logged smart meter events. When we get a call, some information is stored in the center such as call time, what is the issue, customer ID and more. The application then determines where the customer is located in the LV grid (what is the customer’s upstream MV/LV station and LV feeder) from our CIS (Customer Information System). Now that we know the location and time of the call, the application will pull all smart meter events for the affected customer from our AMI (Advanced Metering Infrastructure) database for the last 24 hours from the call. We do this since the call can sometimes be made long after the power outage has happened, for example if power went out during the night and we got a call in the morning. From the events the app will filter only those that have power outage information (i. e. Power Down, Missing Voltage on Phase X). The app than looks at the timestamps of these events and for those timestamps, it also pulls the events from other smart meters connected on that transformer station. A note here is that the app will actually pull events for all the mentioned timestamps +/- 5 minutes, since smart meters can sometimes have slightly misaligned clocks. Figure 2 shows an example for the described procedure.
Figure 2: Determining smart meter events that could caused the power outage.
Now the app has collected all the possible events that could have caused the power outage and it knows on which LV feeder each smart meter is connected. From this information the app determines how many smart meters have been affected by an outage. It calculates the percentage of affected smart meters on each feeder and on the station level. If there are feeders that have 100% of affected meters we can say for sure that the fuse was burned at the LV feeder. If the affection rate is 100% on the station level than the fuse was burned in the transformer bay, and if the percentage is lower and you have only 1 smart meter affected the fuse was probably burned at the consumer side. Figures 3, 4 and 5 show such cases.
Figure 3: Calculated outage percentages for fuse burned at consumer side.
Figure 4: Calculated outage percentages for fuse burned at LV feeder.
Figure 5: Calculated outage percentages for fuse burned at transformer bay.
Now that the application has given us the results we can more accurately determine where the fuse was burned, meaning a field worker can be directly routed to the location of probable failure, which results in faster restoration of power. This is true especially in highly rural areas where consumer can be on one location, transformer station on the other location far away and the transportation to both locations takes a long time and is very difficult.
Now of course this is not fullproof method, here are some exceptions and limitations:
- If consumer’s smart meter logged multiple outage events we don’t know exactly which one caused the call, for example fuse can be burned on only one of the phases on LV feeder, we get the call and then fuse is also burned on another phase. But in any case, we do get information that multiple smart meters have detected multiple outages many times, and that is an indication that something is happening on the feeder level.
- If the consumer which is calling doesn’t have a smart meter, we can’t determine the timestamps of outages in the last 24 hours.
- If some smart meters in the gird have internal malfunctions and won’t log their outages properly, they won’t show in the analysis as the affected meters.
- If smart meter clocks are not synchronized, they won’t timestamp the outage events properly. This can be solved with frequent time synchronization from the concentrator.
- Since most smart meters use PLC communication, they are sometimes unreachable for event pull due to harmonic distortions in the PLC band. In this case those meters must not be considered in the analysis. This can be problematic if large number of smart meters are affected.
- There are consumers connected on the transformer station that have an old analogue meter, they also must be excluded from the analysis.
- You can have a consumer that have their own LV feeder or even their own transformer station in this case affected smart meter percentage is 100 % on every level. But generally, this is not the problem since you still know exactly which user was affected.
As mentioned, we get smart meter events with 1 day delay in our database. With the developed application we did ex-post analysis for the customer calls recorded in the year 2020 so far. Luckily when doing this, we already knew what the final causes of the outages were (i. e. where the fuses were burned), so we could compare the results. It turned out that the methodology is quite accurate as it showed around 30 mis-determined outages compared to total of around 1.500 calls we received.
We’re confident that in the future this will enable us to shorten the time to restore power back to our customers. Elektro Celje is currently in the final stages of ADMS (Advanced Distribution Management System) implementation. A part of ADMS connectivity is also integration with our call center and our AMI system, which is taking place as we speak. Among other things ADMS has a functionality to ping smart meters in real time and get back responses of which meter is powered, and which is not. Information like this can be used to optimally dispatch field crew to the most probable outage location. The ping functionality can of course still represent an issue sometimes, due to unstable PLC communication, but we’re working to tackle this issue also, and of course in the future when smart meters will enable cheaper P2P connectivity their real-time communication will also be possible.
 CEER Benchmarking Report 6.1 on the Continuity of Electricity and Gas Supply, 2018 [link]