Aktuální vydání

celé číslo

08

2024

Automatizace v potravinářství a farmacii

Měření a regulace průtoku, čerpadla

celé číslo

OPC Unified Architecture pro vzájemnou součinnost zařízení

číslo 12/2006

OPC Unified Architecture pro vzájemnou součinnost zařízení

Společnost OPC Foundation letos oslavila desáté výročí svého založení. Zakládající členové této organizace, společnosti Fisher-Rosemount, Rockwell Software, Opto 22, Intellution a Intuitive Technology, si vytyčili úkol vyvinout standard pro vzájemnou komunikaci inteligentních snímačů, akčních členů, regulátorů a programovatelných automatů se systémy HMI a SCADA. Ukázalo se, že jejich rozhodnutí vsadit na již hotová řešení od firmy Microsoft, standardy COM a DCOM, bylo ve své době velmi šťastné. Nový standard pro komunikaci v průmyslové automatizaci, nazvaný OPC (OLE for Process Control), tak mohl vzniknout ve velmi krátké době – práce na něm trvala zhruba rok. A nejen to, díky komerční síle firmy Microsoft se standard OPC velmi rychle rozšířil. Již v roce 2004 jsme tak mohli psát o tom, že OPC je nejrozšířenější metoda přenosu dat v průmyslu [5].

Ovšem snaha byla jít dále a vyvinout standard pro komunikaci nejen snímačů a akčních členů s PLC a systémy SCADA, ale napříč celým automatizovaným systémem, od nejnižší provozní úrovně řízení až po systémy MES a rozhraní pro podnikové systémy ERP. Postupně vznikaly různé specifikace OPC: OPC DA pro přístup k datům, OPC AE pro přístup k alarmům a událostem, OPC HDA pro přístup k historickým datům atd. Koexistence těchto specifikací není zcela bez problémů. Například existence dvou různých OPC serverů – pro data (OPC DA) a pro události (OPC AE) – může vést k tomu, že uživatel zjišťuje prostřednictvím OPC DA aktuální hodnotu teploty z určitého snímače a prostřednictvím OPC AE obdrží výstražné hlášení o tom, že nějaká teplota překročila stanovené meze. On však nemůže s jistotou říci, že teplota, která je mimo určené meze, je právě teplota zjišťovaná datovým OPC serverem – neexistuje totiž požadavek na jednotné pojmenování proměnných v obou serverech [3].

Navíc se původní výhoda, totiž využití již existujících standardů COM a DCOM od firmy Microsoft, časem ukázala jako omezení. Je tomu tak vzhledem k tomu, že v průmyslu se používají i jiné operační systémy než Windows a že standardy COM a DCOM postupně zastaraly a dnes už jsou minulostí. Před několika lety proto vznikl záměr vytvořit nový standard OPC UA (Unified Architecture), jenž by byl založen na webových službách a využíval by jazyk XML.

Počátky OPC UA

Myšlenka OPC UA dozrála v roce 2003. OPC Foundation tehdy vydala tiskovou zprávu [4], kde úmysl vyvinout standard OPC UA poprvé oficiálně představila. Již v roce 2004 se o novém konceptu OPC UA široce diskutovalo také na veletrhu Hannover Messe, který je pro evropskou průmyslovou automatizaci nejvýznamnější výstavní akcí. Na základě těchto diskusí vznikl článek [7], který OPC UA poprvé představil i našim čtenářům.

Průlomovou tehdy byla specifikace OPC XML DA, první ze specifikací OPC, která nestavěla na COM a DCOM, ale na webových službách a XML, a ukázala tak, že se bez COM a DCOM lze obejít.

Znamená to, že se OPC Foundation postavila zády k firmě Microsoft? Nikoliv, Microsoft zůstal váženým členem OPC Foundation. Ovšem i Microsoft sám v nových řešeních opustil COM/DCOM a staví na koncepci „.net„ (dot net), využívající stejně jako OPC UA otevřené webové a internetové standardy a architekturu orientovanou na služby (SOA).

Architektura orientovaná na služby – SOA

Na rozdíl od dřívější objektové koncepce OPC je tedy OPC UA založena na architektuře orientované na služby (SOA – Service Oriented Architecture; lze se setkat i s poněkud toporným překladem servisně orientovaná architektura). Základní myšlenkou SOA je to, že jednotlivé aplikace jsou složeny ze služeb, k nimž aplikace přistupují prostřednictvím standardizovaných rozhraní. Architektura stanovuje, jak jsou jednotlivé služby v síti lokalizovány, vykonávány, spravovány, sledovány a zabezpečovány.

V architektuře SOA existují tři základní softwarové prvky: odběratel, registr a poskytovatel. Poskytovatel posílá do registru informace o síťových službách, které je schopen zajistit, a o tom, jak vypadá rozhraní pro tyto služby, zatímco odběratel hledá v tomtéž registru vhodného poskytovatele dané služby. Výhodou tohoto systému oproti COM/DCOM je, kromě nezávislosti na platformách od společnosti Microsoft, také to, že odběratelé a poskytovatelé, resp. jejich služby, jsou spojeni ad hoc, a mohou se tedy nezávisle na sobě měnit, zatímco v COM/DCOM byly jednotlivé služby pevně vázány na dané klienty. Zmíněná vlastnost s sebou nese velkou flexibilitu řešení založených na SOA.

Myšlenka SOA přitom není nová, ale praktický význam jí dalo teprve využití webových služeb a jazyka XML. Díky nim jsou řešení založená na SOA velmi univerzální (podobně jako třeba webové prohlížeče). Je ovšem třeba připomenout, že v SOA lze využít i jiné síťové služby než webové, a že službou v SOA se tedy automaticky nemyslí webová služba.

Základní prvky OPC UA

Základním prvkem OPC UA je UA server, který v sobě spojuje všechny funkce dřívějších klasických OPC serverů (obr. 1) – přístup k datům, k historickým datům i k událostem a alarmům. Pracuje s jednotnou sadou služeb: čtení a zápis dat, zobrazení a procházení adresového prostoru atd. Díky jednotnému adresovému prostoru již nemůže dojít k nekonzistenci dat mezi servery dat a servery událostí.

Obr. 1.

Obr. 1. UA server zahrnuje všechny funkce OPC serverů

OPC UA splňuje požadavky na odolnost komunikace proti chybám. Klient (odběratel služeb) může od jednotlivých serverů požadovat pravidelnou zprávu potvrzující jejich funkci („heartbeat„ message). Tím lze detekovat selhání serveru nebo komunikačního kanálu. Jednotlivé zprávy je možné označovat pořadovým číslem, takže klient snadno zjistí, když některá zpráva chybí. Lze také zajistit redundanci na úrovni serverů, aplikací i provozních zařízení.

Důležitým požadavkem je také bezpečnost komunikace. Standardně lze UA servery vybavit funkcemi pro řízení přístupu. UA klient předkládá serveru své oprávnění a ten kontroluje, zde je tento klient oprávněn odebírat danou službu. Zasílané zprávy je pro zvýšení bezpečnosti navíc možné šifrovat.

Pro vzájemnou komunikaci jsou důležité normy

Mluví-li OPC Foundation o jednotné komunikaci nezávislé na tom, kde se nacházejí jednotlivé účastnické stanice a na jaké platformě pracují, musí se vypořádat s tím, že automatizace zahrnuje pestrou paletu oborů, kde existuje množství různých standardů pro architektury řídicích systémů i pro komunikaci. Pro OPC Foundation je proto nutností spolupracovat s různými standardizačními autoritami a sdruženími. Významná je především spolupráce s organizací ISA jako s původcem norem ISA S95, ISA S88 a ISA S99 a se sdruženími Mimosa (Machinery Information Management Open System Aliance) a OMAC (Open, Modular Architecture Control). V květnu 2005 jsme informovali o tom, že OPC Foundation spolupracuje také na projektu rozšíření EDDL [6]. OPC Foundation dále kooperuje s organizací OAGi (Open Applications Group, Inc.), která si klade za cíl prosazovat standardy umožňující interoperabilitu ekonomických systémů a participuje na činnosti pracovní skupiny IEC TC57 WG 13, zabývající se standardizací systémů pro správu distribuce a spotřeby energií.

Dostupnost specifikací a dalších informací

Aktuální dostupnost specifikací OPC UA je shrnuta v tab. 1. Specifikace jsou dostupné členům sdružení OPC Foundation (viz www.opcfoundation.org), pouze nejobecnější specifikace je dostupná všem. Členům OPC Foundation budou dostupné i ukázkové zdrojové kódy OPC UA; dosud však žádné k dispozici nejsou.

Tab. 1. Dostupnost specifikací OPC UA (stav k 9. listopadu 2006)

Titul

Verze

Dostupnost

Poslední modifikace

Stav

Definice struktury, adresového prostoru a služeb

OPC UA Part 1 – Concepts 1.00 Specification

1.00

obecná

2006-07-28

vydáno

OPC UA Part 2 – Security Model 1.00 Specification

1.00

členové OPC

2006-07-28

vydáno

OPC UA Part 3 – Address Space Model 1.00 Specification

1.00

členové OPC

2006-07-28

vydáno

OPC UA Part 4 – Services 1.00 Specification

1.00

členové OPC

2006-07-28

vydáno

OPC UA Part 5 – Information Model 1.00 Specification

1.00

členové OPC

2006-07-28

vydáno

OPC UA Part 6 – Contracts (WSDLs, XSDs and BSDs) RC 0.93

RC 0.93

členové OPC

2006-10-17

beta

OPC UA Part 6 – Mappings RC0.93 Specification

RC 0.93

členové OPC

2006-06-01

draft

OPC UA Part 7 – Profiles Draft 0.23 Specification

draft 0.23

členové OPC

2006-07-28

draft

Typy dat

OPC UA Part 8 – Data Access 1.00 Specification

1.00

členové OPC

2006-09-29

vydáno

OPC UA Part 9 – Alarms Draft 0.62 Specification

draft 0.62

členové OPC

2006-04-15

draft

OPC UA Part 10 – Commands Draft 0.2 Specification

draft 0.2

členové OPC

2006-04-15

draft

OPC UA Part 11 – Historical Access RC1.00 Specification

RC 1.00

členové OPC

2006-11-03

draft

OPC UA Part 12 – Batch

     

prozatím odloženo

OPC UA Part 13 – Data Exchange

     

OPC Foundation pořádá na téma OPC UA mnoho seminářů a konferencí. Zatím poslední z nich, vývojářská konference DevCon 2006, se konala 10. až 12. října 2006 v Mnichově (SRN) a setkala se s mimořádným zájmem. Zúčastnilo se jí na 250 posluchačů ze 133 různých firem. Účastníci vyslechli množství přednášek, komerčně zaměřených, „vizionářských„ i popisujících technické detaily OPC UA.

Závěrem

Proces standardizace OPC UA pokračuje velmi rychle. Silná je i snaha zavést tuto koncepci co nejrychleji do praxe. Z téměř 400 členů OPC Foundation tvoří skupinu průkopníků OPC UA tyto společnosti: 4CE, ABB, Absynt, Advosol, Allmendinger, Ascolab, Beckhoff, CAS, Cognex, Cyberlogic, Emerson, GE, Honeywell, Iconics, Indusoft, Invensys/Foxboro, Kepware, Matrikon, Microsoft, OSISoft, Prosys, Rockwell, SAP, Siemens, SISCO, SMAR, Softing, SoftwareToolbox, SRI, Technical Research Center Finland, Technosoftware, Wapice, Wonderware a Yokogawa.

Lze očekávat, že OPC UA se stane stejným standardem pro komunikaci v průmyslové automatizaci jako OPC. Její vlastnosti jí však dávají šanci uspět i v jiných oblastech, než je průmyslová automatizace, např. v automatizaci technických zařízení budov, v systémech řízení dopravy apod.

Poděkování: Děkuji panu Petru Pavlíkovi z firmy Kontron Czech za odbornou korekturu příspěvku.

Literatura:
[1] STIANKO, M. – PETERKA, J.: OPC v průmyslové komunikaci. Automa, 2004, roč. 10, č. 6, s. 40–42.
[2] BURKE, T. J.: The magic of OPC Unified Architecture. Industrial Ethernet Book, leden 2006, Issue 30.
[3] LUTH, J.: Unified architecture – The future of OPC. Controlglobal.com, 2004. Dostupné na http://www.controlglobal.com/articles/2004/229.html# (cit. 9. 11. 2006).
[4] OPC Foundation: OPC transitions to unified architecture for global interoperability. Tisková zpráva, říjen 2003.
[5] OPC je v současnosti základní metoda sdílení dat v průmyslu. Automa, 2004, roč. 10, č. 12, s. 42.
[6] OPC se připojuje k projektu rozšíření EDDL. Automa, 2005, roč. 11, č. 5, s. 56.
[7] OPC Unified Architecture sjednotí toky dat. Automa, 2004, roč. 10, č. 7, s. 48.

(Bk)