Need ideas: Selectively triggering ADMS integration for "significant" network changes

[rpepato_bizpoke]

Hi team,

We have a customer (electric domain) who is planning to use ExportSubnetwork to feed their ADMS, and they've raised a good point about integration frequency.

The customer is using a single-tier configuration, with feeders extending from the breaker terminal to the service delivery points.

They understand that a subnetwork gets marked as 'Dirty' (requiring validation) after topology validation, even for minor changes (like connecting a single service point). However, they only want the ADMS to be synchronized after major network changes or a batch of minor changes (e.g., every 5 new LV residential customers). They specifically do not want to feed the ADMS for every minor edit.

Since the "Dirty" status is automatically triggered, and that is basically the initial condition of "something has changed - we need to clean the subnetwork and inform ADMS about the change", I'm wondering if there's a way to add a custom trigger/condition for the process of marking the network as Dirty without major development/customization work.

Does anyone have experience or ideas on how to handle this export request conditionally?

Thanks for your insights!

[gis_KIWI4 · Accepted solution]

@rpepato_bizpoke - This is a good question, one that we have been pondering over ourselves.

You are right in saying that every small change will mark the subnetwork dirty and if you use that as a trigger to start updates to ADMS then every single small change will be passed through. I do not believe there is a way to change this behavior, it's a foundational piece of the UN functionality.

Hypothetically, If you do not want that system marking the subnetwork dirty at every small change then you can set that in the subnetwork definition by unchecking the option "Manage IsDirty". It then becomes your responsibility to know when subnetworks are “dirty” and when to update them. In my opinion, this is not a great outcome and would advise against it.

Coming back to your problem statement. 
If we unpick that you need to capture cumulative changes and only if it exceeds the update threshold (number of updates, additions, deletes) then then trigger the ADMS update process. This needs to be handled by an external mechanism. 

I would rely on ExportSubnetwork at a historic moment to export the network elements and compare them to the current state and decide if the ADMS should be updated.

==========================================================================

Option 1 - Use the Dirty flag and subsequent Network Validation as trigger to ExportSubnetwork at current state and also ExportSubnetwork when the LASTACKEXPORTSUBNETWORK was set. Compare the two for changes and make a decision. 

Option 2  - Set a time scheduled trigger. If LASTUPDATESUBNETWORK is greater than LASTACKEXPORTSUBNETWORK then ExportSubnetwork at current state and also ExportSubnetwork when the LASTACKEXPORTSUBNETWORK was set. Compare the two for changes and make a decision. 

Option 3 - This option assumes capability to export model from the ADMS frequently. Comparing the subnetwork export from GIS to model from ADMS might be the easiest one on paper but this is ADMS dependent and the way it's architected. 

I must say these are simplistic patterns and will need a lot more thinking once you start incorporating business rules in it. 

Some considerations - 

Example 1 - 

---

They understand that a subnetwork gets marked as 'Dirty' (requiring validation) after topology validation, even for minor changes (like connecting a single service point). However, they only want the ADMS to be synchronized after major network changes or a batch of minor changes (e.g., every 5 new LV residential customers). They specifically do not want to feed the ADMS for every minor edit.

---

Are we talking about 5 LV connections across the network or on one feeder?
If it's per feeder then what happens when there is only one new LV connection on that feeder for months?
If it's across the network then you need to merge all results do a network wide comparison. 

Example 2 - 

Updates to non-network attributes like ratings, conductor type do not trigger dirty areas or validation. How do you account for that? These are attributes that your ADMS will be interested in.

We are contemplating the approach below. 
Overnight updates with the ability to trigger a sync if it cannot wait for the overnight update. 

Hope this helps 🙂 

[robertopepato_bizpoke]

Great insights, thank you for sharing @gis_KIWI4.

This is certainly helpful and will aid in determining the best alternative for the customer. We were already concerned about updates on attributes that wouldn't trigger a dirty subnetwork (but should trigger an ADMS integration), and some of the ideas you shared were helpful in our internal discussions. 

Thank you for collaborating.

Roberto

[RobertKrisher]

Another option is to consider using the Differences API on the version management to get all the edits that have been applied to a version (or default) between two moments in time. This approach allows you to see all changes made to features, including changes made to non-network attributes. You will need to do some additional work to identify which subnetworks were affected (likely relying on the subnetwork name field).

You could run this process every night to identify all the features that were modified (and their corresponding subnetworks) then determine whether or not to extract a subnetwork that night based on some threshold you set up.

As @gis_KIWI4 suggested you will likely want to have a business rule that says that even if a subnetwork hasn't had any significant change, you still must extract all dirty subnetworks within x days of it becoming dirty (using the logic outlined in option 2 above).

I have also seen option 3 implemented, with some success, since it does a comparison of the extracts from the last circuit imported to the ADMS and the latest circuit. This is better than trying to detect edits on the GIS side, since that requires a detailed understanding of how information from the GIS is mapped to the elements in the ADMS.

[robertopepato_bizpoke]

This all makes sense to me. We will study the options we have and certainly consider your suggestions and those of @gis_KIWI4 and hopefully come up with a viable alternative.

Thank you for collaborating!

Roberto.