Provozní bezpečnost dispečerských center

Provozní kontext

Náš stále více technologický svět je svou podstatou závislý na provozu různých technických řešení a tento trend se stále zvyšuje. Fenoménem posledních let je navíc provozování technických řešení formou externí služby (síťové služby, cloudová řešení), což činí situaci z provozního pohledu ještě rozmanitější. Proto je z pohledu zodpovědného provozovatele účelné se zabývat krizovými scénáři pro možné mezní situace a to především u kritické infrastruktury, kterou je dodávka pitné vody.

O technické odolnosti systému vůči různým poruchám technického prostředí dispečinku hovoříme v tomto článku jako o provozní bezpečnosti. V případě dispečerského systému jsou pro zachování dálkového řízení a ovládání zásadní dvě schopnosti – jednak chod center řízení a jednak dostupnost komunikačního prostředí. Pro celkovou šíři tohoto téma, se v příspěvku zaměříme na chod dispečerských center a komunikačního prostředí dispečerských pracovišť navazujících na servery telemetrie. Nebudeme se zde tedy zabývat provozní problematikou přenosových sítí telemetrie ani koncovými jednotkami.

Pro bližší pochopení vzájemných souvislostí si připomeneme složení dispečerského systému. Dispečerský systém je ve svém celku tvořen pěti základními součástmi. Dispečerských center se přímo týkají první tři:

• Servery telemetrie s aplikací SCADA software v provozních uzlech s řídícími radiomodemy pro dálkové měření a ovládání objektů nebo ASŘ technologie provozního objektu. Server může být v roli hlavního nebo záložního stroje.
• Dispečerská pracoviště pro operativní řízení vodárenského provozu
• Počítačová síť (ICT infrastruktura), která slouží jako páteřní komunikační platforma pro integraci serverů, komunikačních uzlů telemetrie, pracovišť operátorů a pracovních stanic koncových uživatelů dispečinku do jedné soustavy.
• Přenosové sítě dálkového měření a ovládání (Radiové datové sítě privátní i mobilních operátorů). Přenosová síť provádí komunikační propojení jednotlivých telemetrických stanic s nadřazeným dispečerským centrem nebo mezi sebou navzájem.
• Koncová zařízení telemetrie (RTU nebo místní SŘ ÚV a ČOV). Telemetrické zařízení (u větších objektů instance místního SŘ) provádí základní funkce dálkového měření a ovládání včetně začlenění provozního objektu do dispečerského systému.

Propojení a zachování funkční integrity těchto součástí je předmětem následujících kapitol. Pokud hovoříme o provozní odolnosti v tomto článku, máme na mysli využití náhradního technického řešení včleněného do infrastruktury dispečinku pro případ výpadku některé z hlavních součástí dispečerského systému. Moderní SCADA systémy (např. Retos.net) umí mechanismy provozní odolnosti využívat a lze na jejich platformě budovat odolné architektury dispečerských systémů, založených na pružné infrastruktuře dispečinku.

Vymezení rizik

Pro udržení integrity dispečerského celku je klíčové zejména udržení kontinuity provozu instance SCADA serveru, která kromě automatického řízení stanovuje všechny podstatné definiční a řídící parametry, zachycující požadované chování řízené soustavy. Dynamické hledisko je v procesním pohledu na navrhované řešení zásadní, protože soubor parametrů řízení dispečinku má proměnlivou podobu.

Bezpečnostní kritéria jsou obecně pro dispečink stanovena takto:

• Trvalá dostupnost dispečinku (365/7/24).
• Řízení přístupu k datům a funkčním rolím na základě přístupových hesel.
• Zabezpečení dat před ztrátou.

V následujícím textu se soustředíme na kritické prvky. Na provoz dispečerského centra mohou mít devastující účinky zejména dvě události – jednak vlastní porucha na SCADA serveru, který řídí komunikaci s koncovými objekty i dispečery a jednak výpadek služeb počítačové sítě, která zabezpečuje konektivitu dispečerských pracovišť se serverem a potažmo i mezi servery navzájem.

Výpadek síťových služeb pak ještě z praktických důvodů rozlišíme na dvě samostatné situace. První je stav, kdy z důvodu např poruchy síťového prvku (routeru nebo přepínače) nemá určitý segment sítě přístup k doménovému řadiči a výsledkem je provozní stav, ve kterém je sice daný segment po technické stránce schopen síťové komunikace i datové výměny, nicméně nedostupnost domény neumožňuje běžný síťový provoz. Druhá situace pak zachycuje úplný výpadek, bez technické schopnosti komunikace v postiženém segmentu.

1. Riziko výpadku serveru telemetrie
2. Riziko výpadku počítače sítě
   
   1. Výpadek řadiče domény počítačové sítě
   2. Výpadek jednoho či více segmentů počítačové sítě

Navrhovaná opatření se tedy v prvé řadě logicky soustřeďují zejména na chod a provozní dostupnost serverů telemetrie a komunikačního prostředí.

Porucha serveru telemetrie

Poruchu serveru můžeme charakterizovat jako nedostupnost nebo nečinnost serveru na hlavní a současně i záložní IP adrese.

Pro tuto situaci se nabízí triviální řešení, kterým může být záložní SCADA server. Základním problémem u záložních SCADA serverů je skutečnost, že soubor parametrů řízení dispečerské soustavy má dynamický charakter, protože i hydrotechnické děje mají charakter nepřetržitého, proměnného procesu a návazně se i řídící parametry dynamicky mění dle stavu soustavy. Hlavní i záložní server zapojené do technologického řízení musí umět mezi sebou sdílet data i řídící prostředky, což v praxi obnáší tyto tři základní datové a komunikační entity:

• Aktuální soubor parametrů řízení soustavy
• Databázi provozních dat
• Přístup k přenosovým sítím telemetrie

V praxi jsou užívané různé provozní formace zálohovaných serverů – „horká“ nebo „studená“ záloha. Pro provozně citlivé aplikace se používá řešení SCADA serveru v bezvýpadkové (fault tolerantní) sestavě, tvořené dvojicí počítačů v horkém záskoku. Což ale není u většiny provozovatelů časté díky finančním nákladům. Častější variantou zejména u středních vodárenských společností je provoz SCADA centra ve virtuálním prostředí, která řeší zálohování technických prostředků serverů efektivnějším a z pohledu potřeb vodárny komplexnějším způsobem.

Použití virtuálního prostředí je vhodnější, protože umožňuje efektivněji zálohovat technické prostředky a je proto často využíváno v současné praxi, neboť výrazně urychluje dobu obnovy celé řídící instance po poruše hardware. Z pohledu SCADA software však samo o sobě není úplným řešením, protože při provozu SCADA serveru se dynamicky mění soubor řídících parametrů, což vyžaduje i nasazení mechanismu průběžného zálohování těchto dat mimo tuto strukturu.

U větších soustav s více SCADA servery není sestava s horkými zálohami strojů efektivní ani po technické stránce, protože v případě více serverů je třeba navíc řešit i s tím spojený stav měnící se topologie řídících prostředků, která zachycuje řídící prvky zapojené do systému řízení a jejich aktuální stav – role hlavního resp. záložního prostředku. U dispečerských soustav s hlavními a záložními servery musí být součástí systému i instance, která bude v každém okamžiku pro všechny uživatele dispečerského systému určovat, který server/komunikační segment je v daném čase hlavní a který je záložní, aby bylo jednoznačně stanoveno, kam mají operátoři dispečinku směrovat pokyny na provádění dispečerského řízení. Topologie infrastruktury řízení má tedy rovněž dynamický charakter. Rozebereme si tento problém podrobněji.

Sestava s horkou zálohou je řešením, kdy řídící počítač má svoje dvojče – plně vybavenou technickou zálohu, která je schopna, v případě poruchy hlavního stroje, téměř okamžitě převzít jeho roli v plném rozsahu. Sestavou tzv. „horké zálohy“ jsou zabezpečeny velíny úpraven vod a dispečinky střední velikosti, kdy se předpokládá minimální doba výpadku. Tyto soustavy mají zpravidla jediné centrum řízení a tak vyšší náklady na dosažení provozní odolnosti zdvojením prostředků mají smysl.

Možným řešením pro rozsáhlé celky se soustavou skupinových vodovodů a hierarchií dispečerských center je architektura s více SCADA servery v provozních uzlech a jednou sdílenou záložní instancí. Proces záložního řízení v takovém systému probíhá kontinuálně v několika rovinách.

Sestava se sdíleným záložním centrem. Záložní centrum je tvořeno v minimální podobě záložním serverem telemetrie (SCADA) a dispečerskou stanicí. Každá produktivní instance serveru telemetrie cyklicky vytváří záložní klon konfiguračních souborů SCADA, který bude ukládán na stanovené síťové uložiště dostupné ze záložního centra.

Dostupnost serverů je automaticky ověřována prostředky SCADA Retos_Topology. Tento modul s webovou aplikací udržuje a prezentuje stav a identitu hlavních a záložních prvků topologie systému. Výpadek služeb serveru je v podstatě okamžitě identifikován příslušným dispečerským pracovištěm s trvalou obsluhou, která ověří, zda se jedná o výpadek komunikačního spojení nebo o výpadek serveru a které komunikační adresy jsou dostupné.

Pro případ výpadku kteréhokoliv ze serverů systému je v infrastruktuře dispečinku připravena sdílená instance záložního SCADA serveru s předinstalovanými prostředky v rozsahu systémové platformy. Správce dispečinku po výpadku spuštěním nástroje Retos_Recovery a příslušného záložního souboru v několika minutách vytvoří ze záložního stroje plnohodnotný funkční klon původního stroje. Následně přepne záložní server do role hlavního stroje, který zcela převezme kompetence řízení serveru v poruše. Předpokladem, je komunikační dostupnost příslušných modemů pro řízeni přenosových sítí pro záložní instanci. Okamžikem aktivace komunikačního spojení s příslušným modemem přebírá záložní server roli hlavního prostředku řízení dané oblasti.

Protože se změnila identita řídícího serveru telemetrie je třeba aktualizovat role dotčených serverů (hlavní/záložní) v návaznosti na potřeby dispečerských pracovišť. Základní varianta procesu předání kompetencí je založena na faktu, že každý dispečerský klient Retosu má v konfiguraci uloženo, se kterými servery je oprávněn pracovat. Při této základní variantě jsou změny identifikace serverů (IP adresa) prováděny na klientských pracovištích manuálně správcem.

Vzdálené připojení přenosových sítí. Pružné uspořádání dispečerského systému zachovává základní strukturu přenosových sítí včetně přístupových bodů. Připojení přenosových sítí k serverům telemetrie ale musí být provedeno nikoliv přímo (server – lokální datové rozhraní – radiomodem), ale po ethernetu přes komunikační převodníky ethernet/sériová linka (server sériových portů). Toto opatření je předpokladem vzdáleného managementu přidělení řídících kompetencí daného modemu k libovolnému serveru.

Výpadek počítačové sítě

Komunikační prostředí počítačové sítě je pojícím tmelem zajišťujícím integritu celého dispečerského prostředí při běžném provozu. Vhodně navržený dispečerský systém může být udržitelný v provozu i při výpadku páteřní počítačové sítě, byť v omezené míře a za snížení uživatelského komfortu i výkonnostních parametrů. Jak je uvedeno výše, budeme se zabývat dvěma základními situacemi.

Provoz dispečinku po výpadku doménového řadiče

Běžné produkty SCADA serverů používají pro ověření oprávnění přístupu uživatelů přímo služeb doménového řadiče (je to z pohledu správy provozu IT nejefektivnější řešení). Podstatné je, že přístupová práva v dispečerském systému jsou spojena s každou instancí technologického serveru.

Některé verze SCADA software např. Retos umí bez výpadku pracovat i za situace kdy je doména nedostupná. Umožnuje to samostatná ověřovací autorita, provádějící autentifikaci lokálních uživatelů dané serverové instance Retosu, vlastním procesem nezávisle na chodu domény a při plném komfortu správy sítě.

Po výpadku domény totiž přestanou fungovat doménové účty v síti a využívání služeb sítě na základě běžných identit uživatelů se stane nemožným. Možné řešení vychází ze předpokladu, že pokud jsou technické prostředky hlavní sítě funkční, je možný provoz dispečinku na páteřní síti za pomocí statických IP adres. Toho lze dosáhnout náhradou doménových služeb ověřováním lokální autorizační instancí na serverech telemetrie a uživatelé na všech dispečerských pracovištích se musí po výpadku přihlásit pod lokálními účty.

Provoz dispečinku po výpadku segmentu páteřní počítačové sítě

Odpovědnost za provoz služeb počítačové sítě má i ve vodárenské společnosti zpravidla na starosti IT oddělení. Pro potřeby zachování kontinuity dispečerských funkcí je však vhodné aby i řešení počítačové sítě zahrnovalo prvky provozní odolnosti. V minimálním rozsahu by mezi hlavními součástmi dispečerského systému měla existovat i záložní počítačová síť a prostředky dispečinku by mělo být monitorováno napájení využívaných síťových prvků (routery přepínače). Současně je potřeba aby pracovní stanice dispečinku byly předkonfigurovány na provozní režimy po záložní síti a bez domény. Jedná se zejména o přípravu lokálních účtů a k nim přiřazených oprávnění vzhledem k akcím a datům dispečerských serverů.

Záložní komunikační síť

Záložní datové spojení je v trvalém provozu souběžně s hlavním síťovým prostředím. Každý server telemetrie má ve vnitřní síti dvě statické IP adresy, jednu v hlavní počítačové síti a druhou v záložní komunikační síti. Dispečerské servery jsou v pružné architektuře přímo adresovatelné po IP adresách na hlavním nebo záložním spojení.

V případě komunikačního výpadku přesměruje dispečer připojení svého pracoviště na záložní spojení a provoz dispečinku může pokračovat prakticky v plném rozsahu s možnými pomalejšími reakcemi systému (v závislosti na přenosové kapacitě a zatížení záložní linky).

Ostrovní režim

V případě úplného rozpadu páteřní sítě, přechází obsluha dispečerského systému do lokálního režimu v rámci spádové oblasti. V tomto režimu zůstávají v provozu ostrovy místních sítí v centrech provozních uzlů zahrnující server telemetrie, pracovní stanice dispečera a řídící modemy přenosových sítí. Funkce automatického řízení serveru telemetrie i schopnost dálkového ovládání zůstávají zachovány.

Reakcí na výpadek je přihlášení se dispečera pod lokálním účtem, nezávislým na doménovém ověření. Pro tento případ je na každém pracovišti krizového řízení vytvořen účet „havarijního uživatele“, který dovolí plnohodnotný přístup k místnímu serveru telemetrie.

Závěr

V předchozím textu jsme si ukázali, že provozní odolnosti dispečerských systémů můžeme efektivně dosáhnout za pomoci architektury pružného uspořádání, která je tvořena: servery telemetrie (hlavní a záložní), dispečerskými pracovišti (hlavní a záložní), modemy řízení přenosových sítí a páteřní počítačovou sítí s redundantní architekturou.

Při návrhu firemní strategie zajištění provozní odolnosti je důležité zvážit odpovědi na tuto základní otázku:

Jak dlouho se obejdeme při řízení výroby a dodávky pitné vody bez chodu dispečerského centra?

Od odpovědi se pak odvíjí technické parametry návrhu vlastního řešení.

Při návrhu řešení je třeba vzít v úvahu i skutečnost, že zavedení prvků provozní odolnosti do technické infrastruktury znamená zákonitě i nárůst technické složitosti celého řešení. Je tedy potřeba i zachovat rozumnou míru pro udržení provozuschopnosti takto komplexního soustavy.

Za žádoucí je rovněž potřeba považovat pravidelné procvičování provozních dovedností obsluh při užití provozních postupů v mezních situacích (krizové scénáře) spojené s využitím záložních technických prvků. Což zajistí i průběžnou kontrolu provozuschopnosti záložní infrastruktury.