Edge, nebo cloud? V průmyslu je to špatně položená otázka

V projektech průmyslové digitalizace pravidelně zaznívá otázka: edge, nebo cloud?

Jako by bylo nutné vybrat si mezi dvěma navzájem se vylučujícími pohledy na svět. Na jedné straně zpracování přímo na místě, na druhé cloud. Jedno je rychlé a nezávislé, druhé škálovatelné a centrálně spravovatelné.

Ve skutečnosti dobře fungující průmyslový systém téměř vždy využívá obojí. Ne podle technologické módy, ale podle toho, kde lze daná data nebo rozhodnutí zpracovat nejbezpečněji, nejrychleji a nejhospodárněji.

Co vlastně znamená edge?

Edge nemusí být nutně zvláštní server vedle výrobní linky. Může sem patřit jakákoli výpočetní a rozhodovací schopnost, která pracuje blízko místa, kde data vznikají.

Může to být:

• inteligentní senzor;
• PLC;
• průmyslová IoT brána;
• lokální počítač;
• server v místě provozu;
• služba pro zpracování dat běžící v kontejneru.

Úkolem edge není jen „posílat do cloudu méně dat“. Může lokálně zajišťovat funkce, u nichž záleží na nízké latenci, nezávislosti na síti, ochraně dat nebo provozní bezpečnosti.

Co se nesmí svěřit vzdálenému spojení

Pokud musí rozhodnutí padnout během milisekund nebo sekund, může být cesta sítí tam a zpět riziková. Totéž platí, když musí technologie fungovat i bez připojení k internetu.

Typicky zůstává lokálně:

• přímé řízení strojů a procesů;
• funkce funkční bezpečnosti (safety);
• okamžitý ochranný zásah;
• předzpracování dat s vysokou vzorkovací frekvencí;
• vyrovnávací ukládání (buffering) dat;
• základní lokální funkce pro obsluhu;
• přizpůsobení komunikačních protokolů.

Pokud například snímač vibrací vytváří několik tisíc vzorků za sekundu, nemusí být účelné posílat každou surovou hodnotu nepřetržitě do centrálního systému. Lokální zpracování může vypočítat charakteristické veličiny, rozpoznat překročení prahu a předat jen relevantní souhrn nebo úsek vzorků z okolí události.

V čem je centrální nebo cloudové zpracování silnější

Centrální prostředí se vyplatí tam, kde je třeba propojit data z více lokalit, z dlouhých období nebo z více podnikových systémů.

Zde je vhodné řešit například:

• srovnání mezi lokalitami;
• historickou analýzu;
• dohled nad zařízeními na úrovni celé flotily;
• podnikové reporty;
• centrální správu oprávnění;
• trénování modelů;
• údržbové a obchodní procesy;
• správu verzí a konfigurací.

Výhoda cloudu nespočívá jen v tom, že „server je jinde“. Může nabídnout flexibilní kapacitu, centrální dostupnost, jednotný provoz a společné zpracování dat z více zdrojů.

Pět skutečných rozhodovacích kritérií

Rozdělení úloh mezi edge a cloud je vhodné stanovit podle nejméně pěti kritérií.

1. Latence

Jak rychle je třeba reagovat? Zásah na ochranu stroje a měsíční energetický report zjevně nepatří do stejné kategorie.

2. Spolehlivost spojení

Co se stane, když vypadne připojení WAN nebo mobilní připojení? Lokální proces musí dál bezpečně fungovat a data je třeba v případě potřeby uložit do vyrovnávací paměti a později synchronizovat.

3. Objem dat

Přenášíme surové datové řady, nebo již zpracované charakteristiky? Šířka pásma, náklady na úložiště a cíl analýzy společně určují správnou odpověď.

4. Bezpečnost a nakládání s daty

Která data smějí opustit lokalitu? Z jakého směru je spojení povoleno? Kde probíhá autentizace, šifrování a protokolování?

5. Životní cyklus a provoz

Kdo aktualizuje lokální komponentu? Jak spravovat konfiguraci stovky lokalit? Jak se vrátit od chybné verze? Edge zařízení se nesmí stát zapomenutou černou skříňkou.

Provoz offline není výjimka, ale návrhový stav

U průmyslového řešení je třeba výpadek sítě navrhovat ne jako mimořádnou nehodu, ale jako předem ošetřený stav systému.

Je nutné určit:

• kolik dat lze uložit lokálně;
• v jakém pořadí probíhá zpětné nahrávání dat;
• jak se řeší duplicity;
• co se stane při vzájemně si odporujících příkazech;
• které funkce zůstanou dostupné;
• kdy a komu systém podá hlášení.

Přístup OrigSmart k branám a platformě tuto kontinuitu řeší. Terénní připojení, lokální logika, předávání zpráv, centrální zpracování dat a obchodní proces nejsou samostatné projekty, ale části jednoho systému navrženého od začátku do konce (end-to-end).

V obousměrném systému je hranice ještě důležitější

Jednoduchá telemetrie posílá data pouze směrem nahoru. Skutečná provozní platforma však může zpětně působit i na fyzický provoz: změní žádanou hodnotu (setpoint), reguluje střídač, plánuje spotřebu, potvrdí alarm nebo spustí lokální proces.

V takovém případě je třeba jasně oddělit:

• doporučení od proveditelného příkazu;
• centrální optimalizaci od lokálního bezpečnostního limitu;
• uživatelské oprávnění od povolení na straně zařízení;
• běžný provoz od bezpečného záložního (fallback) režimu.

Centrální systém může vyhodnotit, že snížení zátěže by bylo ekonomicky výhodné. Lokální řízení však musí zabránit každému zásahu, který by porušil technologickou nebo bezpečnostní mez.

Zdroje

• Evropská komise – Evropská politika v oblasti internetu věcí
• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security
• OrigSmart – Webový podnikový operační systém