Als das utility network erstmals veröffentlicht wurde, führte es ein neues Konzept in das Esri-Ökosystem und den Wortschatz ein, das Subnetwork genannt wird. Diese Abstraktion wurde geschaffen, um die verschiedenen Möglichkeiten zu beschreiben, wie Benutzer ihre Netzwerke in Netzwerkzonen unterteilen und verwalten, ohne branchenspezifische Begriffe wie ‚Circuit‘ oder ‚Pressure zone‘ zu verwenden.
Aber warum verwenden wir den Begriff „Subnetwork“?
Alle Daten, die zur Verwaltung der Konnektivität für eine Ressourcengruppe eines Versorgungsunternehmens verwendet werden, sind in einem utility network gespeichert (z. B. dem Netzwerk). Wenn dieses Netzwerk in kleinere, topologisch zusammenhängende Bereiche (Schaltkreise, Druckzonen usw.) unterteilt wird, kann jede dieser Zonen genau als Subnetwork beschrieben werden. Mit dieser Abstraktion wurde ein Rahmen geschaffen, um jedes Subnetwork als eigenes GIS-Objekt zu verwalten, das visualisiert, analysiert und sogar für Berichte verwendet werden kann. Ein wichtiger Bestandteil dieses Rahmens ist die Möglichkeit, Metadaten zu jedem Subnetwork zu verfolgen, damit Benutzer verstehen können, wie sich ihr System im Laufe der Zeit verändert.
Diese Metadaten liefern grundlegende Informationen wie Felder zur Bearbeitungsverfolgung oder können erweitert werden, um benutzerdefinierte Werte wie die Anzahl der Kunden, Anzahl der Schutzvorrichtungen usw. einzubeziehen. Metadaten ermöglichen es den Benutzern auch, die häufigste und wichtigste Frage zu beantworten, die eine GIS-Person gestellt bekommt: Sind diese Daten korrekt?
Das ist eine überraschend schwierige Frage, weil ‚korrekt‘ für verschiedene Personen unterschiedliche Bedeutungen hat. Wenn man die ursprüngliche Frage jedoch in spezifischere Fragen aufteilt, wird es viel einfacher zu beantworten:
- Wann wurde das Subnetwork zuletzt aktualisiert?
- Wann wurde das Subnetwork zuletzt in ein anderes System exportiert?
- Ist dieses Subnetwork aktuell?
- Wurden Features im Subnetwork seit der letzten Aktualisierung geändert?
- Gibt es bekannte Fehler in diesem Subnetwork, die behoben werden müssen?
Die ersten beiden Fragen lassen sich leicht über mehrere Datumsfelder beantworten, die im Subnetwork gepflegt werden, nämlich die Felder Last Update Subnetwork und Last Ack Export Subnetwork. Die letzten drei Fragen können alle durch Betrachtung des Status-Felds eines Subnetworks beantwortet werden (in früheren Modellen hieß dieses Feld ‚Is Dirty‘), das die Statuswerte Clean, Dirty und Invalid enthält. Hier ist die Bedeutung dieser Werte:
- Clean – Ein Subnetwork ohne bekannte Fehler und bereit zur Analyse.
- Dirty – Ein Subnetwork, das geändert wurde und aktualisiert werden muss.
- Invalid – Ein Subnetwork mit einem oder mehreren bekannten Fehlern, die behoben werden müssen.
Nachdem die Grundlagen gelegt sind, konzentriert sich der Rest dieses Artikels darauf, wie das System das Statusfeld verwaltet und wie man die verschiedenen Statuswerte interpretiert.
Subnetze als Dirty markieren
Der Schlüssel zur Verwaltung des Status von Subnetzen im utility network besteht darin, dass das System erkennen muss, wann ein Subnetwork durch eine Bearbeitung betroffen ist, damit es als dirty markiert werden kann. Obwohl es viele Möglichkeiten gibt, dies zu erreichen, verwendet die Software derzeit den Vorgang validate network topology, um subnetworks zu entdecken und als dirty zu markieren. Da die Bestimmung des betroffenen subnetworks eine Nachverfolgung erfordert, würde dies den Bearbeitungsprozess stark verlangsamen, wenn das System diese Analyse nach jeder Bearbeitung durchführen würde. Da alle Bearbeitungsabläufe mit Auswirkungen auf das Netzwerk validiert werden müssen, stellt dies sicher, dass der Zustand der subnetworks nicht mit den bearbeiteten Daten aus dem Gleichgewicht gerät.
Aber wie bestimmt das System, welche subnetworks geändert wurden?
Das System führt eine subnetwork controller trace für alle validierten Features durch, um herauszufinden, welche subnetworks von den Änderungen betroffen sind. Das genaue Verhalten unterscheidet sich leicht je nachdem, ob die validierten Änderungen zu einem partitioned oder einem hierarchical utility network gehören. Was bedeuten diese Begriffe und warum ist das wichtig? Wir erläutern dies im Folgenden.
In einem partitioned subnetwork kann jedes Feature höchstens zu einem einzigen subnetwork gehören. Das bedeutet, dass das System jede Ebene des Netzwerks analysiert, um festzustellen, ob eines der bearbeiteten Features zu dieser Ebene gehört. Sobald ein Feature einem bestimmten subnetwork zugeordnet wurde, kann es bei der Analyse der folgenden Ebenen ausgeschlossen werden; sobald alle Features zugeordnet sind, ist die Analyse abgeschlossen – auch wenn nicht alle Ebenen analysiert wurden. Ein vereinfachtes Beispiel für ein partitioned network sehen Sie unten:
Im Fall eines hierarchical network kann jedes Feature mehreren subnetworks angehören, da die Ebenen des Netzwerks ineinander verschachtelt sind. Daher muss das System immer jede Ebene im Netzwerk für alle bearbeiteten Features analysieren. Ein vereinfachtes Beispiel für ein hierarchical network sehen Sie unten:
Nachdem wir nun einen Überblick über die verschiedenen Topologietypen haben, betrachten wir mehrere Bearbeitungsszenarien für jeden dieser Typen und notieren uns das Verhalten des Systems.
Partitioned
Wenn die Netzwerktopologie in einem partitioned network validiert wird, muss das System das durch jede Bearbeitung betroffene subnetwork identifizieren. Dazu ermittelt es alle Ebenen im Netzwerk mit subnetworks und analysiert jede Ebene daraufhin, welche subnetworks in dieser Ebene von der Bearbeitung betroffen sind. Dieser Vorgang wird mit jeder Ebene wiederholt bis alle bearbeiteten Features einer Netzwerkquelle zugeordnet wurden oder alle Ebenen analysiert sind. Schauen wir uns einige Beispiele für dieses Verhalten an.
Im ersten Beispiel unten wird eine einzelne Änderung am utility network vorgenommen (violettes Hash-Polygon). Wenn validate network topology ausgeführt wird, findet es auf der ersten analysierten Ebene – der Verteilungsebene – eine einzige Netzwerkquelle für die Änderung. Dadurch kann validate auf eine Analyse der Übertragungsebene verzichten, da bereits ein subnetwork controller gefunden wurde, der alle Änderungen abdeckt.
Im zweiten Beispiel werden mehrere Änderungen in verschiedenen Bereichen des Netzwerks validiert. Das System muss mehrere Nachverfolgungen durchführen, um Quellen für alle Änderungen zu finden, da diese in mehreren Ebenen des Netzwerks auftraten.
Im dritten Beispiel validiert das System eine Änderung an einem Feature ohne Verbindung zu einem subnetwork. In diesem Fall muss das System alle Ebenen des Netzwerks nachverfolgen um sicherzustellen, dass keine subnetworks betroffen sind.
Wie Sie sehen können identifiziert validate network topology modifizierte subnetworks in partitioned networks schneller wenn sich Änderungen auf eine einzelne Ebene beschränken und wenn die geänderten subnetworks kleiner sind. Mit zunehmender Anzahl an Ebenen und Größe des subnetworks benötigt das System mehr Zeit zur Identifikation modifizierter subnetworks während validate network topology da mehr Nachverfolgungen erforderlich sind und diese länger dauern.
Hierarchical
Da jedes Feature in einem hierarchical network mehreren Ebenen angehören kann muss das System bei der Identifikation betroffener subnetworks während validate network topology jede Ebene mit subnetworks berücksichtigen.
Unten sehen Sie ein Beispiel für ein einfaches hierarchical network mit einem einzelnen system subnetwork welches zwei kleinere subnetworks enthält.
Im ersten Beispiel unten wird ein Feature eines kleineren subnetworks bearbeitet. Das System identifiziert zunächst das kleinere subnetwork zur Änderung gehörend. Da es sich jedoch um ein hierarchical subnetwork handelt muss es alle übrigen Ebenen im Netzwerk analysieren und findet dabei ein zweites subnetwork in einer anderen Ebene welches als dirty markiert wird.
Im zweiten Beispiel wird ein Feature bearbeitet welches ausschließlich zum größeren subnetwork gehört. In diesem Fall werden niedrigere subnetworks nicht als dirty markiert da sie von der Änderung nicht betroffen sind. Diese Logik gilt unabhängig davon ob das Netzwerk quellbasiert oder senkenbasiert ist da das höchstrangige Netzwerk immer der äußerste Container in der Hierarchie ist (die ultimative Quelle oder Senke des Netzwerks).
Im dritten Beispiel wird ein Feature bearbeitet welches keinem subnetwork angehört. In diesem Fall werden keine subnetworks als dirty markiert; dennoch muss das utility network jede Ebene nachverfolgen um sicherzustellen dass dieses Feature keinem subnetwork angehört.
Da system subnetworks sehr groß sind können sie bei validate network topology höhere Leistungskosten verursachen als kleinere subnetworks. Außerdem werden diese subnetworks aufgrund ihrer Größe häufiger als dirty markiert weshalb jedes system subnetwork oft mehrmals täglich aktualisiert werden muss um sauber zu bleiben. Deshalb ist es üblich dass die höchstrangigen Ebenen eines hierarchical networks so konfiguriert sind dass sie den Status nicht verwalten sondern nur nachts aktualisiert werden. Dies reduziert nicht nur wie oft diese subnetworks aktualisiert werden sondern verbessert auch die Leistung von validate network topology da diese Ebene übersprungen wird während der Validierung. Der nächste Abschnitt dieses Artikels erklärt wie Sie feststellen können ob eine Ebene so konfiguriert ist dass sie den Status verwaltet.
Konfiguration
Obwohl die Pflege des Statusfelds standardmäßig bei den subnetworks im utility network erfolgt gibt es einige Benutzer und ganze Branchen die den Subnetzstatus nicht in ihren Arbeitsabläufen verwenden. Um diese Konfiguration zu unterstützen enthält der Abschnitt Update Subnetwork Policy des Set Subnetwork Definition tool eine Option zur Festlegung ob die entsprechende Ebene im subnetwork ‚Manage IsDirty‘ aktiviert haben soll.
Benutzer, die sich gegen dieses Verhalten (Deaktivierung des State Managements) entscheiden, tun dies in der Regel aus einem von zwei Gründen:
- Ihre Bearbeitungsabläufe führen dazu, dass Subnetzwerke immer als "dirty" gelten, oder...
- Leistungseinbußen
Denken Sie daran, dass diese Einstellung für jede Ebene in Ihrem Netzwerk separat konfiguriert wird. Sie können also wählen, diese Einstellung für einige Ebenen in Ihrem Netzwerk aktiviert zu lassen (Verteilung, Druckzonen usw.) und sie für andere, größere Ebenen (Übertragung, System usw.) zu deaktivieren.
Unabhängig davon, wie Ihr Netzwerk derzeit konfiguriert ist, können Sie diese Einstellung jederzeit ändern. Wenn Ihr Modell diese Einstellung derzeit aktiviert hat, kann diese Option deaktiviert werden, wenn Sie die Verwaltung des Statusfelds nicht als nützlich erachten. Wenn Sie hingegen ein Modell haben, das das Statusfeld nicht verwaltet, aber später entscheiden, dass Sie das Statusfeld in Ihren Arbeitsabläufen nutzen möchten, kann es aktiviert werden.
Konsistenz validieren
Die gesamte bisherige Diskussion hat sich damit beschäftigt, wie, wann und welche Subnetzwerke als "dirty" markiert werden, wenn ein "dirty" Bereich validiert wird. Dies wirft natürlich die Frage auf: Wie reagiert das System oder wie identifiziert es Subnetzwerke mit Änderungen, die noch nicht validiert wurden? Hier kommt die Idee der Konsistenzvalidierung während der Analyse ins Spiel.
Das Standardverhalten bei einer Trace-Ausführung im Versorgungsnetz besteht darin, die Konsistenz Ihres Trace-Ergebnisses zu validieren. Praktisch bedeutet dies, dass das System prüft, ob mit Ihren Trace-Ergebnissen "dirty" Bereiche verbunden sind. Wenn keine "dirty" Bereiche mit Ihren Ergebnissen verbunden sind, gelten Ihre Ergebnisse als konsistent.
Wenn jedoch "dirty" Bereiche mit Ihren Trace-Ergebnissen verbunden sind, schlägt der Trace fehl und Sie erhalten eine Fehlermeldung, die Sie darüber informiert, dass während des Traces ein oder mehrere "dirty" Bereiche entdeckt wurden. Wenn Sie die "dirty" Bereiche ignorieren und die Trace-Ergebnisse sehen möchten – was möglicherweise zu falschen Ergebnissen führt – können Sie die Option zur Validierung der Konsistenz deaktivieren.
Wie wirkt sich das auf den Status von Subnetzwerken aus? Wenn während eines Updates eines Subnetzwerks "dirty" Bereiche gefunden werden, wird das Subnetzwerk als "dirty" markiert. Ein sauberes Subnetzwerk kann jedoch konsistent oder inkonsistent sein – je nachdem, ob seit dem letzten Update noch ausstehende und nicht validierte Änderungen vorliegen. Wenn es unvalidierte "dirty" Bereiche in Ihrer Datenbank gibt, weiß das System nicht, welches Subnetzwerk (falls überhaupt eines) als "dirty" markiert werden soll, bis die Änderungen validiert sind. Sobald alle "dirty" Bereiche validiert sind, werden die entsprechenden Subnetzwerke als "dirty" markiert und alle Traces sind konsistent.
Welche Auswirkungen hat das auf die Verwaltung von Subnetzwerken? Es bedeutet, dass man nicht unbedingt am Status eines Subnetzwerks erkennen kann, ob es konsistent ist. Sie können jedoch sicher sein, dass Sie beim Trace eines Subnetzwerks eine Fehlermeldung erhalten, wenn Sie versuchen, ein inkonsistentes Subnetzwerk zu analysieren oder zu exportieren – selbst wenn das Subnetzwerk als sauber angezeigt wird.
Fazit
Nachdem Sie diesen Artikel gelesen haben, sollten Sie ein besseres Verständnis für die Vorteile und Arbeitsabläufe im Zusammenhang mit der Verwaltung von Subnetzwerken haben und wissen, wie das Statusfeld Sie durch diese Arbeitsabläufe führt. Außerdem sollten Sie verstehen, wie das System dieses Feld verwaltet und warum bestimmte Branchen möglicherweise nur für einige Ebenen ihres Versorgungsnetzes das Statusfeld verwalten.
