Wenn Sie das Migrate To Utility Network-Werkzeug verwendet haben, um Ihre elektrischen Daten in ein Versorgungsnetz zu migrieren, fragen Sie sich wahrscheinlich: „Welche Konfiguration muss ich an diesem Versorgungsnetz vornehmen, damit es sich wie ein elektrisches Verteilnetz verhält?“
Diese Netze modellieren den Weg, den der Strom von einem Mittelspannungsschalter in einer Umspannstation zu den Niederspannungskunden im Netz nimmt. Analyse-Workflows für diese Datensätze reichen von der Betrachtung der Last am Leistungsschalter oder Transformator bis hin zur Sicherstellung, dass Schutzausrüstung richtig dimensioniert ist, um potenzielle Fehler im System zu bewältigen.
In diesem Artikel zeigen wir Ihnen, wie Sie ein mit dem Migrationstool erstelltes Modell erweitern können, um einige dieser grundlegenden Workflows zu unterstützen.
Hinweis: Bevor Sie Konfigurationsänderungen an Ihrem Netz vornehmen, sollten Sie sicherstellen, dass alle entdeckten Topologiefehler behoben sind, da Sie in Bereichen Ihres Netzes mit Fehlern keine Traces durchführen können. Das Beheben von Topologiefehlern nachdem Sie Ihre Netzwerktopologie aktiviert oder Ihr Versorgungsnetz bereitgestellt haben, schränkt Ihre Möglichkeiten ein, Werkzeuge wie "Apply Error Resolutions" zu verwenden, um Fehler automatisch zu korrigieren.
Konnektivitäts-Trace
Die erste und grundlegendste Art von Trace im Versorgungsnetz ist ein verbundener Trace. Um einen verbundenen Trace durchzuführen, fügen Sie einen Startpunkt auf einem Netzobjekt zur Karte hinzu und führen dann einen verbundenen Trace aus. Dieser Trace-Typ gibt alle Objekte zurück, die vom angegebenen Standort aus basierend auf der für den Trace bereitgestellten Konfiguration durchquerbar sind. Ein verbundener Trace ohne zusätzliche Konfiguration gibt wahrscheinlich Ihren gesamten Datensatz zurück, wie unten zu sehen ist.
Während dies ein praktischer Test ist, um nicht verbundene Objekte zu identifizieren, würde ein realistischerer Trace den Status eines Geräts (offen/geschlossen), die elektrische Phasung und ob ein Objekt in Betrieb oder vorgeschlagen ist, berücksichtigen. Dies kann simuliert werden, indem manuell Barrieren zum Trace hinzugefügt werden, um diese Bedingungen darzustellen. Die empfohlene Methode ist jedoch die Definition von Bedingungsbarrieren für Ihren Trace.
Wenn Sie das Migrate To Utility Network verwenden, um Ihr Netz zu erstellen, sehen Sie, dass jedes Objekt ein aktiviertes Feld hat. Wenn Sie Daten aus einem geometrischen Netz migriert haben, ist dieses Feld mit einem Wert gefüllt, der angibt, ob es als Barriere fungieren soll. Im folgenden Beispiel führen wir einen Trace mit Daten aus einem geometrischen Netz durch und behandeln alle deaktivierten Objekte (offene Geräte) als Barrieren.
Sie können sehen, dass dieser Trace im Gegensatz zum ersten Trace alle Objekte zurückgibt, die elektrisch mit dem Objekt verbunden sind, das mit dem Startpunkt verknüpft ist. Die Bewertung dieser Bedingungsbarrieren während eines Traces ermöglicht es uns, das Ausmaß des Stromkreises vom Startort aus zu entdecken.
Obwohl es völlig akzeptabel ist, das aktivierte Feld als Bedingungsbarriere zu verwenden, sind Sie möglicherweise nicht daran gewöhnt, ein aktiviertes Feld zu pflegen und möchten stattdessen ein anderes Feld verwenden, um den Status Ihres schaltbaren Geräts zu verwalten. Dies wird im nächsten Abschnitt behandelt.
Gerätestatus
Um Attribute Ihrer Objekte in Traces oder Analysen einzubeziehen, erstellen Sie ein Netzwerkattribut, damit das Versorgungsnetz darauf zugreifen kann. Lassen Sie uns ein Beispiel durchgehen, wie man ein Netzwerkattribut "Gerätestatus" erstellt, das zur Steuerung von Traces verwendet werden kann.
Der erste Schritt besteht darin, das Feld aus unseren Daten zu identifizieren, das wir verwenden möchten. In diesem Fall verwenden wir das Feld NormalOperatingStatus in unserer Gerätekategorie. Dies ist ein Short-Integer-Feld mit einer Domäne, die angibt, ob das Gerät offen (1) oder geschlossen (0) ist.
Nachdem wir das Feld, den Datentyp und die Domäne identifiziert haben, können wir das Netzwerkattribut erstellen. Zuerst fügen wir dem Versorgungsnetz ein Netzwerkattribut hinzu, das dem Datentyp unseres Feldes entspricht. Da dieses Feld in fast allen unseren Traces verwendet wird, möchten wir es inline speichern, damit es besser funktioniert.
Lesen Sie das Online-Hilfethema über Netzwerkattribute für weitere Informationen über deren Verwendung und Auswirkungen auf das Verhalten Ihres Versorgungsnetzes.
Nachdem das Netzwerkattribut zum Versorgungsnetz hinzugefügt wurde, besteht der nächste Schritt darin auszuwählen, welche Felder mit dem Attribut verknüpft werden sollen. Es ist nicht erforderlich, dass ein Netzwerkattribut mit jeder Klasse in unserem Netz verknüpft wird; jedoch kann jedes Netzwerkattribut nur mit einem einzelnen Feld pro Klasse verknüpft werden. Wenn wir mehrere Statusfelder haben, können wir nur ein einzelnes Feld auswählen, um es mit diesem Netzwerkattribut zu verknüpfen.
Nachdem wir dieses Feld mit unserem Netzwerkattribut verknüpft haben, können wir es verwenden, um eine Bedingungsbarriere für unsere Traces zu definieren.
Jedes Mal wenn ein Benutzer ein Feld ändert, das mit einem Netzwerkattribut verknüpft ist, erzeugt das Objekt einen Dirty-Bereich (zu überprüfender Bereich), der validiert werden muss, um das Netz mit dem neuen Wert zu aktualisieren. Ein Beispiel dafür sehen wir unten: Wir tracen durch eine geschlossene Sicherung (1) und nachdem der Gerätestatus der Sicherung auf offen gesetzt und die Änderung validiert wurde (2), stoppt der Trace an der neu geöffneten Sicherung.
Diese Strategie funktioniert gut bei einem einzelnen Statusfeld. Aber was ist wenn Sie für jede Phase ein anderes Statusfeld pflegen? Das besprechen wir im nächsten Abschnitt.
Mehrere Statusfelder
Im vorherigen Abschnitt haben Sie gesehen, wie man ein einzelnes Feld verwendet, um die offene/geschlossene Position eines Geräts zu modellieren. Wenn Sie jedoch Felder haben, die es erlauben jeder Phase eines Geräts einen separaten Status zuzuweisen, müssen Sie eine von mehreren Lösungen in Betracht ziehen.
Es ist üblich bei elektrischen Modellen drei separate Felder zur Verwaltung des offenen/geschlossenen Status eines Geräts zu verwenden. Jedes dieser Felder entspricht einer anderen Phase des Stroms (A-, B- oder C-Phase), und dieses Modell erlaubt es dem Netz den Status jeder Phase eines Geräts separat zu modellieren.
Beim Einsatz des Migrate To Utility Network-Werkzeugs muss ein Gerät als gemeinsam betätigt behandelt werden. Das bedeutet: Das Gerät wird entweder als offen oder geschlossen betrachtet; es kann keinen gemischten Status haben. Wenn Sie Geräte mit gemischtem Status modellieren müssen, müssen Sie diese entweder als separate Geräte modellieren oder Ihre Daten in die Electric Utility Network Foundation. migrieren.
Es gibt mehrere Möglichkeiten dies mit dem Migrate To Utility Network-Werkzeug umzusetzen. Der einfachste Weg ist weiterhin das aktivierte Feld (oder die Erstellung eines einzelnen Gerätestatusfeldes) zur Steuerung des Tracings zu verwenden und dieses Feld mit Ihren bestehenden Statuswerten zu befüllen. Dazu müssen Sie einige Dinge wissen:
- Welche Felder verwenden Sie zur Darstellung des Status jeder Phase eines Geräts?
- Welche Werte repräsentieren offen und geschlossen?
- Welches Feld verwenden Sie zur Darstellung der Phasung eines Geräts in Ihrem Netz?
- Welche Werte im Phasenfeld gelten für jedes Statusfeld?
Mit diesen Informationen können Sie das Werkzeug "Select By Attributes" verwenden um alle Geräte auszuwählen die offen oder geschlossen sein sollten.
Sehen wir uns dazu folgendes Beispiel an.
- Welche Felder verwenden Sie zur Darstellung des Status jeder Phase eines Geräts?
- StatusValueOpen0Closed1PhasingCodePhaseValueA4B2C1AB6AC5BC3ABC7Mit diesen Informationen können wir drei Abfragen schreiben:QueryExpressionGeräte die offen sein sollten (Enabled=False)ENABLED=1 UND(((POSA=0 UND PHASINGCODE=4)ODER (POSB=0 UND PHASINGCODE=2)ODER (POSC=0 UND PHASINGCODE=1))ODER(((POSA=0 ODER POSB=0) UND PHASINGCODE=6)ODER ((POSA=0 ODER POSC=0) UND PHASINGCODE=5)ODER ((POSB=0 ODER POSC=0) UND PHASINGCODE=3))ODER((POSA=0 ODER POSB=0 ODER POSC=0) UND PHASINGCODE=7))Geräte die geschlossen sein sollten (Enabled=True)ENABLED=0 UND(((POSA=1 UND PHASINGCODE=4)ODER (POSB=1 UND PHASINGCODE=2)ODER (POSC=1 UND PHASINGCODE=1))ODER(((POSA=1 ODER POSB=1) UND PHASINGCODE=6)ODER ((POSA=1 ODER POSC=1) UND PHASINGCODE=5)ODER ((POSB=1 ODER POSC=1) UND PHASINGCODE=3))ODER((POSA=1 ODER POSB=1 ODER POSC=1) UND PHASINGCODE=7))Eine Abfrage zur Identifikation von Geräten mit gemischtem Status(PHASINGCODE=6 UND ((POSA=0 UND POSB=1) ODER (POSA=1 UND POSB=0)))ODER (PHASINGCODE=5 UND ((POSA=0 UND POSC=1) ODER (POSA=1 UND POSC=0)))ODER (PHASINGCODE=3 UND ((POSB=0 UND POSC=1) ODER (POSB=1 UND POSC=0)))ODER (PHASINGCODE=7 UND ((POSA=0 UND POSB=0 UND POSC=1) ODER (POSA=0 UND POSB=1 UND POSC=0) ODER (POSA=0 UND POSB=1 UND POSC=1) ODER (POSA=1 UND POSB=0 UND POSC=0) ODER (POSA=1 UND POSB=0 UND POSC=1)))Sehen wir uns an wie diese Technik auf unsere Daten angewendet wird.Führen Sie zuerst die Abfrage aus um Objekte mit gemischtem Status in Ihrem Netz zu identifizieren. Wenn diese Abfrage Objekte findet müssen Sie überlegen wie Geräte mit gemischtem Status zukünftig unterstützt werden sollen. Falls akzeptabel nutzen Sie ein einzelnes Statusfeld und verwalten mehrere Felder entsprechend. Andernfalls müssen andere Optionen erwogen werden wie z.B. die Electric Utility Network Foundation.Nachdem wählen Sie alle Geräte im Netz aus die offen sein sollten (Enabled=False).
- Welche Werte repräsentieren offen und geschlossen?
- Welches Feld verwenden Sie zur Darstellung der Phasung eines Geräts in Ihrem Netz?
- Welche Werte im Phasenfeld gelten für jedes Statusfeld?
Setzen Sie dann bei diesen Objekten das Enabled-Feld auf Deaktiviert/Offen.
Hinweis: Bei großen Datensätzen sollten Sie erwägen die Netzwerktopologie und alle Attributregeln auf der Geräteebene vor dem Anwenden dieser Änderungen zu deaktivieren.
Nachdem Sie die Änderungen angewendet haben entstehen Dirty-Bereiche in Ihrem Netz die validiert werden müssen. Bevor Sie Ihre Änderungen validieren wiederholen Sie diesen Vorgang um alle Geräte zu identifizieren die aktiviert/geschlossen sein sollten. Dies liegt daran dass das Enabled-Feld ein Netzwerkattribut ist und Änderungen daran mittels des Werkzeugs "Validate Network Topology" validiert werden müssen. Sobald alle Dirty-Bereiche validiert sind oder Ihre Netzwerktopologie wieder aktiviert wurde respektieren Ihre Traces nun diesen neuen Wert.
Nachdem wir nun mehrere Techniken zur Modellierung des Gerätestatus in einem elektrischen Netz besprochen haben sehen wir uns an wie das Versorgungsnetz Stromkreise modelliert und warum es diese als Subnetze bezeichnet.
Elektrische Phasung
Die Verwaltung der energisierten Phasen ist eine wichtige Anforderung für die Nachverfolgung und Analyse vieler elektrischer Kunden. Wenn Sie die Phasenzuordnung jeder Leitung und jedes Geräts in Ihrem System verfolgen, sollten Sie diese Schritte befolgen, um Ihre Phaseninformationen in Ihr Netzwerk einzubinden, damit Sie sie während der Nachverfolgung und Analyse verwenden können.
Um diese Konfiguration durchzuführen, müssen Sie die folgenden Informationen identifizieren:
- Welche Klassen und Felder enthalten Phasenzuordnungen?
- Stellen Sie die Phasenzuordnung mit einem ganzzahligen Wert dar?
- Welches Domain verwenden Sie zur Darstellung der Phasenzuordnung?
Mit diesen Informationen können Sie ein Netzwerkattribut erstellen und zuweisen, das zur Verfolgung der Phasenzuordnung in Ihrem Netzwerk verwendet wird. Das Erste, was Sie benötigen, ist ein codierter Wertbereich, um alle Kombinationen von Phasen in Ihrem System darzustellen. Da das utility network die Phasenzuordnung mit bitweisen Operationen berechnet und propagiert, muss das Feld eine Ganzzahl sein, wenn Sie es zur Verwaltung der Phase verwenden möchten. Wenn es Ihnen nur um Berichtsziele geht und nicht um Qualitätssicherung oder Analysezwecke, können Sie es mit einem nicht-ganzzahligen Wert darstellen. Für sowohl die grundlegenden als auch die erweiterten Artikel verwenden wir eine Ganzzahl mit einem codierten Wertbereich, der für bitweise Berechnungen ausgelegt ist, wie unten gezeigt, um die Phasenzuordnung darzustellen. Mehr darüber, wie das utility network Attribute propagiert, erfahren Sie im Attributpropagation und Attributsubstitution im Subnetzwerkmanagement-Artikel.
Der nächste Schritt besteht darin sicherzustellen, dass Ihre Geräte-, Knoten- und Leitungs-Klasse jeweils ein einzelnes Feld hat, das diesen Domain verwendet, um die Phase zu verfolgen. Sobald Sie dies getan haben, sind Sie bereit, Ihr utility network so zu konfigurieren, dass dieses Feld verwendet wird.
Zuerst fügen Sie Ihrem Netzwerk mit dem Werkzeug Add Network Attribute ein Netzwerkattribut hinzu. Betrachten Sie diese Umschreibung: Wie bei vielen Verwaltungswerkzeugen für utility network ist es notwendig, Ihre Netzwerktopologie zu deaktivieren, bevor Sie das Werkzeug ausführen können. Wenn Sie das Attribut als in-line markieren, müssen Sie sicherstellen, dass Sie den oben identifizierten Datentyp und Domain auswählen.
Nachdem Sie das Netzwerkattribut zu Ihrem utility network hinzugefügt haben, müssen Sie dem utility network mitteilen, welche Klassen und Felder diesem Netzwerkattribut entsprechen. Verwenden Sie dazu für jede Klasse in Ihrem Netzwerk, die Phase verwaltet, das Werkzeug Set Network Attribute. Dies umfasst normalerweise die Klassen Electric Device, Electric Junction und Electric Line im Netzwerk.
Nachdem dies abgeschlossen ist, können Sie dieses Feld beim Ausführen von Nachverfolgungen in Ihrem Netzwerk verwenden. Die einfachste Möglichkeit, dieses Attribut zu nutzen, besteht darin, es als Filter oder Barriere zu verwenden, wenn Sie Ihre Netzwerkelemente nachverfolgen. Unten sehen Sie ein Beispiel, das alle Elemente zurückgibt, die eine A-Phase aufweisen.
Hinweis: Wenn Sie das Phasenfeld auf Feldebene für das entsprechende Netzwerkattribut Ihrer Klassen zuweisen, sehen Sie ein Dropdown-Menü anstelle der manuellen Eingabe einer Zahl.
Dies ist ein praktischer Berichtmechanismus; wenn wir jedoch möchten, dass das Subnetzwerk die Phasenzuordnung bei der Bestimmung der energisierten Elemente berücksichtigt, müssen wir zusätzliche Konfigurationen vornehmen. Dieses Thema wird im Artikel zu erweiterten Konfigurationen behandelt.
Erstellen eines Subnetzwerks
Die meisten elektrischen Verteilkreise beginnen an einem Leistungsschalter oder Wiedereinschalter in einer Station. Alles stromabwärts von diesem Leistungsschalter gehört zum selben Stromkreis. In der Terminologie des utility network ist der Stromkreis ein Subnetzwerk, da es sich um eine eigenständige Teilmenge des Netzwerks handelt, die für analytische Zwecke wichtig ist. Die Geräte, die als Quellen/Senken für ein Subnetzwerk fungieren, werden als Subnetzwerk-Controller bezeichnet. Im Fall der meisten elektrischen Netzwerke ist der Leistungsschalter (oder Wiedereinschalter) ein Subnetzwerk-Controller und die meisten Stromkreise haben einen einzelnen Subnetzwerk-Controller. Auf höherer Ebene ist das Verteilungs-Domain-Netzwerk quellbasiert. Das bedeutet, dass der Leistungsschalter die Flussquelle für das Subnetzwerk ist und stromaufwärts aller Elemente im Subnetzwerk liegt.
Wir können den Umfang eines Stromkreises bestimmen, indem wir eine verbundene Nachverfolgung mit Barrieren für deaktivierte/geöffnete Elemente und Leistungsschalter durchführen. Unten sind die Ergebnisse einer Nachverfolgung mit dieser Konfiguration dargestellt, ausgehend von einem Leistungsschalter:
Bis zu diesem Punkt wurden alle durchgeführten Nachverfolgungen als Konnektivitätsnachverfolgungen ausgeführt. Das liegt daran, dass zum Ausführen einer stromaufwärts-, stromabwärts- oder Isolationsnachverfolgung Subnetzwerke definiert sein müssen. Es gibt zwei Möglichkeiten, Subnetzwerk-Controller im utility network zu erstellen. Die erste besteht darin, den Modify Subnetwork Controller-Bereich zu verwenden, um ein Element auszuwählen und manuell ein Subnetzwerk zu erstellen.
Zurück zu unserem ursprünglichen Beispiel: Da wir wissen, dass Leistungsschalter unsere Stromkreise steuern, hätten wir im Werkzeug Migrate To Utility Network für diese Zuordnung die Option „Is Controller“ aktivieren sollen. Dies konfiguriert die resultierenden Asset-Typen in unserem utility network so, dass sie als Subnetzwerk-Controller fungieren. Falls dies nicht geschehen ist, müssen wir den Asset-Typ des Leistungsschalters manuell so konfigurieren, dass er als Subnetzwerk-Controller fungieren darf – gemäß den Anweisungen auf der Set a subnetwork controller-Seite in der Online-Hilfe.
Sobald Leistungsschalter als Subnetzwerk-Controller zugelassen sind, verwenden wir das Werkzeug Modify Subnetwork Controller, um den Leistungsschalter in einen Subnetzwerk-Controller umzuwandeln und dann den dadurch erzeugten Dirty-Bereich zu validieren. Anschließend können wir eine Subnetzwerk-Nachverfolgung für diesen Stromkreis durchführen – unter Verwendung derselben Bedingungsbarrieren wie bisher – und erhalten so den Umfang des Stromkreises.
Hinweis: Wenn Sie die Bedingungsbarrieren für Enabled/Device Status nicht auf Ihre Nachverfolgung anwenden, erhalten Sie keine korrekten Ergebnisse. Warum dies so ist und wie man es korrigiert wird im Abschnitt „Subnetwork Definition“ erläutert.
Wir können auch stromaufwärts- und stromabwärts-Nachverfolgungen innerhalb dieses Stromkreises durchführen; wenn wir unsere Bedingungsbarrieren anwenden, gelingen diese Nachverfolgungen.
Jetzt wo Sie verstehen wie man manuell Subnetzwerke erstellt, besteht der nächste Schritt darin zu betrachten wie man eine Sammlung von Subnetzwerk-Controllern ins utility network importieren kann. Dies ist ein wichtiger Schritt für viele elektrische Netzwerke da sie Hunderte oder Tausende von Stromkreisen/Subnetzwerken enthalten können.
Importieren von Subnetzwerken
Die zweite Möglichkeit zur Erstellung von Subnetzwerken besteht darin eine CSV-Datei zu importieren welche Informationen über alle Subnetzwerke im System enthält. Beide Ansätze sind gültig; aber für die meisten elektrischen Kunden ist es relativ einfach eine CSV-Datei zu erstellen welche alle ihre Subnetzwerk-Controller definiert. Mehr über diesen Prozess erfahren Sie auf der Import a subnetwork controller-Seite der Online-Hilfe. In diesem Beispiel haben wir folgende CSV-Datei erstellt.
Sobald Sie diese CSV-Datei ausgefüllt haben verwenden Sie das Werkzeug Import Subnetwork Controllers um die Datei in Ihr Netzwerk zu importieren und die entsprechenden Elemente als Subnetzwerk-Controller zu aktivieren.
Nach dem Import unserer Subnetzwerk-Controller müssen wir die Dirty-Bereiche bei jedem Controller validieren bevor sie als Quelle erkannt werden können. Sobald dies erledigt ist können Nachverfolgungen durchgeführt werden welche auf Subnetzwerk-Controllern basieren wie stromaufwärts-, stromabwärts- oder sogar Isolationsnachverfolgungen.
Wie bereits besprochen müssen wir für unsere Subnetzwerk-Nachverfolgungen weiterhin manuell Bedingungsbarrieren definieren um sicherzustellen dass offene Schalter unsere Nachverfolgungen stoppen. Im nächsten Abschnitt lernen wir wie man mit dem Werkzeug Set Subnetwork Definition dieses Verhalten als Standard für alle unsere Subnetzwerk-Nachverfolgungen festlegt.
Konfiguration der Subnetzwerk-Nachverfolgung
Bis jetzt erforderte jede Nachverfolgung dass Sie eine Reihe von Bedingungsbarrieren als Teil der Nachverfolgungskonfiguration angeben um korrekte Ergebnisse zu erhalten. Da wir möchten dass diese Bedingungsbarrieren automatisch jedes Mal angewendet werden wenn wir eine Nachverfolgung ausführen können wir das Werkzeug Set Subnetwork Definition verwenden um die Definition unserer Subnetzwerke so anzupassen dass diese Bedingungsbarrieren standardmäßig bei subnetzwerkbasierten Nachverfolgungen angewendet werden. Während wir die Definition des Subnetzwerks anpassen besprechen wir auch die Bedeutung einiger anderer Parameter in diesem Werkzeug welche Sie eventuell anpassen möchten.
Der erste Schritt zur Anpassung Ihrer Subnetzwerkdefinition besteht darin das Netzwerk, Domain und Tier auszuwählen welches Sie ändern möchten. Sobald diese Auswahl getroffen wurde füllt sich das Werkzeug automatisch mit der aktuellen Definition des Subnetztier-Ebenenbereichs.
Das Erste was wir tun müssen ist unsere Bedingungsbarrieren zur Definition unseres Subnetzes hinzuzufügen. Dies geschieht durch Ausfüllen des Parameters Condition Barriers unter dem Abschnitt "Subnetwork Trace Configuration" des Werkzeugs. Alle Änderungen am Abschnitt "Subnetwork Trace Configuration" beeinflussen die Standardnachverfolgungskonfiguration welche vom utility network bei Analysen dieser Netzebene verwendet wird.
Standardmäßig fügt das Werkzeug Migrate To Utility Network eine einzelne Bedingungsbarriere für deaktivierte Elemente hinzu.
Im vorherigen Beispiel wollen wir eine weitere Bedingungsbarriere hinzufügen um offene Geräte als Barrieren zu behandeln. Wenn andere Netzwerkattribute konfiguriert sind welche als Barrieren verwendet werden sollen könnten diese hier ebenfalls konfiguriert werden.
Eine weitere wichtige Option in diesem Abschnitt des Werkzeugs ist ob Container-, Inhalts- und Strukturfeatures in Ihren Nachverfolgungsergebnissen enthalten sein sollen. Wenn Sie Strukturen oder Container innerhalb Ihres Netzwerks modellieren wollen ermöglicht dies den subnetzwerkbasierten Nachverfolgungen schnell Features zu identifizieren welche vom Subnetz unterstützt werden oder dieses unterstützen.
Diese Konfiguration der subnetzwerkbasierten Nachverfolgung erlaubt Ihnen auch Zusammenfassungen für jedes Subnetz festzulegen. Diese Zusammenfassungen ermöglichen es Ihnen während Ihrer Nachverfolgungen zusammenfassende Statistiken zu berechnen; wenn sie ein Zusammenfassungsattribut definieren können Ergebnisse berechnet und auf Ihrem subnetwork line Feature zur Berichterstattung gespeichert werden. Ein einfaches Beispiel wäre die Berechnung der Gesamtlänge des Leiters eines Stromkreises wie unten gezeigt.
Jede Zusammenfassung benötigt Zeit während der Nachverfolgung und Aktualisierung des Subnetzes; seien Sie also achtsam bezüglich des Zeitaufwands zum Berechnen von Zusammenfassungen gegenüber dem Nutzen den sie Ihren Endbenutzern bieten. Nachdem sie Ihre Konfiguration angepasst haben können sie auf Ausführen klicken; eventuell möchten sie aber auch andere Abschnitte ihrer Definition anpassen.
Gültige Features und Objekte
Ein weiterer wichtiger Abschnitt der Subnetzwerkdefinition ist der Abschnitt "Gültige Features und Objekte". Dieser bestimmt, welche Features an Subnetzwerken für diese Ebene teilnehmen dürfen. Wenn Sie neue Asset-Typen zu Ihrem Modell hinzufügen, ist es wichtig, Ihre Subnetzwerkdefinitionen entsprechend zu aktualisieren, da Sie sonst Fehler erhalten, wenn Sie Ihre Subnetzwerke aktualisieren, die Features mit diesen neuen Asset-Typen enthalten.
Sie sollten auch in Erwägung ziehen, den Parameter "Aggregierte Linien für SubnetLine Feature Class" zu aktualisieren. Dieser bestimmt, welche Geometrien bei der Erstellung der Subnetzwerk-Linienklasse berücksichtigt werden. Standardmäßig schließt der Utility Network Builder keine Asset-Typen ein, was bedeutet, dass beim Aktualisieren von Subnetzwerken keine Subnetzwerk-Linie generiert wird. Sie sollten für diesen Parameter nur Asset-Typen auswählen, die Mittel- und Hochspannungsleitungen darstellen. Wählen Sie nicht alle Ihre Asset-Typen für diesen Parameter aus, da dies die Zeichnungszeit Ihrer Subnetzwerk-Linienebene erheblich negativ beeinflusst.
Hinweis: Features, die nicht in der Subnetzwerk-Linie enthalten sind, werden dennoch in den Zusammenfassungsstatistiken für das Netzwerk berücksichtigt. Wenn Sie also Ihre Leiterlänge berechnen möchten, sollten Sie eine Zusammenfassungsfunktion in Ihrer Trace-Konfiguration verwenden. Dies hat den zusätzlichen Vorteil, dass Sie einen Filter definieren können, um separate Längen für Mittel- und Niederspannungsleiter zu berechnen.
Subnetzwerk-Richtlinie aktualisieren
Der letzte große Abschnitt der Subnetzwerkdefinition ist die Aktualisierung der Subnetzwerk-Richtlinie. Diese gibt Ihnen Kontrolle darüber, wie Subnetzwerkinformationen innerhalb Ihres Utility Networks aktualisiert werden. Änderungen an diesen Einstellungen vorzunehmen ist für viele Kunden keine einfache Entscheidung, da es Kompromisse zwischen Bequemlichkeit und Leistung erfordert. Wir geben hier einen kurzen Überblick über diese Entscheidungspunkte und verweisen auf ausführlichere Diskussionen, wo verfügbar.
Der erste und einfachste Punkt zur Diskussion ist, ob Struktur-/Domänennetzwerk-Container aktualisiert werden sollen. Wenn Ihre Subnetzwerk-Trace-Konfiguration Strukturen/Container einschließt, sehen Sie hier Optionen dazu, ob diese aktualisiert werden sollen. Dies bestimmt, ob der Subnetzwerkname und unterstützte Subnetzwerknamenfelder auf Ihren Strukturen und Containern aktualisiert werden, wenn sie ein Feature enthalten oder unterstützen, das zu einem Subnetzwerk gehört. Dies ermöglicht es Ihnen, das Werkzeug "Auswahl nach Attributen" zu verwenden, um Features zu identifizieren, die ein Subnetzwerk unterstützen, ohne eine Trace auszuführen. Obwohl dies für Berichtsziele praktisch ist, bedeutet es auch, dass die Aktualisierung des Subnetzwerks länger dauert, da möglicherweise Hunderttausende zusätzlicher Features aktualisiert werden müssen.
Die nächste Option zur Diskussion ist, ob die Ebene das Feld "IsDirty" verwalten soll; Sie finden eine detaillierte Analyse zum Zustandsmanagement auf der Esri Community-Seite. Dieses Feld wird verwendet, um anzuzeigen, ob in Ihrem Utility Network validierte Bearbeitungen ein bestimmtes Subnetzwerk betroffen haben. Diese Option ist vom Utility Network Builder auf false gesetzt worden, da sie Leistungsbeeinträchtigungen verursachen kann.
Wenn diese Eigenschaft aktiviert ist, muss das Utility Network jedes Mal beim Validieren von Bearbeitungen eine oder mehrere Traces durchführen, um zu identifizieren, welche Subnetzwerke betroffen sind. Da die meisten elektrischen Stromkreise nur wenige tausend Features enthalten, sind die Kosten dafür normalerweise relativ gering im Vergleich zu den Vorteilen für die Qualitätssicherung. Sie sollten jedoch erwägen, diese Eigenschaft deaktiviert zu lassen, wenn Ihre Subnetzwerke Zehntausende oder Hunderttausende von Features enthalten.
Wenn diese Eigenschaft aktiviert ist, können Sie Ihre Qualitätssicherungsbemühungen auf nur die Subnetzwerke konzentrieren, die geändert wurden und leicht identifizieren, welche Stromkreise sauber sind und bereit zur Extraktion in ein externes System wie ein OMS sind.
Die leistungsfähigste Konfiguration besteht darin, diese Option deaktiviert zu lassen. Die Konfiguration mit dem größten Nutzen für Qualitätssicherung und Integrationen ist es hingegen, das Zustandsmanagement zu aktivieren.
Die letzte zu berücksichtigende Option ist der Eventing-Modus für Standard- und benannte Versionen. Dies beeinflusst die Leistung von "Update Subnetwork" und ob das Subnetzwerk-Feld während bestimmter Arbeitsabläufe ausgefüllt wird. Es gibt eine detaillierte Analyse zu Eventing-Modi auf der Esri Community-Seite. Eine stark vereinfachte Version der Diskussion folgt hier.
Wenn ein Subnetzwerk ohne Events aktualisiert wird, läuft es schneller. Dies liegt an mehreren Faktoren; ein Grund ist jedoch, dass Attributregeln und Editor-Tracking nicht ausgelöst werden. Der größte Nachteil dieses Verhaltens besteht darin, dass beim Aktualisieren eines Subnetzwerks in einer benannten Version nicht garantiert ist, dass alle Features ihren Subnetzwerknamen entsprechend dem ihnen zugehörigen Subnetzwerk aktualisiert bekommen.
Wenn ein Subnetzwerk mit Events aktualisiert wird, dauert die erste "Update Subnetwork"-Operation länger. Nachfolgende Aktualisierungen können ebenfalls länger dauern, wenn Attributregeln konfiguriert sind und viele Features aktualisiert werden. Der Vorteil des Aktualisierens von Subnetzwerken mit aktiviertem Eventing besteht darin, dass beim Ausführen von "Update Subnetwork" in einer Version garantiert wird, dass das Feature "Subnetzwerknamen" korrekt für alle Features dieses Subnetzwerks ausgefüllt wird.
Hinweis: Bei ArcGIS Enterprise 11.4 und ArcGIS Pro 3.4 kann die Leistungseinbuße durch das Auslösen von Attributregeln durch das neue Triggering Fields Verhalten von Attributregeln gemindert werden.
Die leistungsfähigste Konfiguration besteht darin, den Eventing-Modus auf "ohne Events aktualisieren" zu belassen. Die nützlichste Konfiguration für Qualitätssicherung besteht darin, den Eventing-Modus in benannten Versionen zu aktivieren und sicherzustellen, dass alle Ihre Attributregeln korrekt konfigurierte Triggerfelder haben.
Fazit
Nachdem Sie diesen Artikel abgeschlossen haben, kennen Sie nun die Grundlagen zur Konfiguration von Tracing und Netzwerkattributen zur Durchführung von Analysen mit Ihrem elektrischen Netzwerk. Sie haben auch gesehen, wie Sie Subnetzwerke erstellen können, die Upstream-, Downstream- und Isolations-Tracing ermöglichen. Außerdem haben Sie gelernt, wie Sie Ihre Subnetzwerkdefinition anpassen können, um Ihre Netzwerkattribute optimal zu nutzen. Wenn Sie bereit sind für fortgeschrittene Konfigurationen lesen Sie den Artikel zur erweiterten Konfiguration elektrischer Netzwerke.
Wenn Sie mehr darüber erfahren möchten, wie man das Utility Network zur Verwaltung elektrischer Netzwerke verwendet, erkunden Sie bitte die Learn ArcGIS Utility Network for Electric Utilities Serie. Diese Lernserie enthält Tutorials und Artikel zur Demonstration der Anforderungen der Elektroindustrie unter Verwendung des Utility Networks.
Laden Sie das Migrationstoolset herunter und erfahren Sie mehr über das Tool "Migrate to Utility Network" im Artikel „Erste Schritte mit dem Migrationstoolset“. Wie immer können Sie bei Fragen oder Kommentaren diese gerne auf der Esri Community-Seite stellen!
