Als je de Migrate To Utility Network tool hebt gebruikt om je elektrische gegevens naar een utility network te migreren, vraag je je waarschijnlijk af: "Welke configuratie moet ik uitvoeren op dit utility network om het te laten functioneren als een elektrisch distributienetwerk?"
Deze netwerken modelleren het pad dat elektriciteit aflegt van een middenspanningsschakelaar in een onderstation naar de laagspanningsklanten in het netwerk. Analysewerkstromen voor deze datasets variëren van het bekijken van de belasting op de schakelaar of transformator tot het zorgen dat beschermingsapparatuur correct is gedimensioneerd om mogelijke storingen in het systeem aan te kunnen.
In dit artikel laten we je zien hoe je een model dat met de Migration-toolset is gemaakt, kunt uitbreiden om enkele van deze basiswerkstromen te ondersteunen.
Opmerking: Voordat je configuratiewijzigingen aanbrengt in je netwerk, moet je ervoor zorgen dat alle topologiefouten zijn opgelost, omdat je niet kunt traceren in delen van je netwerk die fouten bevatten. Het oplossen van topologiefouten nadat je de netwerktopologie hebt ingeschakeld of je utility network hebt ingezet, beperkt je mogelijkheid om tools zoals Apply Error Resolutions te gebruiken om fouten automatisch te corrigeren.
Connectiviteitstracering
De eerste en meest basale soort trace in het utility network is een verbonden trace. Om een verbonden trace uit te voeren, voeg je een startpunt toe op een netwerkobject op de kaart en voer je vervolgens een verbonden trace uit. Dit type trace retourneert alle objecten die vanaf die locatie doorlopen kunnen worden op basis van de configuratie voor de trace. Een verbonden trace zonder extra configuratie zal waarschijnlijk je gehele dataset retourneren, zoals hieronder te zien is.
Hoewel dit een handige test is om niet-verbonden objecten te identificeren, zou een realistischer trace rekening houden met de status (open/gesloten) van een apparaat, elektrische fasering en of een object in gebruik of voorgesteld is. Dit kan worden gesimuleerd door handmatig barrières toe te voegen aan je trace om deze condities weer te geven, maar de aanbevolen manier is om conditiebarrières voor je trace te definiëren.
Als je de Migrate To Utility Network gebruikt om je netwerk te maken, zie je dat elk object een enabled-veld heeft. Als je gegevens uit een geometrisch netwerk hebt gemigreerd, is dit veld gevuld met een waarde die aangeeft of het als barrière moet fungeren. In het onderstaande voorbeeld voeren we een trace uit met gegevens uit een geometrisch netwerk en behandelen we alle uitgeschakelde objecten (open apparaten) als barrières.
Je ziet dat deze trace, in tegenstelling tot de initiële trace, alle objecten retourneert die elektrisch verbonden zijn met het object geassocieerd met het startpunt. Het evalueren van deze conditiebarrières tijdens een trace stelt ons in staat om de omvang van het circuit vanaf de startlocatie te ontdekken.
Hoewel het prima is om het enabled-veld als conditiebarrière te gebruiken, ben je misschien niet gewend om een enabled-veld bij te houden en wil je liever een ander veld gebruiken om de status van schakelbare apparaten bij te houden. Dit wordt besproken in de volgende sectie.
Apparaatstatus
Om attributen van je objecten op te nemen in tracing of analyse, maak je een netwerkattribuut zodat het utility network ernaar kan verwijzen. Laten we door een voorbeeld lopen van het maken van een Device Status-netwerkattribuut dat kan worden gebruikt voor tracingbeheer.
De eerste stap is het identificeren van het veld uit onze gegevens dat we willen gebruiken. In dit geval gebruiken we het NormalOperatingStatus-veld in onze apparaatklasse. Dit is een kort geheel getalveld met een domein dat aangeeft of het apparaat open (1) of gesloten (0) is.
Nu we het veld, datatype en domein hebben geïdentificeerd die we willen gebruiken, kunnen we het netwerkattribuut maken. Eerst voegen we een netwerkattribuut toe aan het utility network dat overeenkomt met het datatype van ons veld. Omdat dit veld in bijna al onze traces wordt gebruikt, willen we het inline opslaan zodat het beter presteert.
Lees de online help over netwerkattributen voor meer informatie over hun gebruik en effect op het gedrag van je utility network.
Zodra het netwerkattribuut aan het utility network is toegevoegd, is de volgende stap om te selecteren welke velden aan het attribuut worden gekoppeld. We zijn niet verplicht om elk klasse in ons netwerk aan elk netwerkattribuut te koppelen, maar elk netwerkattribuut kan slechts aan één veld per klasse worden gekoppeld. Als we meerdere statusvelden hebben, kunnen we slechts één veld selecteren om aan dit netwerkattribuut te koppelen.
Zodra we dit veld hebben gekoppeld aan ons netwerkattribuut, kunnen we het gebruiken om een conditiebarrière voor onze traces te definiëren.
Elke keer dat een gebruiker een veld wijzigt dat gekoppeld is aan een netwerkattribuut, genereert het object een dirty area die gevalideerd moet worden om het netwerk bij te werken met de nieuwe waarde. Hieronder zien we een voorbeeld waarbij we traceren door een gesloten zekering (1) en nadat we de apparaatstatus van de zekering op open hebben gezet en na validatie stopt de trace bij de nieuw geopende zekering (2).
Deze strategie werkt goed als je één statusveld hebt, maar wat als je voor elke fase een ander statusveld bijhoudt? Dat bespreken we in onze volgende sectie.
Meerdere Statusvelden
In de vorige sectie zag je hoe je één enkel veld kunt gebruiken om de open/gesloten positie van een apparaat te modelleren. Maar als je velden hebt waarmee elke fase van een apparaat een aparte status kan hebben, moet je rekening houden met één van verschillende oplossingen.
Het is gebruikelijk dat elektrische modellen drie aparte velden gebruiken om de open/gesloten status van een apparaat te beheren. Elk van deze velden correspondeert met een andere elektriciteitsfase (A, B of C), en dit model maakt het mogelijk om de status van elke fase afzonderlijk te modelleren.
Bij gebruik van de Migrate To Utility Network-tool moet een apparaat als gang operated worden behandeld. Dit betekent dat het apparaat als geheel open of gesloten wordt beschouwd; er kan geen gemengde status zijn. Als je apparaten met gemengde status wilt modelleren, moet je ze als aparte apparaten modelleren of moet je jouw gegevens migreren naar de Electric Utility Network Foundation.
Er zijn verschillende manieren om dit werkend te krijgen met behulp van de Migrate To Utility Network-tool. De gemakkelijkste manier is door door te gaan met het gebruik van het enabled-veld (of door één enkel apparaatstatusveld aan te maken) om tracing te regelen en dit veld vullen met jouw bestaande statuswaarden. Hiervoor moet je enkele dingen weten:
- Welke velden gebruik jij om de status van elke fase van een apparaat weer te geven?
- Welke waarden vertegenwoordigen open en gesloten?
- Welk veld gebruik jij om de fasering van een apparaat in jouw netwerk weer te geven?
- Welke waarden in het faseveld zijn toepasbaar op elk statusveld?
Met deze informatie kun je de Select By Attributes-tool gebruiken om alle apparatuur die open of gesloten moet zijn te identificeren.
Laten we hieronder naar een voorbeeld hiervan kijken.
- Welke velden gebruik jij om de status van elke fase van een apparaat weer te geven?
- StatusValueOpen0Gesloten1 PhasingCodePhaseValueA4B2C1AB6AC5BC3ABC7 Met deze informatie kunnen we drie queries schrijven:QueryExpressionApparaten die open moeten zijn (Enabled=False)ENABLED=1 EN(((POSA=0 EN PHASINGCODE=4)OF (POSB=0 EN PHASINGCODE=2)OF (POSC=0 EN PHASINGCODE=1))OF(((POSA=0 OF POSB=0) EN PHASINGCODE=6)OF ((POSA=0 OF POSC=0) EN PHASINGCODE=5)OF ((POSB=0 OF POSC=0) EN PHASINGCODE=3))OF((POSA=0 OF POSB=0 OF POSC=0) EN PHASINGCODE=7))Apparaten die gesloten moeten zijn (Enabled=True)ENABLED=0 EN(((POSA=1 EN PHASINGCODE=4)OF (POSB=1 EN PHASINGCODE=2)OF (POSC=1 EN PHASINGCODE=1))OF(((POSA=1 OF POSB=1) EN PHASINGCODE=6)OF ((POSA=1 OF POSC=1) EN PHASINGCODE=5)OF ((POSB=1 OF POSC=1) EN PHASINGCODE=3))OF((POSA=1 OF POSB=1 OF POSC=1) EN PHASINGCODE=7))Een query om apparatuur met gemengde status te identificeren(PHASINGCODE=6 EN ((POSA=0 EN POSB=1) OF (POSA=1 EN POSB=0)))OF (PHASINGCODE=5 EN ((POSA=0 EN POSC=1) OF (POSA=1 EN POSC=0)))OF (PHASINGCODE=3 EN ((POSB=0 EN POSC=1) OF (POSB=1 EN POSC=0)))OF (PHASINGCODE=7 EN ((POSA=0 EN POSB=0 EN POSC=1) OF (POSA=0 EN POSB=1 EN POSC=0) OF (POSA=0 EN POSB=1 EN POSC=1) OF (POSA=1 EN POSB=0 EN POSC=0) OF (POSA=1 EN POSB=0 EN POSC=1))) Laten we kijken naar een voorbeeld waarbij deze techniek op onze data wordt toegepast.Eerst voer je de query uit om objecten met gemengde status in jouw netwerk te identificeren. Als deze query objecten identificeert, moet je overwegen hoe je apparaten met gemengde status voortaan wilt ondersteunen. Indien acceptabel, gebruik dan één enkel statusveld en beheer meerdere velden dienovereenkomstig. Anders moet je andere opties overwegen, zoals gebruikmaken van Electric Utility Network Foundation.Vervolgens selecteer alle apparaten in het netwerk die open moeten zijn (Enabled=False).
- Welke waarden vertegenwoordigen open en gesloten?
- Welk veld gebruik jij om de fasering van een apparaat in jouw netwerk weer te geven?
- Welke waarden in het faseveld zijn toepasbaar op elk statusveld?
Stel vervolgens het Enabled-veld op deze objecten in op Uitgeschakeld/Open.
Opmerking: Als je dataset groot is, overweeg dan eerst de netwerktopologie en eventuele attribuutregels op de apparaatslaag uit te schakelen voordat je deze bewerkingen toepast.
Zodra je de bewerkingen toepast, ontstaan er dirty areas in jouw netwerk die gevalideerd moeten worden. Herhaal dit proces voordat je jouw bewerkingen valideert om apparaten die Enabled/Gesloten moeten zijn te identificeren. Dit komt omdat Enabled een netwerkattribuut is; wijzigingen eraan moeten gevalideerd worden via de Validate Network Topology-tool. Zodra alle dirty areas gevalideerd zijn of wanneer jij jouw netwerktopologie opnieuw inschakelt, zullen jouw traces deze nieuwe waarde respecteren.
Nu we verschillende technieken hebben besproken voor het modelleren van apparaatstatussen in een elektrisch netwerk, bekijken we hoe het utility network circuits modelleert en waarom ze subnetworks noemen.
Elektrische Fasering
Het beheren van de geactiveerde fasen is een belangrijke vereiste voor tracing en analyse voor veel elektrische klanten. Als u de fasering van elke lijn en elk apparaat in uw systeem bijhoudt, moet u deze stappen volgen om uw fase-informatie in uw netwerk op te nemen zodat u deze kunt gebruiken tijdens tracing en analyse.
Om deze configuratie uit te voeren, moet u de volgende informatie identificeren:
- Welke klassen en velden bevatten fasering?
- Geeft u fasering weer met een gehele waarde?
- Welke domein gebruikt u om fasering weer te geven?
Met deze informatie kunt u een netwerkattribuut maken en toewijzen dat wordt gebruikt om fasering in uw netwerk bij te houden. Het eerste wat u nodig hebt, is een gecodeerd waardedomein om alle combinaties van fasen in uw systeem weer te geven. Omdat het utility network fasering berekent en verspreidt met behulp van bitwise-bewerkingen, moet het veld een geheel getal zijn als u het wilt gebruiken om fase te beheren. Als het u niet uitmaakt om fasering te gebruiken voor kwaliteitsborging of analyse, maar alleen voor rapportagedoeleinden, kunt u het weergeven met een niet-geheel getal. Voor zowel de basis- als geavanceerde artikelen zullen we een geheel getal gebruiken met een gecodeerd waardedomein dat is ontworpen voor gebruik met bitwise-berekeningen, hieronder weergegeven, om fasering weer te geven. U kunt meer leren over hoe het utility network attributen verspreidt in de Attribuutverspreiding en attribuutsvervanging in subnetwerkbeheer artikel.
De volgende stap is ervoor te zorgen dat uw apparaat-, knooppunt- en lijnklasse elk een enkel veld hebben dat dit domein gebruikt om fase bij te houden. Zodra u dit hebt gedaan, bent u klaar om uw utility network zo te configureren dat dit veld wordt gebruikt.
Eerst voegt u een netwerkattribuut toe aan uw netwerk met behulp van de tool Netwerkattribuut toevoegen. Overweeg deze herschrijving: Zoals bij veel beheertools voor utility networks, is het noodzakelijk om uw netwerktopologie uit te schakelen voordat u de tool kunt uitvoeren. Wanneer u het attribuut als inline markeert, moet u ervoor zorgen dat u het gegevenstype en domein kiest die u hierboven hebt geïdentificeerd.
Zodra u het netwerkattribuut aan uw utility network hebt toegevoegd, moet u het utility network vertellen welke klassen en velden overeenkomen met dit netwerkattribuut. Gebruik hiervoor de functie Netwerkattribuut instellen voor elke klasse in uw netwerk die fase beheert. Dit omvat meestal de Electric Device-, Electric Junction- en Electric Line-klassen in het netwerk.
Als dit is voltooid, kunt u dit veld gebruiken bij het uitvoeren van traces met uw netwerk. De gemakkelijkste manier om dit attribuut te gebruiken is als filter of barrière wanneer u uw netwerkelementen traceert. Hieronder staat een voorbeeld dat alle elementen retourneert die een A-fase hebben.
Opmerking: Als u het faserveld op veldniveau toewijst voor het overeenkomstige netwerkattribuut van uw klassen, ziet u een keuzelijst in plaats van dat u handmatig een nummer hoeft in te typen.
Dit is een handig rapportagemechanisme, maar als we willen dat het subnetwerk rekening houdt met de fasering bij het bepalen welke elementen geactiveerd zijn, moeten we extra configuratie uitvoeren. Dat onderwerp wordt besproken in het artikel over geavanceerde configuraties.
Maak een subnetwerk
De meeste elektrische distributiecircuits beginnen bij een stroomonderbreker of herinschakelaar die zich in een station bevindt. Alles stroomafwaarts van deze stroomonderbreker maakt deel uit van hetzelfde circuit. In terminologie van utility networks is het circuit een subnetwerk, omdat het een afzonderlijke subset van het netwerk is die belangrijk is voor analytische doeleinden. De apparaten die fungeren als bronnen/afvoeren voor een subnetwerk worden subnetwork controllers genoemd. In het geval van de meeste elektrische netwerken is de stroomonderbreker (of herinschakelaar) een subnetwork controller, en de meeste circuits hebben één enkele subnetwork controller. Op een hoger niveau is het distributiedomeinnetwerk brongebaseerd. Dit betekent dat de stroomonderbreker de bron van de stroomrichting is voor het subnetwerk en stroomopwaarts ligt van alle elementen in het subnetwerk.
We kunnen de omvang van een circuit bepalen door een verbonden trace uit te voeren, met barrières voor uitgeschakelde/geopende elementen en stroomonderbrekers. Hieronder staan de resultaten van een trace met deze configuratie, beginnend bij een stroomonderbreker:
Tot nu toe zijn alle uitgevoerde traces connectiviteitstraces geweest. Dat komt omdat je om upstream-, downstream- of isolatietraces uit te voeren subnetwerken gedefinieerd moet hebben. Er zijn twee manieren om subnetwork controllers in het utility network te creëren. De eerste is om het Subnetwork Controller Wijzigen venster te gebruiken om een element te selecteren en handmatig een subnetwerk aan te maken.
Terug naar ons oorspronkelijke voorbeeld. Omdat we weten dat stroomonderbrekers onze circuits regelen, hadden we de optie "Is Controller" moeten aanvinken voor die mapping in de Migrate To Utility Network-tool. Dit zal de resulterende assettypes in ons utility network configureren om als subnetwork controllers te fungeren. Als dat niet was gedaan, moeten we handmatig configureren dat het assettype stroomonderbreker mag fungeren als subnetwork controller volgens de instructies op de Subnetwork Controller Instellen pagina in de online help.
Zodra stroomonderbrekers mogen fungeren als subnetwork controllers, gebruiken we de tool Subnetwork Controller Wijzigen om de stroomonderbreker tot subnetwork controller te maken en valideren vervolgens het dirty gebied dat hierdoor ontstaat. We kunnen dan een subnetwerktrace uitvoeren voor dat circuit, met dezelfde conditiebarrières die we tot nu toe hebben gebruikt, en we krijgen dan de omvang van het circuit.
Opmerking: Als u geen conditiebarrières toepast voor ingeschakelde/apparaatstatus op uw trace, ziet u niet de juiste resultaten. We zullen bespreken waarom en hoe dit te corrigeren in de sectie Subnetwerkdefinitie.
We kunnen ook upstream- en downstreamtraces binnen dat circuit uitvoeren, en als we onze conditiebarrières toepassen zullen deze traces slagen.
Nu u begrijpt hoe subnetwerken handmatig worden gemaakt, is de volgende stap bekijken hoe u een verzameling subnetwork controllers kunt importeren in het utility network. Dit is een belangrijke stap voor veel elektrische netwerken omdat ze honderden of duizenden circuits/subnetwerken kunnen bevatten.
Subnetwerken Importeren
De tweede manier om subnetwerken te creëren is door een csv-bestand te importeren met informatie die alle subnetwerken in het systeem beschrijft. Beide benaderingen zijn geldig, maar voor de meeste elektrische klanten is het relatief eenvoudig om een csv-bestand te produceren waarin al hun subnetwork controllers worden gedefinieerd. U kunt meer leren over dit proces op de Subnetwork Controller Importeren pagina van de online help. In dit voorbeeld hebben we het volgende CSV-bestand gemaakt.
Zodra u dit CSV-bestand hebt ingevuld, gebruikt u de tool Subnetwork Controllers Importeren om het bestand in uw netwerk te importeren zodat de overeenkomstige elementen worden ingeschakeld als subnetwork controllers.
Na het importeren van onze subnetwork controllers moeten we de dirty gebieden op elk van de controllers valideren voordat ze als bron kunnen worden herkend. Zodra dit is gedaan, kunnen traces die afhankelijk zijn van subnetwork controllers zoals upstream-, downstream- en zelfs isolatietracing worden uitgevoerd
Zoals eerder besproken moeten we nog steeds handmatig conditiebarrières definiëren zodat open schakelaars onze traces stoppen voor onze subnetwerktraces werken. In de volgende sectie leren we hoe we met behulp van de tool Subnetwerkdefinitie instellen dit standaardgedrag kunnen maken voor al onze subnetwerktraces
Subnetwerk Trace Configuratie
Tot nu toe vereiste elke trace dat u een set conditiebarrières specificeert als onderdeel van de traceconfiguratie om ervoor te zorgen dat we correcte resultaten krijgen. Omdat we willen dat deze conditiebarrières automatisch worden toegepast elke keer dat we een trace uitvoeren, kunnen we gebruikmaken van de Subnetwerkdefinitie instellen tool om de definitie van onze subnetwerken aan te passen zodat deze conditiebarrières standaard worden opgenomen bij subnetwerkgebaseerde traces. Terwijl we de subnetwerkdefinitie aanpassen bespreken we ook het belang van enkele andere parameters in deze tool die u mogelijk wilt aanpassen.
De eerste stap bij het aanpassen van uw subnetwerkdefinitie is het selecteren van het netwerk, domein en tier die u wilt aanpassen. Zodra u deze keuzes hebt gemaakt vult de tool automatisch met de huidige subnetwerkdefinitie voor die tier.
Het eerste wat we moeten doen is onze conditiebarrières toevoegen aan onze subnetwerkdefinitie. Dit gebeurt door het parameter Conditiebarrières onder het gedeelte Subnetwerk Trace Configuratie van de tool in te vullen. Alle wijzigingen die worden aangebracht in het gedeelte Subnetwerk Trace Configuratie beïnvloeden de standaard traceconfiguratie die door het utility network wordt gebruikt bij analyse van deze tier van het netwerk.
Standaard voegt de Migrate To Utility Network-tool één conditiebarrière toe voor uitgeschakelde elementen.
In het vorige voorbeeld willen we nog een conditiebarrière toevoegen om Open apparaten als barrières te behandelen. Als we andere netwerkattributen hebben geconfigureerd die we als barrières willen gebruiken kunnen we die hier ook configureren.
Een andere belangrijke optie die u in dit gedeelte van de tool moet overwegen is of u containers, inhoud en structuren wilt opnemen in uw traceresultaten. Als u besluit structuren of containers binnen uw netwerk te modelleren stelt dit subnetwork traces in staat snel elementen te identificeren die door of ter ondersteuning van het subnetwerk zijn.
Deze configuratie voor subnetwerktraces stelt u ook in staat samenvattingen voor elk subnetwerk te definiëren. Deze samenvattingen stellen u in staat samenvattende statistieken tijdens uw traces te berekenen en als u een samenvattingsattribuut definieert kunnen resultaten worden berekend en opgeslagen op uw subnetwerklijn-element ten behoeve van rapportage. Een eenvoudig voorbeeld hiervan zou zijn om de totale geleiderlengte voor een circuit te berekenen zoals hieronder weergegeven.
Elke samenvatting die u berekent kost tijd tijdens traceer- en update-subnetwerken dus wees bewust hoeveel tijd wordt besteed aan samenvattingen berekenen versus welk voordeel ze bieden aan uw eindgebruikers. Zodra u uw configuratie voor subnetwerktraces hebt aangepast kunt u op uitvoeren klikken maar mogelijk wilt u ook andere secties van uw subnetwerkdefinitie aanpassen.
Geldige Elementen en Objecten
Een andere belangrijke sectie van de subnetwerkdefinitie is de sectie Geldige Kenmerken en Objecten. Dit bepaalt welke kenmerken mogen deelnemen aan subnetwerken voor deze laag. Wanneer je nieuwe assettypen aan je model toevoegt, is het belangrijk om je subnetwerkdefinities bij te werken om hiermee rekening te houden, anders krijg je fouten wanneer je subnetwerken bijwerkt die kenmerken bevatten met deze nieuwe assettypen.
Je zou ook moeten overwegen om de parameter Geaggregeerde Lijnen voor SubnetLine Feature Class bij te werken. Dit bepaalt welke geometrieën in aanmerking worden genomen bij het maken van de subnetwerklijnklasse. Standaard zal de utility network builder geen assettypen opnemen, wat betekent dat er geen subnetwerklijn wordt gegenereerd wanneer je subnetwerken bijwerkt. Je moet alleen assettypen selecteren voor deze parameter die middenspanning- en hoogspanningslijnen vertegenwoordigen. Selecteer niet al je assettypen voor deze parameter, omdat dit een aanzienlijke negatieve invloed heeft op de tekentijd van je subnetwerklijnlaag.
Opmerking: Kenmerken die niet zijn opgenomen in de subnetwerklijn worden nog steeds opgenomen in de samenvattende statistieken voor het netwerk, dus als je de lengte van je geleider wilt berekenen, overweeg dan het gebruik van een Samenvattingsfunctie in je traceerconfiguratie. Dit heeft het bijkomende voordeel dat je een filter kunt definiëren om afzonderlijke lengtes te berekenen voor middenspanning- en laagspanningsgeleiders.
Subnetwerkbeleid bijwerken
De laatste grote sectie van de subnetwerkdefinitie is het update subnetwerkbeleid. Dit geeft je controle over hoe subnetwerkinformatie wordt bijgewerkt binnen je utility network. Wijzigingen aan deze instellingen aanbrengen is voor veel klanten geen eenvoudige beslissing, omdat het afwegingen inhoudt tussen gemak en prestaties. We geven hier een korte overzicht van deze beslissingspunten en verwijzen je naar uitgebreidere discussies waar beschikbaar.
Het eerste en gemakkelijkste punt om te bespreken is of structuur-/domeinnetwerkcontainers moeten worden bijgewerkt. Als je subnetwerktraceerconfiguratie structuren/containers bevat, zie je hier opties of ze moeten worden bijgewerkt. Dit bepaalt of de subnetwerknaam, ondersteunde subnetwerknaamvelden op je structuren en containers worden bijgewerkt wanneer ze een kenmerk bevatten of ondersteunen dat tot een subnetwork behoort. Dit stelt je in staat om de tool selecteren op attributen te gebruiken om kenmerken te identificeren die een subnetwork ondersteunen zonder een trace uit te voeren. Hoewel dit handig is voor rapportagedoeleinden, betekent het ook dat update subnetwerk langer duurt omdat er mogelijk honderden duizenden extra kenmerken moeten worden bijgewerkt.
De volgende optie om te bespreken is of de laag het IsDirty-veld moet beheren, je kunt een diepgaande uitleg over statusbeheer vinden op de Esri Community-site. Dit veld wordt gebruikt om aan te geven of er bewerkingen zijn gevalideerd in je utility network die een bepaald subnetwork hebben beïnvloed. Deze optie wordt door de utility network builder op false gezet omdat het prestatie-impact kan hebben.
Als deze eigenschap is ingeschakeld, moet het utility network elke keer dat je bewerkingen valideert één of meer traces uitvoeren om te identificeren welke subnetwerken zijn beïnvloed. Omdat de meeste elektrische circuits slechts enkele duizenden kenmerken bevatten, zijn deze kosten meestal relatief klein vergeleken met de voordelen voor kwaliteitsborging. Je moet echter overwegen deze eigenschap uitgeschakeld te laten als je subnetwerken tienduizenden of honderdduizenden kenmerken bevatten.
Het inschakelen van deze eigenschap stelt je in staat om je kwaliteitsborgingsinspanningen te richten op alleen de subnetwerken die zijn gewijzigd en maakt het gemakkelijk om te identificeren welke circuits schoon zijn en klaar om geëxtraheerd te worden naar een extern systeem zoals een OMS.
De meest prestatiegerichte configuratie is om deze optie uitgeschakeld te laten. De configuratie die het meest voordelig is voor kwaliteitsborging en integraties is het inschakelen van statusbeheer.
De laatste optie om te overwegen is welke eventing-modus moet worden gebruikt voor standaard- en benoemde versies. Dit beïnvloedt de prestaties van update subnetwerk en of het subnetwerkveld wordt gevuld tijdens bepaalde workflows. Er is een diepgaande uitleg over eventing-modi op de Esri Community-site. Hieronder volgt een sterk vereenvoudigde versie van de discussie.
Wanneer een subnetwork wordt bijgewerkt zonder events, gaat dit sneller. Dit komt door verschillende factoren, maar één reden is dat attribuutregels en editor tracking niet worden geactiveerd. Het grootste nadeel van dit gedrag is dat wanneer update subnetwerk wordt uitgevoerd in een benoemde versie, niet gegarandeerd is dat alle kenmerken hun subnetwerknaam bijwerken om overeen te komen met het subnetwork waartoe ze behoren.
Wanneer een subnetwork wordt bijgewerkt met events, duurt de eerste update subnetwerk-operatie langer. Latere updates kunnen ook langer duren als je attribuutregels hebt geconfigureerd en grote aantallen kenmerken bijwerkt. Het voordeel van het bijwerken van subnetwerken met eventing ingeschakeld is dat wanneer update subnetwerk wordt uitgevoerd in een versie, gegarandeerd kan worden dat het subnetwerknaamkenmerk correct wordt gevuld voor alle kenmerken die tot dat subnetwork behoren.
Opmerking: Bij ArcGIS Enterprise 11.4 en ArcGIS Pro 3.4 kan de prestatiekost van het activeren van attribuutregels worden verminderd door gebruik te maken van het nieuwe Triggering Fields gedrag van attribuutregels.
De meest prestatiegerichte configuratie is om de eventing-modus in te stellen op bijwerken zonder events. De meest nuttige configuratie voor kwaliteitsborging is om de eventing-modus in te schakelen wanneer in benoemde versies en ervoor te zorgen dat je triggering fields correct hebt geconfigureerd op al je attribuutregels.
Conclusie
Nu je dit artikel hebt voltooid, heb je de basis geleerd over hoe tracing en netwerkattributen kunnen worden geconfigureerd om analyses uit te voeren met behulp van je elektrische netwerk. Je hebt ook gezien hoe je subnetwerken kunt maken waarmee upstream-, downstream- en isolatietracing kunnen worden uitgevoerd. Je hebt ook geleerd hoe je je subnetworkdefinitie kunt aanpassen om gebruik te maken van je netwerkattributen. Wanneer je klaar bent om meer geavanceerde configuraties te leren, lees dan het artikel over geavanceerde configuraties van elektrische netwerken.
Als je meer wilt weten over het gebruik van het utility network voor het beheren van elektrische netwerken, verken dan alsjeblieft de Learn ArcGIS Utility Network for Electric Utilities serie. Deze leerserie bevat tutorials en artikelen die demonstreren hoe aan de behoeften van de elektriciteitsindustrie kan worden voldaan met behulp van het utility network.
Download en leer meer over de Migration toolset en de Migrate to Utility Network tool in het Beginnen met de Migration toolset artikel. Zoals altijd, als je vragen of opmerkingen hebt, stel ze dan zeker op de Esri Community site!
