Az OPC Data Access Automation Interfacce

A legáltalánosabb adatcseréket (írás-olvasás) ezen kereszül lehet a legkönnyebben megvalósítani. Az interfész működését egy minimális kliens vizsgálatán keresztül célszerű vizsgálni.
Tegyük fel, hogy az OPC klienst Visual Basic-ben írjuk. Ez azért fontos, mert az ezzel létrehozott alkalmazásoknak van OLE Automation interfésze. (lásd:előző rész) Az egész OPC objektumorientált, tehát a következőkben objektumokról, metódusokról, tulajdonságokról lesz szó. Az effélékkel való bánásmód ismerete nélkül is értelmezhető leírás készítése a célunk. Aki mélyebb, programozási részletekre vágyik, legjobban teszi, ha belép az OPC Foundation-be (fizetős), és ezután díjmentesen kérhet kidolgozott forráskódokat vagy lefordított DLL-t is, OPC kommunikációhoz. Olcsóbb és gyorsabb mint kitalálni és megírni az egészet.

Az OPCItem objektum

Minden egyes adat, ami az OPC szerver és a kliens között közlekedik (pl. egy nyomásérték a PLC-ből) egy OPCItem objektum. Az objektumnak számos tulajdonsága van, ezek közül most ötöt emelünk ki:

- ServerHandles: Ez egy "long" tipusú tulajdonság. Az OPC szerver minden OPCItem-hez rendel egy azonosítót, ezzel lehet azt megcímezni. A kliensnek tehát létre illik hozni egy Tagname-cím adatbázist, a könnyű kezelés érdekében.

- Value: A pillanatnyi érték. Ez egy Variant tipusú tulajdonság (régi szóhasználattal:változó), ami azt jelenti, hogy gyakorlatilag bármi lehet benne.

- EUType: Mértékegység. Amint már említettük, itt nem bitekből-bájtokból legózzuk össze a mért értéket, hanem készen kapjuk. Azért ez nem egy "string" (azaz szöveg) tipusú tulajdonság, hanem "long", azaz egy szám. Fel kell építeni egy táblázatot, mely összerendeli a mértékegység nevét és sorszámát. Erre azért van szükség, hogy gyorsítsuk az átvitelt. (Ne kelljen minden mérési adattal átvinni a hosszú mérnöki egység nevet, pl. négyzetkilóméter per fertályóra.)

- TimeStamp: A mérés időbélyege. Később ismertetjük, hogyan lehet garantálni azt, hogy a mért érték és az időbélyeg mindig szinkronban legyen. A TimeStamp természetesen "date" tipusú tulajdonság (változó).

- Quality: Az érték minősége. Felépíthetünk egy táblázatot, ami összerendel minőségeket számokkal. A Quality ugyanis "long" tipusú.

A tulajdonságok mellett nagyon fontos, hogy mit lehet csinálni az objektummal, azaz mely metódusok vonatkozhatnak rá. Ezekből kettő van:

- Read: Az OPCItem olvasása. Meg kell neki adni a forrást (melyik szerver), és beolvas egy rekordot (a fenti tulajdondágok időszinkronizált értékeit.)

- Write: Az OPCItem írása. Az írás a Value tulajdonság átvitelét jelenti.

OPCItems obektum

Hogy az adatbázisunk struktúrája hasonló legyen a technológia struktúrájához, az OPCItem-eket össze lehet (és kell) fogni OPCItems nevű csoportokba (collections). Ezekkel a csoportokkal a következő dolgokat művelhetjük (a legfontosabb metódusok):

- AddItem: A csoportba felveszünk egy új tagot. Az új tag örökli a csoportra beállított "default" tulajdonságokat, úgyhogy felvétel után ezeket át kell írni, ha szükséges (pl. mértékegység).

- Remove: Törlünk egy vagy több OPCItem-et a csoportból.

- Validate: Ellenőrzi, hogy van-e olyan OPCItem a csoportban. Létrehozás után célszerű kiadni, mert egyébként olyan OPCItem olvasásakor mely nem létezik, az olvasó metódus hibaüzenettel tér vissza, amit külön le kell kezelni a Visual Basic Err eljárásával.

- Item: A meghívott OPCItem adataival tér vissza. A címzése a csoporton belüli sorszámmal történik, tehát kell egy táblázat a sorszámokról és a ServerHandles-ekről...

OPCGroup objektum

Egy OPCGroup-ba az azonosan kezelendő OPCItems-ek kerülnek. Van sok olyan tulajdonság, mely közösen ugyanaz lehet a benne szereplő item-ekre. A - folyamatirányítási szempontból - legfontosabb tulajdonságok:

- UpdateRate: Legrövidebb frissítési idő (msec). Nyilvánvaló, hogy egy lassú folyamatban nem érdemes állandóan kérdezgetni az értékeket, mert csak foglalja a buszt (ethernet vagy soros vonal), és a PC rendszeridejét. Ennél lassabb lehet a frissítés (ha semmi nem változik).

- DeadBand: azaz holtsáv. Beállítható a méréshatár százalékában. Ha az OPCGroup-on belül egy item nagyobb mértékben megváltozik, mint a DeadBand, egy DataChange esemény következik be, amit a kliensnek kell figyelnie. Ekkor indíthat pl. egy olvasást.

Az OPCGroup-ban nem sok metódus van, de ezek közül fontosságban kiemelkedik a következő négyes:

- SyncRead: A group egy vagy több elemének értékeit olvassa be. Nagyon lényeges, hogy az olvasás két helyről történhet: Memóriából (cache) és eszközből (device). Ez azért érdekes, mert a metódus addig nem tér vissza értékkel, míg le nem futott. Ha a szerver által megszólított PLC a világ túlsó felén van és pl. interneten érjük el, az idő hosszú lehet, ha device-ból olvasunk. Ha cache-ből olvasunk az sokkal gyorsabb, de nem biztos, hogy a legfrisebb adatokat kapjuk...

- SyncWrite: Írás az eszközbe. Fontos, hogy a SyncWrite csakis eszközbe képes írni. Addig nem tér vissza a metódus (szubrutin), míg a PLC el nem fogadta, vagy vissza nem utasította a neki szánt adatokat.

- AsyncWrite: A SyncWrite-tal ellenben ez csak elküldi a PLC-nek az adatokat és visszatér. A program futhat tovább. Ha majd a PLC elfogadta az értékeket, a szerver egy AsyncWriteCompleted eseménnyel jelzi ezt.

- AsyncRead: A SyncRead-del ellentétben ez nem vár, amíg a PLC méltóztatik az adatokat feladni, csupán jelzi a szervernek, hogy kéri az adatokat. Ha az olvasás befejeződött és az adatok megvannak, egy AsyncReadComplete esemény következik be. Ezt a kliensnek figyelnie kell.

OPCServer objektum

A kliensben minden eddig említett objektum az OPCServer objektumból kell hogy származzon. Ez tehát a "gyökér könyvtára" az egész OPC-nek. A legfontosabb tulajdonságai:

- ServerNode: Meg kell adni, melyik gépen fut az az OPC szerver, melyről az adatokat kérjük. Ez a címmegadás lehet UNC, vagy DNS alapú, tehát a szerver a világon bárhol lehet, ha TCP/IP-n látható.

- ServerState: Egy OPC szervernek öt üzemmódja van: RUNNING, amikor normálisan fut, FAILED, amikor meghibásodott, NOCONFIG, ha nincs a szerver konfigurálva, de fut, SUSPENDED, ha futhatna, de a szervert megállította valami, TEST, amikor rendesen fut, de a kimeneteket nem írja ki a PLC-re, csak szimulálja ezt.

- Bandwidth: A szervernek meg kell mondania magáról, hogy milyen sávszéleséggel érhetőek el az adatai. A kliensben ezt fel lehet használni a frissítési idő beállításához, kalkulációjához.

A legfontosabb OPCServer metódusok a következők:

- GetOPCServers: Az elérhető OPC szerverek azonosítójával (progID) tér vissza. Természetesen az OPC szervernek be kell konfigurálva lenni a Windows-ba. Ezt telepítéskor a szervertől elvárható.

- Connect: A kliens hozzákapcsolódik a szerverhez (annak automation interfészéhez).

- Disconnect: A szétkapcsolódás.

- CreateBrowser: Az OPC szerver nem kötelező szolgáltatása a böngészhetőség biztosítása. Ez azt jelenti, hogy az OPCItem-ektől az OPCServer-ig egy faszerkezetet építhetnek fel magukban, amiben könnyebben eligazodhat a kliens.

Az OPCBrowser objektum:

Nagy előny, könnyebb a kliens konfiguráló felületét elkészíteni ha a szerver browse-olható. Ez is egy objektum, melynek legfontosabb metódusai:

- ShowBranches: A faszerkezet szétágazásaival tér vissza egy Variant-ban.

- ShowLeafs: Az aktuálisan kibontott "ág" végén ülő "levelek" neveivel tér vissza egy Variant-ban. Az ágakat és leveleket mint a Windows Intéző ikonocskáit képzeljük el!

- MoveUp, MoveDown, MoveRoot, MoveTo: A faszerkezetben való mozgások.


Összefoglaló:

Látható, hogy még a legegyszerűbb OPC kliens megírása sem tréfadolog. Figyelembevéve azonban az automatizálási piacon kapható professzionális szoftverek árait, sokszor érdemes lehet egy klienst megírni-megíratni. Mivel a kliens megírható VBA-ban is, mely az Excel-nek része, gyorsan, olcsón létrehozható egy alkalmazás, ami az Excelben, Explorerben sémaképeket csinál, naplóz, archivál.

Ennél azonban fontosabbnak érzem az egyedi, alkalmazásspecifikus szoftverek becsatolhatóságát. Ahogy a technológiák egyre bonyolultabbakká válnak, ezek jelentősége egyre nőni fog.


folyt. köv.