Toen het utility network voor het eerst werd uitgebracht, introduceerde het een nieuw concept in het Esri-ecosysteem en vocabulaire, de Subnetwork. Deze abstractie is gemaakt om de verschillende manieren te beschrijven waarop gebruikers hun netwerken opdelen en beheren in netwerkzones zonder gebruik te maken van industriespecifieke termen zoals ‘Circuit’ of ‘Pressure zone’.
Maar waarom gebruiken we de term “subnetwork”?
Alle gegevens die worden gebruikt om de connectiviteit voor één set middelen van een nutsbedrijf te beheren, worden opgeslagen in een utility network (bijv. het netwerk). Dus wanneer dit netwerk wordt onderverdeeld in kleinere, topologisch aaneengesloten gebieden (circuits, drukzones, enz.) kan elk van deze zones nauwkeurig worden beschreven als een subnetwork. Met deze abstractie is een raamwerk gecreëerd om elk subnetwork als een eigen GIS-object te beheren dat kan worden gevisualiseerd, geanalyseerd en zelfs gebruikt voor rapportagedoeleinden. Een belangrijk onderdeel van dit raamwerk is het vermogen om metadata bij te houden over elk subnetwork zodat gebruikers kunnen begrijpen hoe hun systeem in de loop van de tijd verandert.
Deze metadata biedt basisinformatie zoals editor tracking-velden of kan worden uitgebreid met door gebruikers gedefinieerde waarden zoals het aantal klanten, aantal beschermingsapparaten, enz. Metadata stelt gebruikers ook in staat om de meest voorkomende en belangrijke vraag die een GIS-persoon krijgt gesteld te beantwoorden: zijn deze gegevens correct?
Dit is een verrassend lastige vraag omdat correct voor verschillende mensen verschillende dingen betekent. Door de oorspronkelijke vraag echter op te splitsen in meer specifieke vragen wordt het veel gemakkelijker om te beantwoorden:
- Wanneer is het subnetwork voor het laatst bijgewerkt?
- Wanneer is het subnetwork voor het laatst geëxporteerd naar een ander systeem?
- Is dit subnetwork up-to-date?
- Zijn er functies in het subnetwork gewijzigd sinds de laatste update?
- Zijn er bekende fouten die moeten worden opgelost in dit subnetwork?
De eerste twee vragen zijn gemakkelijk te beantwoorden via verschillende datumvelden die worden bijgehouden op het subnetwork, namelijk de velden Last Update Subnetwork en Last Ack Export Subnetwork. De laatste drie vragen kunnen allemaal worden beantwoord door te kijken naar het Status veld van een subnetwork (in eerdere modellen werd dit veld ‘Is Dirty’ genoemd) dat de statuswaarden Clean, Dirty en Invalid bevat. Dit is wat deze waarden betekenen:
- Clean – Een subnetwork zonder bekende fouten en klaar voor gebruik bij analyses.
- Dirty – Een subnetwork dat is gewijzigd en bijgewerkt moet worden.
- Invalid – Een subnetwork met één of meer bekende fouten die moeten worden opgelost.
Met deze basis gelegd zal de rest van dit artikel zich richten op hoe het systeem het Status-veld beheert en hoe elke statuswaarde geïnterpreteerd moet worden.
Subnetwerken markeren als Dirty
De sleutel tot het beheren van de status van subnetwerken in het utility network is dat het systeem moet kunnen bepalen wanneer een subnetwork wordt beïnvloed door een bewerking zodat het als dirty kan worden gemarkeerd. Hoewel er veel manieren zijn om dit te bereiken, gebruikt de software momenteel de validate network topology-operatie om subnetwerken te ontdekken en als dirty te markeren. Omdat bepalen welk subnetwork door een bewerking werd beïnvloed tracing vereist, zou dit teveel overhead aan het bewerkingsproces toevoegen als het systeem deze analyse na elke bewerking uitvoert. Ten slotte, omdat alle bewerkingsworkflows die het netwerk beïnvloeden gevalideerd moeten worden, kan het systeem ervoor zorgen dat de status van subnetwerken niet uit sync raakt met de gegevens tijdens bewerking.
Maar hoe bepaalt het systeem welke subnetwerken zijn gewijzigd?
Het systeem voert een subnetwork controller trace uit voor alle gevalideerde objecten om te ontdekken welke subnetwerken door de bewerkingen werden beïnvloed. Het exacte gedrag verschilt enigszins afhankelijk van of de gevalideerde bewerkingen behoren tot een partitioned of hierarchical utility network. Wat betekenen deze termen en waarom is dit belangrijk? We bespreken dit hieronder.
In een partitioned subnetwork kan elk object maximaal tot één subnetwork behoren. Dit betekent dat het systeem elke laag van het netwerk analyseert om te bepalen of een van de bewerkte objecten tot die laag behoort. Zodra een object aan een specifiek subnetwork is gekoppeld, kan het uit latere analyses worden verwijderd en zodra alle objecten gekoppeld zijn, is de analyse voltooid, zelfs als niet alle lagen zijn geanalyseerd. Hieronder ziet u een vereenvoudigd voorbeeld van een partitioned netwerk:
In het geval van een hierarchical netwerk kan elk object tot meerdere subnetwerken behoren omdat de lagen van het netwerk genest zijn in elkaar. Daarom moet het systeem altijd elke laag in het netwerk analyseren voor alle bewerkte objecten. Hieronder ziet u een vereenvoudigd voorbeeld van een hierarchical netwerk:
Nu we op hoofdlijnen naar de verschillende topologietypen hebben gekeken, zullen we verschillende bewerkingsscenario’s voor elk type bekijken en noteren hoe het systeem zich gedraagt.
Partitioned
Wanneer de netwerktopologie wordt gevalideerd in een partitioned netwerk, moet het systeem bepalen welk subnetwork door elke bewerking werd beïnvloed. Hiervoor identificeert het alle lagen in het netwerk die subnetwerken bevatten en analyseert elke laag om te bepalen welke subnetwerken per laag eventueel door de bewerking werden beïnvloed. Het systeem herhaalt dit proces per laag totdat bronnen voor alle bewerkte objecten zijn gevonden of totdat alle lagen zijn geanalyseerd. Laten we enkele voorbeelden bekijken van dit gedrag in actie.
In het eerste voorbeeld hieronder wordt één enkele bewerking uitgevoerd op het utility network (paars gearceerd gebied). Wanneer validate network topology draait vindt het één netwerkbron voor de bewerking op de eerste geanalyseerde laag, namelijk de distributielaag. Dit stelt validate in staat om geen analyse uit te voeren op de transmissielaag omdat al een subnetwork controller is gevonden die alle bewerkingen omvat.
In dit tweede voorbeeld worden meerdere bewerkingen op verschillende plekken in het netwerk gevalideerd. Het systeem moet meerdere traces uitvoeren om bronnen voor alle bewerkingen te vinden omdat ze zich op meerdere lagen bevinden.
In het derde voorbeeld valideert het systeem een bewerking aan een object dat niet verbonden is met enige subnetwerken. In dit geval moet het systeem alle lagen traceren om te bevestigen dat geen subnetwerken werden beïnvloed.
Zoals u kunt zien kan validate network topology sneller gewijzigde subnetwerken identificeren in partitioned netwerken wanneer bewerkingen beperkt blijven tot één laag en wanneer gewijzigde subnetwerken kleiner zijn. Naarmate er meer lagen zijn en subnetwerken groter worden duurt identificatie langer omdat er meer traces nodig zijn die ook langer duren.
Hierarchical
Omdat elk object in een hierarchical netwerk tot meerdere lagen kan behoren, moet bij validate network topology elke laag met subnetwerken worden overwogen bij identificatie van beïnvloede subnetwerken.
Hieronder ziet u een voorbeeld van een eenvoudig hierarchical netwerk met één systeemsubnetwerk dat twee kleinere subnetwerken bevat.
In dit eerste voorbeeld hieronder wordt een object uit één van de kleinere subnetwerken bewerkt. Het systeem identificeert eerst dat kleinere subnetwork waartoe de bewerking behoort. Omdat dit echter een hierarchical subnetwork is moet ook elke andere laag geanalyseerd worden en identificeert het systeem hier nog een tweede subnetwork in een andere laag dat als dirty gemarkeerd wordt.
In het tweede voorbeeld wordt een object exclusief behorend tot het grotere subnetwork bewerkt. In dit geval worden lagere rangorde subnetwerken niet als dirty gemarkeerd omdat ze niet werden beïnvloed door de bewerking. Deze logica geldt ongeacht of het netwerk source-based of sink-based is omdat altijd het hoogste rangorde netwerk buitenste container is in de hiërarchie (de ultieme bron of ultieme afvoer).
In het derde voorbeeld wordt een object dat niet tot enig subnetwork behoort bewerkt. In dit geval worden geen subnetwerken als dirty gemarkeerd maar moet wel elke laag getraceerd worden om te bevestigen dat dit object niet tot enige subnetwerken behoort.
Omdat systeemsubnetwerken zo groot zijn kunnen ze hogere prestatiekosten veroorzaken bij validate network topology dan kleinere subnetwerken. Ook omdat ze zoveel objecten bevatten worden ze vaker als dirty gemarkeerd tijdens validate en moeten ze vaak meerdere keren per dag bijgewerkt worden om clean te blijven. Daarom wordt vaak ingesteld dat hoogste lagen in hierarchical netwerken niet zelf status beheren maar alleen ’s nachts bijgewerkt worden. Dit vermindert updates én verbetert prestaties omdat validate network topology deze laag dan overslaat tijdens validatie. De volgende sectie bespreekt hoe u kunt bepalen of een laag zo is ingesteld.
Configuratie
Hoewel onderhoud van het Status-veld standaardgedrag is voor subnetwerken in utility networks, zijn er gebruikers en hele sectoren die geen gebruik maken van statusbeheer binnen hun workflows. Om deze configuratie te ondersteunen bevat de sectie Update Subnetwork Policy van de Set Subnetwork Definition tool een optie om te bepalen of bijbehorende laag binnen subnetwork ‘Manage IsDirty’ moet toepassen.
Gebruikers die ervoor kiezen om deze functie niet te activeren (state management uitschakelen) doen dit meestal om een van de twee redenen:
- Hun bewerkingsworkflows resulteren in subnetwerken die altijd 'dirty' zijn, of...
- Prestatie-impact
Onthoud dat deze instelling afzonderlijk wordt geconfigureerd voor elke laag in uw netwerk, dus u kunt ervoor kiezen deze instelling ingeschakeld te laten voor sommige lagen in uw netwerk (distributie, drukzones, enz.) terwijl u deze uitschakelt voor andere, grotere lagen (transmissie, systeem, enz.).
Ongeacht hoe uw netwerk momenteel is geconfigureerd, kunt u deze instelling altijd later wijzigen. Als uw model deze instelling momenteel heeft ingeschakeld, kan deze optie worden uitgeschakeld als u het beheren van het statusveld niet nuttig vindt. Als u daarentegen een model hebt dat het statusveld niet beheert, maar later besluit dat u het statusveld in uw workflows wilt gebruiken, kan het worden ingeschakeld.
Consistentie valideren
De hele discussie tot nu toe heeft gekeken naar hoe, wanneer en welke subnetwerken als 'dirty' worden gemarkeerd wanneer een 'dirty' gebied wordt gevalideerd. Dit roept natuurlijk de vraag op; hoe reageert het systeem of identificeert het subnetwerken die bewerkingen bevatten die nog niet zijn gevalideerd? Hier komt het idee van consistentie valideren tijdens analyse om de hoek kijken.
Het standaardgedrag wanneer u een trace uitvoert in het utility network is om de consistentie van uw traceresultaat te valideren. Wat dit praktisch betekent is dat het systeem controleert of er 'dirty' gebieden zijn gekoppeld aan uw traceresultaten. Als er geen 'dirty' gebieden zijn gekoppeld aan uw resultaten, worden uw resultaten als consistent beschouwd.
Als er echter wel 'dirty' gebieden zijn gekoppeld aan uw traceresultaten, zal de trace mislukken en ontvangt u een foutmelding waarin wordt aangegeven dat één of meer 'dirty' gebieden zijn ontdekt tijdens de trace. Als u de 'dirty' gebieden wilt negeren en de traceresultaten wilt zien, wat mogelijk onjuiste resultaten oplevert, kunt u de optie Consistentie valideren uitschakelen.
Hoe werkt dit met betrekking tot de status van subnetwerken? Als er tijdens het bijwerken van een subnetwork 'dirty' gebieden worden aangetroffen, wordt het subnetwork als 'dirty' gemarkeerd. Een schoon subnetwork kan echter consistent of inconsistent zijn, afhankelijk van of er nog openstaande, niet-gevalideerde bewerkingen zijn sinds de laatste update. Als er niet-gevalideerde 'dirty' gebieden in uw database zijn, weet het systeem niet welk subnetwork (indien aanwezig) als 'dirty' moet worden gemarkeerd totdat de bewerking is gevalideerd. Zodra al uw 'dirty' gebieden zijn gevalideerd, worden de overeenkomstige subnetwerken als 'dirty' gemarkeerd en zullen alle traces consistent zijn.
Welke impact heeft dit op het beheren van subnetwerken? Het betekent dat u niet per se aan de status van een subnetwork kunt zien of het consistent is. U kunt er echter zeker van zijn dat als u een subnetwork traceert, u een foutmelding krijgt als u probeert een inconsistent subnetwork te analyseren of exporteren, zelfs als het subnetwork aangeeft schoon te zijn.
Conclusie
Nu u dit artikel hebt gelezen, zou u een beter begrip moeten hebben van de voordelen en workflows die gepaard gaan met subnetworkbeheer en hoe het statusveld u door die workflows helpt leiden. U zou ook moeten begrijpen hoe het systeem dit veld beheert en waarom bepaalde sectoren ervoor kunnen kiezen om het statusveld alleen voor sommige lagen in hun utility network te beheren.
