V minulom storočí vznikla organizácia, ktorej cieľom bolo a je zadefinovať štandardný mechanizmus pre komunikáciu väčšieho počtu dátových zdrojov, teda zariadení vo výrobe a databázových, alebo ovládacích aplikácií na strane riadenia výroby. Táto organizácia bola pomenovaná OPC foundation.

Architektúru riadenia výroby definovali do troch vrstiev:

• Field managment
• Process managment
• Business managment

Obr.1 – Architektúra riadenia výroby

Úlohou field managementu je priamo monitorovať a riadiť výrobu. S príchodom malých, jednoduchých a odolných tzv. “smart” zariadení ako napríklad snímačov, alebo regulátorov je v súčasnosti k dispozícii priamo z výroby veľké množstvo dát. Týmito dátami sú informácie o stave zariadení, parametroch, nastavení, o stave materiálu vo výrobe, alebo stave samotnej výroby, ktoré musia byť posúvané ďalej k užívateľovi a ovládacím aplikáciám v konzistentnej podobe.

Process managment zahŕňa ovládacie a riadiace aplikácie ako sú DCS (Distributed Control Systems) alebo SCADA (Supervisory Control And Data Acquisition) systémy, ktoré kontrolujú a riadia výrobu tým, že digitalizujú dáta poskytnuté nižšou vrstvou a tieto sa tak stávajú dostupné pre vyššiu vrstvu. 

Hlavnou výhodou používania riadiacich systémov je integrovanie informácii zozbieraných z výroby do obchodných systémov riadiacich finančnú stránku výrobného procesu. Poskytovanie informácií klient aplikáciám v konzistentnej forme minimalizuje úsilie na túto integráciu. Túto čať obsahuje Business managment.

Na to, aby všetky tri úrovne fungovali efektívne, výrobcovia potrebujú pristupovať k dátam zo zariadení priamo vo výrobe a integrovať ich do existujúcich obchodných plánov a systémov. Výrobcovia musia byť schopní využívať systémy ako SCADA alebo DCS na realizáciu svojich plánov. Kľúčom k splneniu tejto podmienky je otvorená a efektívna komunikačná architektúra zameraná na prístup k dátam a nie na typ dát.

K realizácii takejto architektúry je potrebný spoločný a presne definovaný spôsob pre komunikáciu aplikácii so zdrojmi dát akými sú zariadenia vo výrobe alebo databázy SCADA systémov. Idea spomínanej komunikácie je znázornená na obrázku 2. OPC serverom sa myslí ľubovoľný server poskytujúci OPC rozhranie napríklad OPC Data Access Server, OPC Historical Data Server, alebo Alarm & Event Handling Server.

Obr.2 –  Komunikácia medzi aplikáciami typu klient a OPC servermi

V súčasnosti je k dispozícii množstvo klient aplikácií pre prístup k dátam z dátových zdrojov vo výrobe, ktoré majú implementované vlastné ovládače a spôsoby prístupu k týmto dátam. Hlavné nedostatky takéhoto riešenia sú : 

• Opakovanie úsilia – každý musí napísať vlastný ovládací software pre zariadenia jednotlivých výrobcov
• Nekompatibilita medzi ovládačmi – možnosti hardwaru nie sú podporované všetkými vývojármi ovládačov
• Podpora zmien možnosti hardwaru – zmena vybavenia hardwaru môže spôsobiť nefunkčnosť ovládacieho softwaru
• Prístupové konflikty – dve aplikácie nemôžu pristupovať na to isté zariadenie, lebo každé používa nezávisle ovládače

Výrobcovia hardwaru sa pokúšali vyriešiť tieto problémy vývojom ovládacieho softwaru pre svoje zariadenia, ale ich úsilie stroskotalo na rozdieloch v protokoloch používaných aplikáciami pri komunikácii. V dnešnej dobe je už nemožné vyvinúť ovládač, ktorý by mohli používať všetky aplikácie typu klient. Práve preto vzniklo OPC, ktoré je spojnicou medzi poskytovateľmi hardwaru a vývojármi softwaru. Zabezpečuje mechanizmus pre štandardný transfer dát z hardwarových zariadení do ľubovoľnej klientskej aplikácie. Výrobcovia môžu vďaka tomu vyvinúť opakovane použiteľný, vysoko optimalizovaný server pre komunikáciu svojho softwaru so zdrojom dát (hardwarom riadiacim technologický proces) a definovať mechanizmus na efektívnu výmenu dát medzi softwarom a hardwarom. Poskytnutím serveru s OPC rozhraním umožnia ľubovoľnému klientovi prístup k ich zariadeniu. Spolu s rastúcim počtom výrobcov hardwaru rastie aj počet klient aplikácií, ktoré sú vyvíjané v jazykoch ako Visual Basic, Delphi, C ++, alebo Java. OPC musí držať krok s týmto trendom. Microsoft pochopil trend a vyvinul OLE / COM (Object Linking and Embedding / Component Object Model) model, aby dovolil vývojárom využiť softwarové komponenty vo svojich programoch napísaných v inom jazyku. Vývojári v spoločnosti Microsoft napísali softwarové komponenty v jazyku C alebo C++ a v týchto zapúzdrili rozhrania pre prístup k dátam z dátových zdrojov. Vývojári podnikových aplikácií tak môžu napísať kód napríklad vo Visual Basicu, ktorý používa dáta priamo z priemyselného hardwaru. Cieľom všetkých špecifikácií je uľahčiť vývoj serverov pre OPC v C/C++ a dať tým vývojárom aplikácií voľnosť pri výbere programovacieho jazyka. Architektúra a dizajn rozhraní sú vyvíjané tak, aby podporovali vývoj OPC serverov aj v iných jazykoch ako C alebo C++. Široká akceptácia OPC v priemysle poskytuje viacero výhod, ako napríklad:

• výrobcovia hardwaru môžu vyvinúť len jednu sadu softwarových komponentov, ktoré zákazníci využijú vo svojich aplikáciách
• vývojári softwaru nemusia prepisovať svoje aplikácie pri zmene vlastností hardwaru
• zákazníci majú viac možností pre vývoj integrovaných podnikových systémov

S OPC je možná jednoduchá integrácia rôznorodých softwarových prostredí a platforiem (Obr. 3). Prvé verzie OPC špecifikácie boli limitované na oblasti, ktoré boli spoločné pre väčšinu poskytovateľov hardwaru, no v dnešnej dobe už OPC špecifikácia obsahuje bohatú funkcionalitu takmer vo všetkých oblastiach. Architektúra OPC využíva výhody COM rozhrania, ktoré poskytuje pohodlný mechanizmus na rozšírenie jeho funkcionality a je určená na využitie DCOM (Microsoft distributed OLE technology) modelu, aby umožnila klientom pripojenie na vzdialené servre.

Obr.3 – Integrácia rôznorodých prostredí

Ciele dizajnu OPC sú:

• jednoduchá implementácia
• flexibilné prispôsobenie sa potrebám výrobcov
• poskytnúť rozsiahlu funkcionalitu
• umožniť efektívne operácie a prenos dát

Špecifikácie OPC obsahujú sadu COM rozhraní pre použitie tvorcami klient, alebo server aplikácií a odkazy na sadu OLE automatizačných rozhraní pre vývoj klientov s podporou vyšších aplikácií ako Excel, MS SQL server, alebo Visual Basic.

Článok vznikol v rámci odboného praktika, ktoré vypracoval Jaroslav Zubák na Ústave riadenia a priemyselnej informatiky FEI STU v Bratislave.