Když byla utility síť poprvé vydána, představila nový koncept do ekosystému a slovníku Esri, Podsíť. Tato abstrakce byla vytvořena k popisu různých způsobů, jak uživatelé oddělují a spravují své sítě do síťových zón bez použití odvětvově specifických termínů jako ‚Obvod‘ nebo ‚Tlaková zóna‘.
Proč ale používáme termín „podsíť“?
Všechna data používaná ke správě konektivity pro jednu sadu zdrojů utility jsou uložena v utility síti (např. síti). Když je tato síť rozdělena na menší, topologicky souvislé oblasti (obvody, tlakové zóny atd.), může být každá z těchto zón přesně popsána jako podsíť. S touto abstrakcí byl vytvořen rámec pro správu každé podsítě jako samostatného GIS objektu, který lze vizualizovat, analyzovat a dokonce použít pro účely reportování. Důležitou součástí tohoto rámce je schopnost sledovat metadata o každé podsíti, aby uživatelé mohli pochopit, jak se jejich systém v průběhu času mění.
Tato metadata poskytují základní informace jako pole sledování editoru nebo mohou být rozšířena o uživatelem definované hodnoty, například počet zákazníků, počet ochranných zařízení atd. Metadata také umožňují uživatelům odpovědět na nejčastější a nejdůležitější otázku, kterou GIS pracovník dostává: jsou tato data správná?
To je překvapivě obtížná otázka, protože správnost znamená pro různé lidi různé věci. Nicméně rozdělením původní otázky na konkrétnější otázky je mnohem snazší odpovědět:
- Kdy byla podsíť naposledy aktualizována?
- Kdy byla podsíť naposledy exportována do jiného systému?
- Je tato podsíť aktuální?
- Byly prvky v podsíti upraveny od poslední aktualizace?
- Jsou v této podsíti známé chyby, které je třeba opravit?
První dvě otázky lze snadno zodpovědět pomocí několika datových polí udržovaných u podsítě, konkrétně polí Poslední aktualizace podsítě a Poslední potvrzený export podsítě. Na poslední tři otázky lze odpovědět pohledem na Stav pole podsítě (v dřívějších modelech nazývané ‚Je špinavá‘), které obsahuje stavové hodnoty Čistý, Špinavý a Neplatný. Zde je význam těchto hodnot:
- Čistý – Podsíť bez známých chyb, připravená k analýze.
- Špinavý – Podsíť byla upravena a je potřeba ji aktualizovat.
- Neplatný – Podsíť má jednu nebo více známých chyb, které je třeba vyřešit.
S tímto základem se zbytek tohoto článku zaměří na to, jak systém spravuje pole Stav a jak interpretovat jednotlivé stavové hodnoty.
Označování podsítí jako špinavých
Klíčem ke správě stavu podsítí v utility síti je schopnost systému určit, kdy byla podsíť ovlivněna úpravou, aby mohla být označena jako špinavá. I když existuje mnoho způsobů, jak toho dosáhnout, software v současnosti používá operaci validace topologie sítě k objevení a označení podsítí jako špinavých. Protože určení, která podsíť byla úpravou ovlivněna vyžaduje trasování, bylo by příliš náročné provádět tuto analýzu po každé úpravě během editace. Nakonec protože všechny editační postupy ovlivňující síť musí být validovány, umožňuje to systému zajistit, že stav podsítí nemůže být nesynchronizovaný s daty během jejich úprav.
Jak ale systém určí, které podsítě byly upraveny?
Systém provede trasu kontroloru podsítě pro všechny validované prvky, aby zjistil, které podsítě byly úpravami ovlivněny. Přesné chování se mírně liší podle toho, zda validované úpravy patří do rozdělené nebo hierarchické utility sítě. Co tyto pojmy znamenají a proč je to důležité? To si vysvětlíme níže.
V rozdělené podsíti může každý prvek patřit maximálně do jedné podsítě. To znamená, že systém analyzuje každou vrstvu sítě, aby zjistil, zda některý z upravených prvků patří do této vrstvy. Jakmile je prvek přiřazen ke konkrétní podsíti, může být vyřazen z analýzy v následujících vrstvách a jakmile jsou všechny prvky přiřazeny, analýza končí i když nebyly analyzovány všechny vrstvy. Zjednodušený příklad rozdělené sítě můžete vidět níže:
V případě hierarchické sítě může každý prvek patřit do více podsítí protože vrstvy sítě jsou do sebe vnořené. Výsledkem je, že systém musí vždy analyzovat každou vrstvu sítě pro všechny upravené prvky. Zjednodušený příklad hierarchické sítě vidíte níže:
Nyní když jsme si na vysoké úrovni prohlédli různé typy topologií, podíváme se na několik editačních scénářů pro každý z těchto typů topologií a poznamenáme si chování systému.
Rozdělená
Když je topologie sítě validována v rozdělené síti, systém musí identifikovat podsíť ovlivněnou každou úpravou. K tomu identifikuje všechny vrstvy v síti obsahující podsítě a analyzuje každou vrstvu k určení které podsítě v dané vrstvě byly úpravou ovlivněny. Tento proces opakuje u každé vrstvy dokud nenajde zdroje sítě pro všechny upravené prvky nebo dokud nejsou analyzovány všechny vrstvy v síti. Podíváme se na několik příkladů tohoto chování v praxi.
V prvním příkladu níže je provedena jedna úprava utility sítě (fialový hash polygon). Když proběhne validace topologie sítě najde jeden zdroj sítě pro úpravu v první analyzované vrstvě – distribuční vrstvě. To umožňuje validaci přeskočit analýzu přenosové vrstvy protože systém již našel kontrolor podsítě pokrývající všechny úpravy.
Ve druhém příkladu jsou validovány více úprav ve více různých oblastech sítě. Systém musí provést více trasování k nalezení zdrojů všech úprav protože tyto úpravy proběhly ve více vrstvách sítě.
Ve třetím příkladu systém validuje úpravu prvku nepřipojeného k žádné podsíti. V tomto případě musí systém trasovat všechny vrstvy sítě aby potvrdil že žádná podsíť nebyla ovlivněna.
Jak vidíte, operace validace topologie sítě dokáže rychleji identifikovat upravené podsítě v rozdělených sítích pokud jsou úpravy omezeny na jednu vrstvu a pokud jsou upravené podsítě menší. S rostoucím počtem vrstev a velikostí podsítí trvá systému déle identifikovat upravené podsítě během validace topologie protože musí provést více trasování a ty budou trvat déle.
Hierarchická
Protože každý prvek v hierarchické síti může patřit do více vrstev, musí systém při identifikaci ovlivněných podsítí během validace topologie zvážit každou vrstvu obsahující podsítě.
Níže vidíte příklad jednoduché hierarchické sítě obsahující jednu systémovou podsíť se dvěma menšími podsítmi.
V prvním příkladu níže je upraven prvek patřící do jedné z menších podsítí. Systém nejprve identifikuje menší podsíť ke které úprava patří. Protože se jedná o hierarchickou podsíť musí však systém analyzovat i všechny zbývající vrstvy sítě a v tomto případě identifikuje druhou podsíť v jiné vrstvě k označení jako špinavou.
Ve druhém příkladu je upraven prvek patřící výhradně do větší podsítě. V tomto případě nižší pořadové podsítě nejsou označeny jako špinavé protože úprava neovlivnila žádnou z nich. Tato logika platí bez ohledu na to zda je síť založena na zdroji nebo cíli protože nejvyšší pořadová síť je vždy nejvnější kontejner v hierarchii (konečný zdroj nebo konečný cíl sítě).
Ve třetím příkladu je upraven prvek nepatřící do žádné podsítě. V tomto případě nejsou žádné podsítě označeny jako špinavé. Nicméně utility síť musí trasovat každou vrstvu sítě aby potvrdila že prvek nepatří do žádné podsítě.
Protože systémové podsítě jsou tak velké mohou přidat větší výkonovou zátěž při validaci topologie než menší podsítě. Také protože tyto podsítě obsahují tolik prvků jsou častěji označovány jako špinavé během validace a proto často potřebují být aktualizovány mnohokrát denně aby zůstaly čisté. Proto je běžné nastavit nejvyšší vrstvy hierarchické sítě tak aby nespravovaly pole Stav a místo toho byly aktualizovány pouze jednou za noc. Kromě snížení frekvence aktualizací těchto sítí toto nastavení také zlepšuje výkon validace topologie protože umožňuje utility síti přeskočit tuto vrstvu během validace. Další část tohoto článku popisuje jak zjistit zda je vrstva nakonfigurována ke správě pole Stav.
Konfigurace
I když je správa pole Stav výchozím chováním u podsíťi v utility síti existují uživatelé i celé obory které nepoužívají stav podsíťi jako součást svých pracovních postupů. Pro podporu této konfigurace sekce Aktualizační politika podsíťi nástroje Nastavit definici podsíťi obsahuje možnost určit zda by měla odpovídající vrstva podsíti ‚Spravovat IsDirty‘.
Uživatelé, kteří se rozhodnou do tohoto chování (deaktivace správy stavu) nezapojit, to obvykle dělají ze dvou důvodů:
- Jejich pracovní postupy úprav vedou k tomu, že podsítě jsou vždy označeny jako špinavé, nebo...
- Dopady na výkon
Pamatujte, že toto nastavení je konfigurováno samostatně pro každou vrstvu ve vaší síti, takže můžete zvolit ponechat toto nastavení povolené pro některé vrstvy ve vaší síti (distribution, pressure zones atd.), zatímco ho deaktivujete pro jiné, větší vrstvy (transmission, system atd.).
Bez ohledu na to, jak je vaše síť aktuálně nakonfigurována, toto nastavení můžete kdykoli později změnit. Pokud máte model s tímto nastavením povoleným, můžete tuto možnost deaktivovat, pokud vám správa pole stavu nepřipadá užitečná. Pokud naopak máte model, který pole stavu nespravuje, ale později se rozhodnete využít pole stavu ve svých pracovních postupech, můžete jej povolit.
Ověřit konzistenci
Celá dosavadní diskuse se zabývala tím, jak, kdy a které podsítě jsou označeny jako špinavé při validaci špinavé oblasti. To samozřejmě vyvolává otázku; jak systém reaguje nebo identifikuje podsítě obsahující úpravy, které nebyly validovány? Zde vstupuje do hry myšlenka ověřování konzistence během analýzy.
Výchozí chování při provádění trasování v utility network je ověřit konzistenci výsledku trasování. Prakticky to znamená, že systém kontroluje, zda nejsou s výsledky trasování spojeny nějaké špinavé oblasti. Pokud žádné špinavé oblasti nejsou spojeny s vašimi výsledky, jsou výsledky považovány za konzistentní.
Pokud však jsou s výsledky trasování spojeny špinavé oblasti, trasování selže a obdržíte chybu informující vás o tom, že během trasování byly nalezeny jedna nebo více špinavých oblastí. Pokud chcete tyto špinavé oblasti ignorovat a zobrazit výsledky trasování i přesto, že mohou být nesprávné, můžete zrušit zaškrtnutí možnosti Ověřit konzistenci.
Jak se to vztahuje ke stavu podsítě? Pokud jsou během aktualizace podsítě nalezeny špinavé oblasti, podsíť bude označena jako špinavá. Čistá podsíť však může být konzistentní nebo nekonzistentní v závislosti na tom, zda obsahuje nevalidované úpravy od poslední aktualizace. Pokud jsou v databázi nevalidované špinavé oblasti, systém neví, kterou podsíť (pokud vůbec nějakou) označit jako špinavou do doby validace úprav. Jakmile jsou všechny špinavé oblasti validovány, odpovídající podsítě jsou označeny jako špinavé a všechna trasování budou konzistentní.
Jaký to má dopad na správu podsítí? Znamená to, že nelze nutně podle stavu podsítě poznat její konzistenci. Můžete si však být jisti, že pokud provedete trasování podsítě, obdržíte chybu při pokusu analyzovat nebo exportovat nekonzistentní podsíť i v případě, že stav podsítě uvádí čistotu.
Závěr
Nyní byste po přečtení tohoto článku měli lépe rozumět výhodám a pracovním postupům spojeným se správou podsítí a tomu, jak vám pole stavu pomáhá tyto postupy řídit. Měli byste také chápat, jak systém toto pole spravuje a proč si některá odvětví mohou zvolit spravovat pole stavu pouze pro některé vrstvy ve své utility network.
