Jste zde

Průmyslová komunikace OPC UA - 1.díl - popis protokolu

Antonín Vojáček, 22. Červenec 2020 - 23:41

Komunikační protokol OPC UA umožňuje v průmyslu u zařízení, které ho podporují, poměrně jednoduše realizovat nejen přenos naměřených hodnot do řídícího PC či databáze nebo "natahování" řídících hodnot či receptur pro nastavení výrobních linek, ale i komunikovat mezi sebou. Například mezi PLC a centrálním ovládacím HMI.

Komunikační protokol OPC UA je stále ještě patří mezi relativně dost nové průmyslové komunikační standardy, ale již ho aktivně implementovalo a podporuje u svých průmyslových zařízeních většina špičkových výrobců PLC a HMI, jako například Siemens, Omron, Weintek a další. Každý kdo někdy "přičichl" a zkoušel v praxi zprovoznit k staršímu protokolu OPC DA, postavený na technologii COM/DCOM od firmy Microsoft, jistě potvrdí, že to vždy nebyla jednoduchá práce. Naštěstí moderní protokol OPC UA, který s OPC DA není nijak kompatibilní, je v tomto směru velmi uživatelsky přívětivý a u průmyslových zařízení, které jej přímo podporují, je zprovoznění poměrně jednoduché.

Komunikační protokol OPC UA

OPC Unified Architecture (OPC UA) je průmyslový M2M (machine-to-machine) komunikační standard. Na rozdíl od původní specifikace OPC, která je založena na technologii COM/DCOM od firmy Microsoft (a tudíž funguje pouze pod OS Windows) jde o technologii založenou na obecně používaných komunikačních standardech jako jsou TCP/IP, HTTP a SOAP. To znamená, že OPC UA může fungovat i na jiných platformách než Windows. OPC UA komunikaci je možné zabudovat i do vlastních PLC automatů a jiných zařízení. Na rozdíl od OPC Classic, které odděleně definuje přístup k procesním datům (OPC DA), alarmům (OPC AE) a historickým datům (OPC HDA) nové OPC UA nedefinuje tyto konkrétní přístupy, ale pouze formát předávaných zpráv. To znamená, že jeden standard OPC UA umožňuje přenášení procesních dat, alarmů a historických dat.

Specifikace OPC UA je založená na předávání dat mezi OPC UA klientem a UPC UA serverem založená na mapování a navazování spojení, zabezpečení komunikace a struktura poslaných dat. OPC UA protokol je specifikován jako služebně orientovaná architektura SOA (Service Oriented Architecture), což znamená, že jsou definované služby, na které se klient může dotazovat a server na každý dotaz reaguje příslušnou odpovědí. Služby, které server poskytuje, vytváří abstraktní komunikační model. Po navázání fyzického spojení se pomocí služeb vytváří a udržuje zabezpečený kanál (SecuredChannel) a relace (Session). Zabezpečený kanál je nutné mít aktivní pro veškerou komunikaci, relaci je nutné mít vytvořenou pro dotazování klienta na služby serveru. Obě tyto části komunikace jsou často dohromady označovány jako komunikační zásobník (Stack). Popis adresního prostoru se provádí pomocí uzlů.

Pro to, aby byla OPC UA komunikace byla funkční, není nutné implementovat veškeré dostupné funkce, ale stačí splnit jen nutné minimum pro provoz a další funkce je možné přidávat podle potřeby. Aby se dalo zjistit, které funkce zrovna daná konkrétní aplikace podporuje a využívá, existují profily se seznamem vlastností. Aplikace poskytuje informace o tom, které profily podporuje, a tím informuje dalším aplikace zjistit, které části OPC UA specifikace využívá. Profily mohou obsahovat sady služeb, použité kódování, zabezpečení a další volitelné části specifikace OPC UA.

Základní blokové schéma architektury protokolu OPC UA.

OPC UA model/zásobník

Komunikaci v OPC UA obstarává komunikační model / zásobník (Stack), kde využívá transportní, komunikační a aplikační vrstvy:

Transportní vrstva (Transport Layer) - obstarává samotné odesílání a příjem zpráv (paketů), tedy vytváří a obsluhuje komunikační protokol. Používá šifrovací a ověřovací mechanismy k zajištění bezpečnosti zprávy poslané po síti, aby nemohla být zpráva přečtena ani modifikována třetí stranou. Při navazování spojení je transportní vrstva vytvořena ihned po připojení. OPC UA podporuje protokoly: HTTP/SOAP, HTTPS a TCP/IP.
Komunikační vrstva (Secure Channel Layer + Serialization Layer) - představuje zabezpečený kanál (SecuredChannel) mezi serverem a klientem, který musí být vytvořen ihned po navázání komunikace. Způsob vytvoření kanálu záleží na použitém komunikačním protokolu. Pro více připojení je třeba použít více kanálů, na každém kanále lze identifikovat, kterému partneru patří. Po vytvoření zabezpečeného kanálu je vytvořen identifikátor kanálu (Secure-ChannelId) a bezpečnostní známka (SecurityToken), kterými se dále kanál prokazuje. Zatímco identifikátor je trvalý, známka má omezenou životnost a je třeba ji v pravidelných intervalech obměňovat. Po vypršení životnosti poslední známky se spojení ukončí.
Aplikační vrstva (Application Layer) - představuje relace (Session), ve které probíhá veškeré volání a zpracování služeb. Relace se používá k vnitřní identifikaci komunikace a může poskytovat i autorizaci. Při vytváření relace předá klient serveru přihlašovací údaje a server po ověření údajů označí klienta jako specifického uživatele, který může mít práva na proveden í některých akcí. OPC UA nenavrhuje, v jaké formě mají existovat uživatelé, navrhuje pouze jak předat přihlašovací údaje. Každý zabezpečený kanál může mít nejvýše jednu relaci. Relaci je třeba vytvořit a poté ještě aktivovat. Aktivací se relace sváže s aktivním zabezpečeným kanálem. Relace se uzavírá po předem určené době nečinnosti. Pokud klient neposílá žádné požadavky, musí pravidelně poslat dotaz, kterým relaci udrží aktivní.

OPC UA adresování

Adresní prostor (AddressSpace) tvoří sdílená data. Adresní prostor se vytváří z jednoduchých objektů - uzlů (Node), které mezi sebou mají různé vazby, které se nazývají reference. Pomocí různých referencí se vytvářejí složitější objekty. Každý uzel má vlastní identifikátor (NodeId), který se skládá s z jmenného prostoru (Namespace) a unikátní části, která může být číselná, textová nebo může být využito GUID (Global Unique Identifier). Jmenný prostor je URI, který označuje kontext uzlu. Pokud je na jiném serveru použito stejného identifikátoru, včetně jmenného prostoru, jedná se o tentýž uzel.

OPC UA také definuje vlastní jmenný prostor, který obsahuje předdefinované uzly potřebné pro provoz OPC UA serveru. Mezi těmito uzly jsou například typy, reference, mapování a dotazy i odpovědi služeb. V adresním prostoru jsou tedy uloženy i nástroje potřebné k definování adresního prostoru.

Uzly se v adresovém prostoru se dělí / organizují do 8 základních tříd (Node Classes):

Proměnné (Variable) - reprezentuje obsah objektu uzlu a poskytuje reálná data.
Typy proměnných (VariableType) = reprezentuje typ uzlu pro proměnné v adresním prostoru serveru. Typicky se používá definování, které vlastnosti promenné jsou k dispozici.
Objekty (Object) - reprezentují systém, komponenty systému, reálné objekty a softwarové objekty.
Typy objektů (ObjectType) - reprezentuje typ uzlu pro objekty v adresním prostoru serveru. Jsou podobné jako třídy v objektově orientovaných programovacích jazycích.
Typy referencí (ReferenceType) - reprezentují typ referencí používaný serverem.
Typy dat (DataType) - všechny použité datové typy jsou reprezentované jako uzly v adresové prostoru.
Metody (Method) - reprezentuje použité metody v adresním prostoru serveru.
Pohledy (View) - slouží k omezení počet viditelných uzlů a referencí k organizování velkého adresního prostoru serveru.

Mezi nejvyužívanější třídu určitě patří "proměnné (Variable)". Ty reprezentují hodnoty, které se dělí na dva typy: datové proměnné (data variables) reprezentující samotnou hodnotu a vlastnosti (properties) reprezentující přidané vlastnosti dalších objektů, hodnot a dalších uzlů. Například senzoru teploty může obsahovat proměnnou hodnotu teploty (data variable) a také měřící rozsah, což je vlastnost (property).

OPC UA atributy

Atributy (Attributes) jsou elementy, který popisují každý uzel (Node) a jsou tedy parametry konkrétního uzlu. Definované atributy jsou jiné / rozdílné pro každou třídu uzlů. Mezi základní a společné atributy pro všechny třídy uzlů (Node Classes) patří:

Identifikátor uzlu (NodeId).
Prohledávané jméno (BrowseName).
Zobrazovací jméno (DisplayName).
Hodnota nebo třída uzlu (Node Class).

Povinnými parametry uzlu jsou zejména zobrazované jméno (DisplayedName) a prohledávané jméno (BrowseName). S pomocí prohledávaného jména lze hledat uzly z výchozího uzlu pomocí referencí (References). Prohledávané jméno nemusí být unikátní, může vyjadřovat vlastnost a umístění uzlu.

Další atributy uzlu se pak liší podle dané použité třídy uzlu. Například uzly třídy "proměnné (Variables)" reprezentují hodnoty, které se dělí na dva typy: datové proměnné (data variables) reprezentující samotnou hodnotu a vlastnosti (properties) reprezentující přidané vlastnosti dalších objektů, hodnot a dalších uzlů.

Například senzoru teploty může obsahovat proměnnou hodnotu teploty (data variable) a také měřící rozsah, což je vlastnost (property).

Mezi atributy například pro proměnné (Variables) patří následující:

Hodnota (Value) - definuje číselnou hodnota proměnné.
Datový typ (DataType) - definuje datový typ číselné hodnoty (např. 16bit. Integer, 32bit. Integer, Float, String apod.)
Úroveň přístupu (Access Level) - definuje, zda hodnotu lze z OPC UA klienta jen číst nebo i zapisovat.
Uživatelská úroveň přístupu (User Access Level) - definuje uživatelská práva k přístupu k atributu hodnoty (Value).

OPC UA služby

Komunikace mezi klientem a serverem probíhá výhradně pomocí volání a zpracovávání služeb (Services), které se zabývají ovládáním jednotlivých části funkcí serveru OPC UA. Dotazy i odpovědi mají své společné hlavičky, kde klient má například u všech dotazů možnost nastavit požadované informace, které má server vrátit.

Server ve svých odpovědích nastavuje stavový kód vykonání požadavku, který oznamuje, zda bylo vykonání služby úspěšné. Všechny stavové kódy definuje OPC UA a dělí se na dobré (Good), které značí správnou provedenou službu, nejisté (Uncertain) a špatné (Bad), které značí selhání volání služby. Každá služba má definováno, které stavové kódy může vracet. Chyby se například mohou týkat přístupových práv, stavu serveru, stavu cíle, špatně provedené akce. Nejistý výsledek může nastat, pokud alespoň jedna z částečných akcí skončila chybou.

Mezi základní OPC UA služby patří:

Průzkumné služby (Discovery) = sada služeb umožňující zjišťovat údaje o samotném serveru a možnostech jeho připojení. Tzv přípojné body mohou a nemusí být předem známy, pomocí této sady je možné najít seznam přípojných bod.

Zabezpečený kanál (SecuredChannel) = sada služeb umožňující vytvořit a ukončit zabezpečený komunikační kanál. Při vytváření je nutné použít certifikát aplikace. Stejný certifikát je poté nutné použít i při vytváření relace. Při otevírání kanálu klient zároveň nastaví používané zabezpečení, přičemž server při každém volání vrací novou bezpečnostní známku. Pro vytvoření nové známky je tedy třeba opětovně volat službu na otevření zabezpečeného kanálu.

Relace (Session) = sada služeb relací umožňující vytvořit a zrušit relaci, aktivovat existující relaci a zrušit všechny probíhající akce.

Správa uzlů (NodeManagement) = sada služeb umožňující klientovi vytvářet a mazat uzly a vytvářet a odstraňovat reference mezi různými uzly. Na rozdíl od specifikace OPC Classic může OPC UA server dovolit klientovi vytváření a mazání uzlů v adresním prostoru a správy referencí mezi nimi. Klient tak může na serveru vytvářet vlastní objekty.

Procházení (Browse) = sada služeb procházení (Browse), kterou lze procházet a načítat adresní prostor serveru. Lze nastavit, v kterém směru budou které reference prohledávány a která data má služba vrátit.
Pohled (View) = sada obsahující služby na postupné procházení adresního prostoru serveru.
Dotazování (Query) = sada služeb, kterými se klient může dotazovat na data, která splňují parametry specifikované v dotazu. Při dotazování nad pohledem server vrací pouze data obsažená v daném pohledu.

Metody (Method) = jedna služba, která danou metodu zavolá, předá jí argumenty a vrátí zpět hodnoty vstupních i výstupních parametrů. Metodu v adresním prostoru představuje specializovaný uzel.

Monitorování (Monitor) = sada služeb určená k monitorování umožňuje vytvoření, úpravu a mazání monitorovaných položek (MonitoredItem), nastavení monitorování a vytváření spouštění událostí. Monitorované položky periodicky snímají hodnotu monitorovaného uzlu a předávají je do fronty odběru (Subscription).
Odběr (Subscription) = sada služeb pro vytváření, úpravu a mazání odběrů. Jejich účelem je předávat klientovi informace o změnách stavu monitorovaného uzlu. Odběr obsahuje frontu, do které jsou přidávána data. Při zavolání publikující služby se obsah fronty odešle klientovi. Mezi publikováním musí uběhnout předem určené intervaly, při vícenásobném zavolání publikující služby se služba vykoná až po uplynutí požadovaného intervalu.

Zabezpečení komunikace OPC UA

Zabezpečení je navrženo tak, aby odolalo moderním hrozbám napadení. Zabezpečení je vnitřní a vnější. Vnějším zabezpečením může být například šifrování a podepisování zpráv nebo využití zabezpečeného kanálu. Mezi vnitřní patří zavírání přebytečných a neužitečných spojení nebo auditing (zaznamenávání aktivity na serveru).

Každá aplikace, tj. účastník OPC UA komunikace (OPC UA server, klient i gateway), musí mít vlastní aplikační certifikát, který jednoznačně identifikuje aplikaci a stroj (počítač), na kterém tato aplikace běží. OPC UA definuje 4 základní úrovně zabezpečení:

Úroveň 1 – bez autentizace = klient a server umožňují komunikovat komukoliv. To znamená, že všechny platné certifikáty jsou považované za důvěryhodné. Aplikační certifikáty jsou použité pouze pro poskytování neověřitelných informací o druhé straně. Příjemce nemá žádný způsob, jakým by ověřil zda poskytovatel je legitimní držitel certifikátu. Na této úrovni obě strany automaticky uznávají platné certifikáty i když tyto nejsou zařazené do seznamu důvěryhodných certifikátů. Tato úroveň nevyžaduje žádné nastavení na straně klienta ani serveru.
Úroveň 2 – serverová autentizace = server umožňuje připojení libovolnému klientovi. Ověření klienta (pokud je požadované) se provádí pomocí ověřovacích údajů jako jméno/heslo zaslané na server po vytvoření zabezpečeného kanálu. Každý klient musí důvěřovat serverovému certifikátu. Toto nastavení provede Administrátor na straně klienta (serverový veřejný klíč musí být explicitně uveden v seznamu důvěryhodných certifikátů, nebo musí být serverový certifikát vydán důvěryhodnou certifikační autoritou). Pokud serverový certifikát explicitně není na seznamu důvěryhodných certifikátů, pak klient musí porovnat DNS jméno uvedené na serverovém certifikátu s DNS jménem počítače, ke kterému se připojuje. Tento postup poskytuje dobrou úroveň zabezpečení, ale server nemůže omezovat klientské aplikace na základě jejich autentizace.
Úroveň 3 – klientská autentizace = klient může připojit k libovolnému serveru, ale server umožňuje připojení pouze důvěryhodným klientům. Tato úroveň se používá u služeb, které vyžadují přístup pouze důvěryhodným klientům a kde současně není požadavek na legitimitu serveru. Aby server poskytl data, musí důvěřovat klientskému certifikátu. Toto nastavení provede Administrátor na serveru (klientský certifikát explicitně uvede do seznamu důvěryhodných certifikátů, nebo musí být klientský certifikát podepsán důvěryhodnou certifikační autoritou).
Úroveň 4 – oboustranná autentizace = klient a server umožňují připojení pouze důvěryhodným partnerům. Tento způsob poskytuje nejvyšší úroveň zabezpečení, ale vyžaduje nastavení na obou stranách (klient a server). Pokud serverový certifikát není explicitně důvěryhodný, pak klient ověří server stejně jako v úrovni 2. Tento přístup zajišťuje nejvyšší míru zabezpečení a je proto doporučen OPC Foundation jako implicitní pro všechny klienty i servery.

Co OPC UA protokol znamená v průmyslové praxi ?

Velkou výhodou OPC UA je její jednoduchost na finální zprovoznění díky skutečnosti, že narozdíl od starší technologie OPC Classic pro svůj provoz už nepotřebuje DCOM knihovny společnosti Microsoft, a díky tomu lze OPC UA provozovat i na jiných operačních systémech, jako je iOS, Android, Linux a další. Je tedy mnohem univerzálnější a netrávíte hodiny nastavováním OPC komunikace mezi počítači. Komunikace je také robustnější a bezpečnější, integrované funkce pro autorizaci a šifrování dat zvyšují bezpečnost dat na maximum.

Např. Simatic S7-1500 nebo HMI Weintek disponují vestavěným OPC UA serverem a připojený OPC UA klient ve formě opět například HMI panelu Weintek či PC softwaru může rovnou zobrazit data z PLC. To je mnohem, mnohem uživatelsky příjemnější a navíc, jak je z toho patrné, lze OPC UA využít nejen k přenosu dat do velkých počítačových OPC systémů s OS Windows, ale již i do libovolných malých HMI s vlastním firmwarem či do malých destiček s OS Linux, typu např. Raspberry Pi.

Pozor ale na to, že technologie OPC UA není přímo kompatibilní s předchozími již dříve využívanými technologiemi OPC Classic (OPC DA atd.). Někdy se stává, že zákazníci ve svých aplikacích disponují pouze klasickým rozhraním OPC DA, ale snaží se do nich připojit nová zařízení s vestavěným OPC UA serverem. To samozřejmě nebude fungovat. V případě nasazení technologie OPC UA je nutné na obou stránách komunikace, tedy na straně OPC serveru i OPC klienta využít pouze zařízení či software přímo výslovně podporující OPC UA. Existují však softwarové utility provádějící převod mezi OPC UA a OPC Classic.

Závěr 1. dílu

Než se podíváme na čistě praktickou stránku ukázky zprovoznění OPC UA komunikace (v 2. díle), zkusil jsem nejdříve "vypíchnout" základní informace o protokolu a jeho funkci. OPC UA je popisem velmi obsáhlý, takže jsem se pokusil zde jen "nastínit" základní aspekty pro základní přehled a seznámení, které pro finální uživatele průmyslových komponent s podporou OPC UA je myslím více než dostačující. Pro bližší zájemce (hlavně z řad vývojářů/programátorů) odkazuji na webové stránky OPC Foundation nebo velmi dobrý český dokument pana Tomáše Ausbergera: "OPC UA servery a jejich použití pro přenos dat řídicích systémů" .

Pokračování v 2. díle

V 2. dílu průmyslová komunikace OPC UA již prakticky ukážu základní použití / zprovozněn OPC UA komunikace mezi OPC UA serverem v podobě HMI panelu Weintek, který má OPC UA protokol již v sobě implementovaný a OPC UA klientem v podobě PC softwaru.