Jak si v budoucnosti systémů najít cestu pro IIoT

Jak si v budoucnosti systémů najít cestu pro IIoT

Je nezbytné rozumět tomu, které technologie pro konektivitu ve sféře IIoT u jednotlivých aplikací použít.

Sdružení Industrial Internet Consortium (IIC) nedávno publikovalo rámec pro konektivitu průmyslového internetu věcí – Industrial Internet Connectivity Framework (IICF), který je výsledkem dvou let analýz technologií průmyslového internetu věcí (Industrial Internet of Things – IIoT). Rámec IICF obsahuje poznatky a důrazná doporučení mnoha odborníků, včetně expertů z předních průmyslových sdružení, řady firem a nejdůležitějších standardizačních organizací. 

Nejpřekvapivější je závěr: Prostor IIoT je příliš velký. Je tak velký, že se technologie v podstatě nepřekrývají.

Návrháři se mohou domnívat, že smějí vybrat jakýkoli standard, včetně služeb distribuce dat (DDS od skupiny Object Management Group), OPC Unified Architecture (OPC UA), MQ Telemetry Transport (MQTT) nebo oneM2M, a budou úspěšní. To ale předpokládá, že řešení pro konektivitu ve sféře IIoT se překrývají, jak znázorňuje obrázek 1

Obrázek 1: Tento diagram znázorňuje běžnou falešnou představu, že „mnoho technologií splňuje požadavky v prostoru konektivity IIoT“. Možnosti pro danou aplikaci (bod je vyznačen písmenem X) jsou B nebo C. Pokud by se tyto technologie opravdu překrývaly, fungovalo by jak řešení B, tak i řešení C. Všechny obrázky poskytla společnost Real-Time Innovations, Industrial Internet Consortium

 

Skutečnost je však velmi odlišná. IIoT pokrývá řadu odvětví s mnoha různými případy použití.

Prostor IIoT je vlastně tak velký, že se technologie jen málokdy překrývají, jestli vůbec. Při navrhování architektury ve sféře IIoT dnes tedy není výzvou vybrat některou z překrývajících se technologií, z nichž by všechny byly schopny poměrně dobře problém vyřešit. Výzvou je porozumět těmto technologiím, porovnat jejich zamýšlené použití s danou aplikací a vybrat takovou technologii, která nejlépe řeší konkrétní problém, s nímž se aplikace potýká. Podíváte-li se na realističtější mapu situace, vypadá spíše jako rozptýlený Vennův diagram na obrázku 2 než překrývající se množiny na obrázku 1

Skutečný problém není vybrat mezi podobnými možnostmi, ale porozumět velmi odlišným variantám a překonat předpojatost. Rámec IICF přesně toto řeší. 

Jak vybrat technologii pro IIoT

Podívejme se na tento proces podrobněji. Můžete si pro každou variantu technologie položit několik otázek a rychle tyto možnosti zúžit. Tyto otázky možná daný problém přehnaně zjednodušují, ale jsou skvělým výchozím bodem. Rámec IICF identifikuje čtyři potenciální „hlavní standardy konektivity“ – DDS, OPC UA, oneM2M a RESTful HTTP. První tři jsou popsány níže. Standard RESTful HTTP je dobře známý, takže jej zde nepopisujeme. Prozkoumáme i protokol MQTT, protože je velmi populární, i když se nekvalifikuje jako „hlavní standard konektivity“ rámce IICF, neboť nemá standardní typový systém požadovaný pro kompatibilitu. 


DDS

DDS je standardem, který definuje datovou sběrnici. Datová sběrnice je řízením toku informací na bázi dat. Je to podobný koncept jako databáze, což je ukládání informací na bázi dat. Klíčový rozdíl: Databáze ukládá staré informace, které lze vyhledávat na základě vlastností uložených dat. Datová sběrnice spravuje budoucí informace filtrováním podle vlastností příchozích dat. Oba koncepty rozumějí datovému obsahu a dovolují aplikacím jednat přímo na základě a prostřednictvím dat namísto toho, aby interagovaly navzájem. Aplikace využívající databázi nebo datovou sběrnici nemají přímý vztah s partnerskými (peer) aplikacemi. 

Se znalostí struktury, obsahu a požadavků na data může datová sběrnice řídit datový tok. Datová sběrnice je schopna řídit kvalitu síťových služeb (Quality of Service – QoS), jako je obnovovací interval (update rate), spolehlivost a živost (liveliness) dat. Může také zjišťovat, řídit či zabezpečovat datové toky a nabízet je aplikacím i generickým nástrojům. Tato dostupná data značně usnadňují systémovou integraci a škálování. 


OPC UA

Technologie OPC UA se soustředí na kompatibilitu zařízení. Před nástupem architektury OPC UA (nebo jejího předchůdce OPC) aplikace jednoduše přistupovaly k zařízením přímo, a to prostřednictvím speciálních rozhraní pro programování aplikací (API) poskytovaných dodavateli zařízení. Bohužel to znamenalo, že aplikace se stávaly závislými na příslušném zařízení, které řídily. A co je ještě horší, aplikace na vyšší úrovni, jako jsou rozhraní HMI, neměly k dispozici žádný snadný způsob, jak vyhledat, připojit se a řídit různá zařízení ve výrobních závodech. 

Architektura OPC UA rozděluje systémový software na klienty a servery. Servery jsou obvykle umístěny v zařízení nebo řídicím prvku PLC vyšší úrovně. Poskytují způsob, jak přistupovat k zařízení prostřednictvím standardního „modelu zařízení“. Existují standardní modely pro desítky různých typů zařízení. Každý výrobce je povinen poskytnout server, který mapuje generický model zařízení na jeho příslušné zařízení. Servery pak disponují objektově orientovaným rozhraním API s možností vzdáleného volání, které implementuje model zařízení. 

Klienti se pak mohou připojovat k zařízení a volat funkce z generického modelu zařízení. Proto je software klienta nezávislý na daném zařízení a integrátoři výrobních závodů mohou podle potřeby měnit výrobce nebo modely zařízení. Architektura OPC UA proto poskytuje konektivitu potřebnou k ovládání systému. Model zařízení rovněž poskytuje úroveň „sémantické“ kompatibility, protože definuje generická objektová rozhraní API ve známých jednotkách a specifikovaných referenčních bodech. 


OneM2M

Specifikace OneM2M je výsledkem spolupráce mnoha poskytovatelů bezdrátového mobilního připojení. Soustředí se na sítě mobilních zařízení, která komunikují většinou nebo pouze prostřednictvím infrastruktury základové stanice. 

Hlavním smyslem specifikace oneM2M je definovat služby, které mohou mobilní zařízení používat ke vzájemné spolupráci a integraci. Pokud se chystáte tyto služby používat, prostě se k nim potřebujete připojit.  Poběží na vrstvě platformy (cloudu), jež je většinou připojena prostřednictvím mobilní datové infrastruktury. IP přenos po mobilní síti využívají i jiné technologie, ale ty se obvykle značně opírají také o sítě LAN, lokální bezdrátové sítě nebo síťové technologie WAN. 

Obrázek 2: Tento diagram je blíže realitě. Technologie pro konektivitu se ve skutečnosti nepřekrývají. Většina aplikací může logicky používat pouze jednu technologii. Často je výzvou zvolit něco, co není úplně dokonalé, a zajistit, aby to fungovalo.

 

MQTT

MQTT je jednoduchým protokolem navrženým především pro účely „sběru dat“. Nekvalifikuje se jako „hlavní standard konektivity“ ve smyslu pokynů rámce IICF, protože nemá standardní typový systém. Proto může komunikovat pouze s datovými typy „opaque“, nikoli se strukturami typovaných dat. Bez typového systému nemůže nabídnout standardní schopnost kompatibility na úrovni „syntaktické“ datové struktury. 

Přesto je protokol MQTT velmi dobře známý. Díky jeho jednoduchosti mohou snadné otázky o vašem systému pomoci určit, zda je dostatečný. 


Vzájemná spolupráce

Značná část rámce IICT je věnována architektuře pro integraci těchto technologií. To má zásadní význam pro realizaci „internetové“ části koncepce průmyslového internetu věcí. Referenční architektura vyžaduje hlavní brány na bázi standardů mezi hlavními standardy konektivity. 

V budoucnu se může objevit integrace například výrobních systémů s přepravou a energetikou. Sofistikovaný autonomní software bude překonfigurovávat pracovní buňky a vytvářet odvážný nový svět pro dodavatele komponentních zařízení. Bezdrátové systémy 5G budou komunikovat s řídicími systémy dálnic a autonomními vozidly. Bezdrátové systémy 5G mohou dokonce přímo řídit zařízení výrobních závodů a omezovat objem kabeláže ve výrobě. 

Nicméně návrháři by měli brát v úvahu obrovskou šíři tohoto prostoru. Dnes existuje několik konkrétních potřeb přemostění těchto světelných let mezi systémy pro konektivitu. To neznamená, že průmysl na tuto zjevnou nezbytnost nereaguje. Z dlouhodobého hlediska takovéto integrace umožní, aby větší systémy tyto technologie kombinovaly. Prozatím musejí návrháři porozumět obrovským rozdílům mezi technologiemi a vybrat tu, která je pro sféru jejich problematiky nejvhodnější. 

Stan Schneider, Ph.D., CEO společnosti Real-Time Innovations a člen výboru Industrial Internet Consortium Steering Committee. Upravila Emily Guentherová, zástupkyně obsahového ředitele, Control Engineering, CFE Media, Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript..

Control Engineering Česko

Control Engineering Česko je přední časopis o průmyslové automatizaci. Je vydáván v licenci amerického Control Engineering, které poskytuje novinky z této oblasti více než 60 let.

www.controlengcesko.com