IT/OT integrace při digitalizaci areálu: co chtít po dodavateli

Po dodavateli digitalizace areálu chtějte čtyři konkrétní odpovědi: jak bude síť periferií oddělená od podnikové sítě, kudy povede servisní přístup, co se stane při výpadku IT a kdo ponese odpovědnost za funkci celku. Digitalizace vjezdu totiž znamená, že provozní technika na bráně — závory, kamery, indukční smyčky, LED panely, turnikety — začne poslouchat software na serveru. A právě na švu mezi těmito dvěma světy, provozním (OT) a informačním (IT), projekty nejčastěji drhnou: ne na závoře a ne na databázi, ale na tom, jak jsou spojené.

Dva světy na jedné bráně

OT (Operational Technology, provozní technika) je v areálu všechno, co fyzicky koná: závora zvedá rameno, indukční smyčka zalitá ve vozovce hlásí kovovou hmotu vozidla, kamera dodává obraz, LED panel svítí, turniket pouští po jednom. IT je všechno, co rozhoduje a eviduje: aplikační server, databáze, webová administrace, síť, rozhraní na podnikové systémy.

Ty dva světy mají různý rytmus i různé správce. O závoru a smyčky se stará údržba nebo facility, o server a síť IT oddělení — a v běžném provozu se ti lidé potkávají málokdy. Digitalizace areálu je nutí potkávat se pořád, protože každé rozhodnutí „otevřít" vzniká v softwaru a vykoná se železem. Fyzickou sestavu na bráně popisuje stránka elektronické vrátnice; to, co z ní dělá jeden systém, je řídicí platforma PSA — průjezdový systém areálu, která integruje kiosky, kamery, IP vstupy a výstupy, LED panely i přístupové kontrolery a rozhoduje, kdo projede.

Když se OT a IT spojí bez pravidel, vzniknou dva typy problémů. Bezpečnostní: provozní zařízení zapojená přímo do kancelářské sítě jsou další cesta dovnitř. A provozní: když brána nejede, nikdo neví, jestli volat údržbu, IT, nebo dodavatele. Obojí se řeší návrhem — a obojí se u dodavatele pozná na čtyřech otázkách níže.

Sběrnice a definované porty: jak spolu ty světy mluví

Nejdřív ale k tomu, jak zdravé spojení vypadá. Na aplikačním serveru PSA běží celá IT vrstva řešení: webová administrace, MQTT broker jako sběrnice pro kiosky a periferie, lokální databáze a rezervační server pro předregistrace. OT prvky se serverem komunikují na vyhrazené síti a každý typ po definovaném portu:

Pro IT oddělení z toho plyne praktická věc: firewallová pravidla se dají napsat předem a přesně. Seznam portů má být součást nabídky a kompletní schéma segmentace se dodává ve fázi projektu. Dodavatel, který porty svého systému neumí vyjmenovat, přenáší tu práci na vaše IT.

Za pozornost stojí i dělba rolí mezi zařízeními, protože rozhoduje o tom, kde se hledá závada. Kamera v systému nedostává povel, jen dodává obraz: vozidlo najede na indukční smyčku (na každý jízdní pruh se instalují dvě), impulz zpracuje IP modul vstupů a výstupů — to on systému oznámí, že u brány někdo stojí — a teprve pak si PSA vezme snímek z videostreamu a rozpozná registrační značku pomocí LPR (License Plate Recognition, rozpoznávání značky z obrazu). Systém značku porovná s evidencí, ověří oprávnění a časové okno a otevře. Posloupnost smyčka → IP modul → server → závora je zároveň diagnostický postup: u každého kroku je jasné, jestli problém leží v OT, nebo v IT, a kdo ho má řešit.

Otázka 1: Jak je oddělená síť periferií?

Správná odpověď má tři části. Zaprvé: všechny prvky systému běží ve vyhrazené síti a provoz MQTT sběrnice nesmí mimo vyhrazený segment — kdyby byla kompromitována jedna periferie, nesmí se z ní dát pokračovat do podnikové sítě. Zadruhé: databáze běží lokálně na aplikačním serveru a není vystavená ven. Zatřetí: žádná komponenta systému není přímo dostupná z veřejného internetu. K tomu patří i pracoviště ostrahy — pro ni lze nasadit vyhrazenou operátorskou stanici, fyzicky i logicky oddělenou od kancelářské sítě.

Tady se digitalizace brány potkává s bezpečnostní regulací: proč přísná IT prostředí právě tyhle vlastnosti vyžadují a jak vypadá auditní stopa průjezdů, rozebírá článek co znamená NIS2 pro technologie na bráně. Tady zůstaneme u projektové praxe: oddělení periferií chtějte popsané v nabídce, ne slíbené ústně.

Otázka 2: Kudy vede servisní přístup?

Servisní přístup vede výhradně přes zabezpečenou VPN; uvnitř tunelu běží vzdálená správa (RDP 3389 nebo HTTPS 443). Trvale otevřený port do internetu „pro servis" neexistuje — a dodavatele, který ho požaduje, se ptejte proč.

Zbývá určit, čí VPN a čí firewall. To je jedno z prvních rozhodnutí projektu a existují dvě topologie podle toho, kdo drží perimetr:

• On-premise v DMZ. Všechny prvky PSA běží ve vyhrazené izolované síti uvnitř vaší infrastruktury. Perimetr řídí váš firewall, vzdálená správa jde přes vaši VPN a rezervační data z veřejného portálu tečou dovnitř šifrovaným tunelem.
• Oddělená síť dodavatele. Prvky PSA běží ve fyzicky oddělené síti nezávislé na vašem IT, perimetr drží router dodavatele a rezervační server je součástí aplikačního serveru. Vhodné tam, kde nechcete nebo nemůžete poskytnout místo ve vlastní síti.

Obě topologie nesou stejnou funkční sestavu; liší se jen tím, čí zařízení stojí na hranici. Volba je věc vaší bezpečnostní politiky a kapacity — a dodavatel má umět nabídnout obě.

Otázka 3: Co se stane při výpadku IT?

Otázka má dvě roviny. První je architektonická: o vjezdu se rozhoduje na aplikačním serveru v areálu, nad lokální databází — ne ve vzdálené službě, jejíž dostupnost nikdo na místě neovlivní.

Druhá rovina je procesní a je důležitější, protože výpadek nevyloučí žádná architektura: co udělají závory, když server nebo síť nepoběží? Vjezd se navrhuje tak, aby výpadek neznamenal zavřenou bránu — režimy pro otevření závor se definují podle pravidel provozovatele, včetně požárního scénáře napojeného na EPS. Chování při výpadku je součást návrhu procesů, ne dodatek. Po dodavateli proto chtějte, aby byl scénář výpadku v projektu popsaný dřív, než se kope první smyčka. Odpověď „server nepadá" není scénář.

Otázka 4: Kdo odpovídá za celek?

Nejčastější podoba IT/OT mezery není technická, ale smluvní: závory dodala jedna firma, kamery druhá, software třetí, síť je vaše. Dokud všechno jede, nevadí to. Když brána stojí, ukazuje každý na druhého — a rozdíl mezi hodinou a dny prostoje dělá právě to, jestli za funkci celku někdo ručí.

Chtít můžete dvojí. Buď jednoho dodavatele, u kterého jsou platforma i technika jeden systém — u SECAPRO jsou software i konstrukce vlastní vývoj a PSA integruje kiosky, kamery, IP moduly, LED panely i přístupové kontrolery jako jeden celek. Nebo, pokud část techniky v areálu už stojí, přesně popsané hranice odpovědnosti: systém se umí přes strojové rozhraní zabezpečené API klíčem i tokenem napojit i na cizí brány, závory a kiosky — externí zařízení může nahlásit vjezd, dotázat se na povolení podle SPZ nebo řídit průjezd. Co je za rozhraním, ale zůstává odpovědností toho, kdo zařízení provozuje. Jaké operace má API deklarovat a na co se u něj ptát, rozebírá článek API elektronické vrátnice.

Stejné pravidlo platí směrem do podnikových systémů. Docházka, ERP a WMS, mostové váhy, plánování dopravy nebo Outlook se napojují postupem „nejdřív ověřit, potom slíbit": před příslibem se chce vidět dokumentace rozhraní protistrany a vědět, kdo je za ni na vaší straně odpovědný; vývoj rozhraní se vede jako samostatná položka rozpočtu, ne skrytě v ceně licence. Výčet napojení a podmínek shrnuje stránka integrace na podnikové systémy.

Odpovědnost za celek tedy neznamená, že jeden dodavatel ručí za všechno ve firmě. Znamená, že u každého prvku a každého rozhraní je před podpisem napsáno, kdo ho drží — a že za sestavu brány jako funkční celek odpovídá jeden subjekt, ne průsečík tří záruk.

Kdy to nedává smysl

• Když na bráně není co integrovat. Jedna závora ovládaná tlačítkem, pár pohybů denně a žádný požadavek na evidenci — plnohodnotná řídicí platforma se nevyužije a šev mezi IT a OT tu prakticky neexistuje.
• Když je zadání „žádný server v areálu". Popsaná architektura stojí na aplikačním serveru s lokální databází. Kdo vyžaduje čistě cloudovou službu bez lokálního prvku, hledá jiný typ řešení — s jinými kompromisy, které je fér pojmenovat.
• Když nemá kdo držet perimetr a oddělenou síť dodavatele odmítáte. Jedna z topologií se zvolit musí. On-premise bez správce firewallu a VPN je segmentace jen na papíře; když nepřipadá v úvahu ani síť dodavatele, projekt nemá kde stát.
• Když stávající technika nemá přístupné řízení. Napojení cizí závory nebo brány předpokládá, že její řízení je dokumentované a přístupné. Když ho výrobce nezpřístupní, zbývá výměna zařízení, nebo jeho ponechání mimo systém — a je fér to vědět před podpisem, ne při realizaci.
• Když má dodavatel technologie ručit i za vaše podnikové systémy. Odpovědnost končí na definovaném rozhraní: za docházku, ERP nebo váhu odpovídá ten, kdo je provozuje. Dodavatel vrátnice má rozhraní ověřit a popsat, ne převzít cizí systém.

Časté dotazy

Poběží systém v naší síti, nebo v cloudu?

Vrstva řešení běží na aplikačním serveru v areálu: webová administrace, MQTT sběrnice, lokální databáze i rezervační server. Databáze není vystavená ven a žádná komponenta není přímo dostupná z veřejného internetu; data z veřejného rezervačního portálu tečou dovnitř šifrovaným Site-to-Site IPsec tunelem.

Naše IT nemá kapacitu starat se o další systém. Je to překážka?

Není nutně. Přesně pro tenhle případ existuje topologie oddělené sítě dodavatele: prvky systému běží ve fyzicky oddělené síti nezávislé na vašem IT a perimetr drží router dodavatele. Vaše IT pak neposkytuje ani DMZ, ani VPN.

Musíme vyměnit závory a kamery, které už na bráně stojí?

Ne, pokud mají přístupné a dokumentované řízení. Systém se přes strojové rozhraní umí napojit na brány, závory a kiosky, které už na místě jsou — cizí zařízení může nahlásit vjezd, dotázat se na povolení podle SPZ nebo řídit průjezd. Konkrétní zařízení se ověřuje před příslibem, ne při realizaci.

Dostane se servisní technik dodavatele do naší podnikové sítě?

Ne. Servisní přístup vede výhradně přes zabezpečenou VPN do vyhrazené sítě systému; uvnitř tunelu běží vzdálená správa. U topologie on-premise jde o vaši VPN podle vašich pravidel, u oddělené sítě dodavatele končí přístup v síti, kterou vaše IT neprovozuje.

Kdo rozhodne, co udělají závory při výpadku?

Provozovatel — tedy vy. Režimy pro otevření závor se definují podle vašich pravidel včetně požárního scénáře napojeného na EPS; dodavatel má scénáře navrhnout a popsat v projektu. Chování při výpadku je součást návrhu procesů, ne dodatek, který se řeší po první poruše.

---

Chcete-li si obě topologie a rozdělení odpovědností projít pro váš areál, domluvte si komentovanou ukázku.

Související články

• Jak digitalizovat areál bez výměny stávajících systémů
• Nejčastější chyby při digitalizaci provozních procesů
• Kdy digitalizace areálu nedává ekonomický smysl — a co dělat místo velkého projektu
• Co znamená digitalizace průmyslového areálu