From Triggers to Training: Automating Network Design in Three Levels

If you ever worked in the electric distribution field, you’ve probably experienced the disconnect between engineering and GIS. One way this shows up is when new additions need to be made to the network. Usually the design is done in CAD, and then handed off to a GIS technician. The technician overlays this on the network and digitizes the data on the GIS. Somewhere in that transition, electrical errors often enter silently (an A phase transformer gets added to a B Phase line) and it’s not caught until later. The whole pipeline: design, digitize, validate, cost is slower than it needs to be.

We built BQ, an extension for Livewire (our power delivery modelling platform), to help shrink this pipeline. With BQ, distribution engineers can build out new infrastructure directly in QGIS (and soon on the web directly at lvwr.io). As an extension of Livewire, electric smarts are built in, so errors that may have crept into the GIS during the CAD to GIS pipeline will be flagged immediately. Once the design is complete a Bill of Quantities is generated and cost calculated. This allows for a very fast turn around with respect to the usual downstream client (normally a housing developer).

Since the stated goal is efficiency, we use a mix of Intelligent Automation and Artificial Intelligence to make workflows seamless. I’ll discuss three levels of how we increase the efficiency of workflows and decrease the turnaround time for the downstream client.

Level 0 - Intelligent Automations I

Distribution engineers probably don’t need to know that there are separate tables in the database for pole mounted and pad mounted transformer banks. They probably don’t care that jumpers are in a different table from overhead primary lines. We use postgresql views to hide these facts. We also use Instead of triggers with lots of PostGIS functions to do the editing. Here is a simple example. Electric lines are attached to poles (unless they are underground). Here is the workflow for creating an overhead line segment before the first set of Intelligent Automations:

1. Start editing.
2. Select “Pole” layer, add poles as required.
3. Select “Overhead Primaryline” layer, draw line with each vertex snapped to a pole.
4. Stop editing.

Let’s create a view named “Residential Overhead Primary” and a similarly named trigger function. We will drop them both in a schema named “Quick Add”. With this first level of Intelligent Automation, here is the new workflow:

1. Start editing.
2. Select “Residential Overhead Primary” layer. Draw a line, with vertex at start point, end point and any places where direction changes significantly.
3. Stop editing.

No longer does the engineer have to draw in each pole manually, we know the general standards of pole spans and we understand sagging in electric lines. The trigger function accounts for this and places poles at suitable locations. Because PostGIS has functions for almost every imaginable thing, the trigger function is relatively simple: A little st_lineinterpolatepoint here, a little st_addpoint there, and voila!! An entire overhead primary line section is generated. The engineer just needs to review the pole locations for any anomalies. For example, did any poles fall in the middle of a road, and move them if needed. And if you read the first blog post, you know that we can automate the moving of lines when we move a pole, so that too is made easy.

In a similar vein, when adding a transformer to a pole, we need to connect jumpers from the transformer to the existing primary line. Instead of having that be a manual process (which can be very tedious especially if you are striving for a true digital twin and are using three dimensional vectors) create a view named “Pole Mounted Transformer - 25KVA” and an associated trigger function. Add them to the “Quick Add” schema and you are off to the races. When a point is added the trigger function checks that there is a pole, checks that the pole has a primary line and then adds both the transformer and jumper. We can create one view for each specific type of object and thus reduce the usual post digitizing flow of editing attributes by selecting the “Hide form on Add Feature” option for that layer. Doing this makes your editing workflow as smooth as coconut oil.

Level 1 - Intelligent Automations II

Let’s step it up a notch. Level 0 made creating individual units easy…what if we could create the whole end product? The distribution engineer knows a few things…well…they know quite a bit, they are engineers!!! But in the context of designing an addition to the network, they know that on average, every household will use some amount of energy and that the number of households on any given transformer has a limit. Generally the bigger the house, the greater the energy demand. They also need to factor in conductor size in some instances especially if the new addition is covering a large area. When it comes to a new housing development, the developer usually provides a plan of the area including street centerline and lot boundaries, in some cases, the building footprints also exist.

So given that we may have the building footprint, we can derive the area of the proposed abode and thus the potential electric demand. We have the street centerline, so we can get a sense of where to place poles. With these two inputs, and we can create a function of about 200 lines of code to generate an entire addition to the network given a polygon drawn by the engineer on a single road. By entire addition I mean poles, primary lines, transformers, secondary lines, service wires and meter locations. We can even give it further smarts to check in the database of procurement or stores to see which transformers/poles etc are in stock so that we are not creating designs that can’t be implemented in the near term. So the workflow here becomes:

1. Start editing.
2. Select “Generate lateral” layer and draw a polygon encompassing the proposed road and its building footprints.
3. Stop editing.

The trigger function will generate an entire lateral that the engineer can review for any errors or anomalies.

Level 2 - Artificial Intelligence

That 200 line function works great for a single road, especially if it has minimal curves. But try to feed it a complex layout and the output won’t be pretty. We could add more lines of code to handle a multitude of cases, but at some point that in itself becomes a complexity. We already have an existing network, why not train a model on that?

I’m generally skeptical of slapping the AI label on things that don’t need it, and truth be told, this is arguably more ML than AI, but I reckon that network design at scale is one place where this moniker is applicable.

That is what we have been doing and the results are promising. There is still some way to go to fine tune everything. The workflow is the same as Level 1, in that there will be a single view and a trigger function, but the polygon in this case can span multiple roads and hundreds of building footprints.

It’s very different from annotating imagery for object detection. Most people can be taught to identify a transformer or streetlight and draw a polygon around it to feed to yolo/tensorflow etc. The outputs can be easily flagged as good or no-good. When it comes to reviewing a generated network design, you really need an engineer who understands the distribution grid (phasing, loading and standards compliance) to review the output from our model and see if it stands up to scrutiny. Given that we are trying to use this for larger areas, even the review itself becomes a mini-project. That feedback loop to see if we are on the right path may be measured in hours instead of minutes.

There are however, lots of things to consider with regards to the training data for which the answers are not readily obvious. These caveats need to be understood before trusting the output.

The network was not built in a day and is not a static artifact. It is essentially a record of decisions made over time with constraints that may have changed over time. Standards have also evolved, there most likely will be robust sections of the network built 3 decades ago. These areas represent what the standards were back then. Training on that data will encode those assumptions that no longer hold…do we go ahead and train and have the engineer adjust during review or ignore those areas totally?

The data we are working with is in a very flat area, we haven’t had to account for terrain or other topographical oddities, and certainly not soil types or slopes. This doesn’t just affect pole placement but also sag calculations and even how crews access the proposed infrastructure.

Similarly, assets that were readily available and cost effective in the past may not be the same now. You may see a section dominated by 50kva transformers, but now 50KVA transformers may be harder to source. If current stock or pricing factors favour different transformer sizes, the model will not account for that. Currently, as shown in the Level 1 example, we can consult a database for pricing and stock amounts to aid in the design process. The level 2 implementation would need to factor this in.

When looking at the demand side, the proliferation of solar and residential battery storage will play a role in predicted peak demand. Load profiles and peak demand have a direct correlation on conductor sizing. Training on decade old data could lead to designs that are oversized for the reality of the future.

Where to from here

This is still the early days and the reality is that this needs to be trained on a per utility basis. For now, level 1 handles most real world jobs well. But the trajectory is clear: the same engineer who added each pole one click at a time, now draws a single polygon and reviews the output. AI will make that polygon bigger.

P.S. Fittingly, the header image was AI-generated.