OPC (Open Platform Communication) este un standard în comunicația industrială care permite conectivitate și interoperabilitate universală. Este utilizat în industria de automatizare și sistemele IT al intreprinderilor industriale. Interoperabilitatea este asigurată prin crearea și întreținerea standardelor de specificație publică (open specification).
Tehnologia OPC se bazează pe arhitectura Client/Server și este o soluție care oferă o comunicare prin standarde industriale ce permit utilizatorilor să faciliteze crearea arhitecturii și implementarea proiectelor lor.
OPC a fost conceput pentru a conecta sisteme, rețele, hardware cu diferite sisteme de operare (ex. Windows, Linux). De asemenea rolul este și procesarea și monitorizarea datelor primite de la hardware sau software. Este un open standard care oferă metode sigure de accesare și descriere al datelor (field data) care sunt trimise direct sau interogate de la dispozitivele plant-floor. Aceste metode rămân aceleași indiferent de sursă și tipul de date.
Serverul OPC oferă multe tipuri de pachete de software cu metoda de accesare a datelor de la dispozitive process control cum sunt PLC (Programable Logic Controller) sau DCS (Distributed Control System). În mod tradițional, de fiecare dată când un pachet de software vrea să acceseze date de la un dispozitiv este necesară scrierea unei interfețe sau driver personalizat.
Scopul OPC este definirea unei interfețe comune care după ce a fost odată conceput poate fi reutilizat în orice alt proiect, SCADA, HMI sau alte pachete de software. Chiar dacă un server OPC se implementează pentru un dispozitiv anume, el va putea fi reutilizat de către orice altă aplicație ce poate acționa ca un client OPC.
OPC Unified Architecture oferă: interoperabilitate și standardizare. În timp ce OPC-ul convențional a rezolvat problema interoperabilității la nivelul de Control, a apărut necesitatea standardizării layer-elor de la nivelul Enterprise și până la plant-floor inclusiv. OPC-ul clasic este bazat pe Microsoft DCOM care poate duce la vulnerabilitatea acestor layer-e. Cerința pentru simplicitate, interoperabilitate și securitate maximă a determinat OPC Foundation să creeze o metodă unificată a comunicării de date privind partea specificațiilor OPC DA (Data Access), HDA (History Data Access), A&E (Alarms and Events) și Security.
OPC Unified Architecture extinde protocolul de comunicare de mare succes al OPC, permițând colectarea de date, modelarea informațiilor și o comunicare mai fiabilă și mai sigură dintre plant-floor și enterprise layer.
OPC este un set de interfețe grupate în categorii, fiecare fiind dedicată unei funcționalități aparte. Categoria este utilizată și pentru a distinge versiuni noi ale aceleiași grupe de interfețe. Fiecare categorie de interfețe este descrisă în documente separate - o specificație având o denumire simbolică și un număr de versiune explicit (ex. OPC Data Access 3.0, OPC UA DA 2.0).
Următoarea imagine reprezintă o arhitectură simplificată al OPC UA, compusă din cele două elemente principale: serverul și clientul.
Serverul conține Address Space-ul pus la dispoziția clienților (informații detailate mai jos), care în exemplul de mai sus poate reprezenta un dispozitiv cum ar fi un senzor termic, un manometru sau un comutator feroviar etc. Modelul informațional conține tipul exact al dispozitivelor și al relațiilor dintre ele, de ex. valoarea senzorului termic este stocat într-un câmp de tip double, float ori într-unul mai complex.
Clientul interoghează Address Space-ul, de exemplu toate componentele unui comutator feroviar și le prezintă utilizatorului ca pe o interfață grafică. Clientul are posibilitatea de a vedea toate datele provenite de la componente și primește alarme și evenimente cu privire la starea acestora. De exemplu, în cazul în care manevra de schimbare a unui comutator feroviar a avut loc cu succes, clientul va primi un eveniment și între timp toate datele componentelor participante la manevră se vor actualiza la client: consumul de energie electrică, temperatura motorului de comutare. În cazul în care manevra a eșuat, clientul va primi o alarmă conținând datele care indică problema.
În cele mai multe cazuri, conexiunea dintre client și server utilizează layerul network, de exemplu Internet sau LAN, care în funcție de configurare poate fi o conexiune securizată. SDK-urile oferă posibilitatea ca serverul și clientul să fie implementate prin diferite limbaje de programare, iar prin aceasta ele capătă independență față de platformă.
Pentru ca sistemul să fie interoperabil, mecanismul de transfer al datelor trebuie asociat unui model consistent de reprezentare al informațiilor. OPC UA folosește obiectul ca un concept fundamental pentru reprezentarea datelor și a activității unui subsistem. Obiectele sunt substituenți pentru variabile, evenimente și metode fiind interconectate prin referințe. Acest concept este similar cu binecunoscuta programare orientată pe obiecte (OOP). Modelul de informații OPC UA furnizează caracteristici cum sunt abstractizarea datelor, încapsularea, polimorfismul și moștenirea.
Metamodelul OPC UA permite definirea unui model informațional prin definirea obiectului, variabilei și a tipului de date, precum și a tipului de referințe. Specificația definește modelul informațional de bază care la rândul său conține deja o serie de tipuri de bază.
Unul dintre principalele scopuri ale OPC UA este expunerea informației care poate fi utilizată de clienți pentru a administrara procesul de bază în timp real. De asemenea, se urmărește integrarea procesul de control și sistemul de management într-un mediu omogen. De obicei, clienții au nevoie numai de o parte anume a informațiilor ce le stau la dispoziție la un moment dat. Pentru a putea face față acestei solicitări informația publicată trebuie să fie bine organizată și accesibilă în mod selectiv ca o entitate (node) cu adresă concretă . Colecția acestor noduri puse la dispoziție de către OPC UA server este denumită Address Space și descrierea acestuia se numește Information Model.
Imaginea de mai sus reprezintă o abordare grafică al unui model deja implementat. În vederea unei explicații mai ușoare, imaginea poate fi împărțită în două părți de săgeata orizontală: în partea dreaptă este modelul de informații care conține tipurile de date și în partea stângă este Address Space-ul bazat pe aceste tipuri. Săgeata orizontală din imagine este așa numita "HasTypeDefinition". Nodurile "First Name" și "Last Name" al obiectulului "Who", respectiv al tipului "Person Type" sunt conectate de acestea prin "HasComponent".
Address Space este un model intern compus mai ales din noduri care reprezintă plant-floor-ul propriu-zis (senzor termic, comutator feroviar, etc.) de la care solicităm și așteptăm date sau primim evenimente.
Aplicația client al OPC UA este un browser generic utilizat pentru a explora și manipula Address Space-ul unui anumit server. Clientul deține funcționalități precum navigarea prin Address Space, citirea și scrierea atributelor unui nod, subscrierea la evenimente și modificările de date (venind de la layerul din plant-floor sau cel din control) și multe alte posibilități de a apela metode. Address Space este stocat într-o sursă de date specială (bază de date sau fișier XML) și în momentul pornirii server-ului este încărcat în totalitate în memoria acestuia, conferind astfel clientului un acces rapid la informațiile solicitate din Address Space.
Conținutul Address Space-ului, respectiv datele care reprezintă plant-floor-ul sunt create/modelate de către programe de modelare aparținând unui anumit SDK, iar din modelul creat se generează un cod utilizat de serverul OPC UA.
Fiecare SDK vine cu un modeler cu ajutorul căruia se poate construi Address Space-ul, adică acel model care reprezintă dispozitivul plant-floor.
O aplicație "" modeler "" prin adăugarea de noduri și referințe, face posibilă vizualizarea Address Space-ului pe interfața grafică, prezentând modelul proiectat în mod ierarhic și grafic. Prezentarea grafică urmează instrucțiunile și sintaxele OPC UA. La sfârșit, printr-o singură apăsare de buton generează un cod cum ar fi C, C++, C#, Java. Astfel, implementarea este mai rapidă, iar calitatea software-ului mai bună, deoarece codul generat este bine structurat și fără erori. Prin reducerea implementării la "modelare și generare" pot fi implementate foarte rapid chiar și modelele complexe.
Evenimentele sunt recepționate prin subscriere la EventNotifier. În mod obișnuit, ele nu sunt vizibile în Address Space, dar există câteva excepții, cum sunt Alarms și Conditions. Evenimentele sunt tipizate, iar în funcție de un anumit tip evenimentul are diferite câmpuri. OPC UA definește o ierarhie de bază a tipurilor de evenimente, care poate fi extinsă. În cazul în care problema este unică, acestea trebuie extinse cu tipuri proprii, pentru a putea recepționa date privind starea sistemului, a procesului din background etc.
Specificațiile existente al OPC COM se concentrează pe date sau evenimente, dar multe aplicații necesită operatiuni mai complexe care nu pot fi reduse la o singură dată sau un singur eveniment. Prin metodele OPC UA serverele permit clienților de a invoca funcții complexe cu un set de parametri. Funcțiile pot fi utilizate pentru a controla un proces background care declanșează evenimente de raportare a progresului acestuia.
Câteva dintre funcționalitățile OPC UA sunt oferite ca service-uri. De exemplu, următoarele service-uri sunt implementate de către server și folosite de către clienți: CreateSessionService - pentru a stabili conexiunea între server și client, BrowseService - pentru a explora Address Space-ul, ReadService - pentru a citi date de pe server, WriteService - pentru a actualiza date pe server, etc.
Read Service este utilizat pentru a citi unul sau mai multe atribute ale unor sau mai multe noduri. Permite citirea subseturilor de elemente sau al unui singur element dintr-o mulțime de valori. În Address Space fiecare nod are atribute prestabilite care de obicei pot fi doar citite și determină starea și validitatea nodului. Atributele care sunt adăugate pe parcursul modelării și dezvoltării conțin informații care provin de la layer-ul din plant-floor. Cu ajutorul Read Sevice, clienții pot solicita de la server informații privind validitatea unui nod și despre datele pe care le conține și care provin de la plant-floor.
Write Service este utilizat pentru a scrie unul sau mai multe atribute ale unor sau mai multor noduri. Permite atât scrierea de subseturi, cât și a unor elemente individuale dintr-o multitudine de valori. Ca cele mai multe OPC UA Service-uri, Write Service este optimizat pentru a scrie mai multe operațiuni în același timp și nu pentru a scrie un singur atribut de valori. Clienții OPC UA pot scrie datele existene în Address Space, iar aceste schimbări pot atinge nivelul layer-ului din plant-floor sau ajung numai la nivelul control-ului.
Având în vedere independența față de platformă și faptul că utilizează tehnologia Web service state-of-the-art, ne putem aștepta ca OPC UA să fie aplicat într-o gamă din ce în ce mai largă de industrii și aplicații.
Caracteristicile cheie și beneficiile OPC UA sunt:
|
|
Acces unificat OPC UA integrează specificațiile OPC existente: DA, A&E, HDA, Commands, Complex data and Object Types, într-o singură specificație. |
|
|
Acces prin Firewall și prin Internet OPC UA utilizează securitate la nivel de mesaj ceea ce înseamnă că mesajele pot fi transmise prin HTTP, port UA TCP sau orice alt port disponibil. |
|
|
Fiabilitatea OPC UA implementează timeout-uri configurabile, detectarea erorii și recuperarea comunicațiilor cu eșec. OPC UA permite comunicarea cu redundanță între aplicațiile diferiților furnizori. |
|
|
Securitate OPC UA este sigur implicit, cu posibilitate de encriptare și utilizează un sistem avansat de tratare a certificatelor de securitate |
|
|
Independență față de platformă OPC UA este conceput pentru a fi independent de platformă. Utilizând SOAP/XML prin HTTP, OPC UA poate fi rulat pe Linux, Windows XP Embedded, VxWorks, Mac, Windows 7 și alte platforme Windows clasice. |
OPC Unified Architecture, Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm, Springer, 2009
de Dan Suciu
