Kihez szólunk?

Ez a sorozat nem programozók számára készült, bár programozásról is szólni fog. Célunk, hogy az átlagos automatizálási szakember - akinek ugyanúgy otthon illik lenni a rozsdamentes csőkötő kiválasztásában, mint a mérőperem méretezésben vagy a PLC programozásban - képet kapjon az OPC-ről, és ha mélyebben érdekli a téma, tudja hogy merre indulhat.

Történelem:

Mióta a mikroprocesszorok betették lábukat az automatizálás területére, gondot jelent a különböző gyártóktól, fejlesztőktől származó rendszerek, alkalmazások közötti hatékony adatcsere. Ennek piacpolitikai és technikai okai egyaránt vannak. Korábban a kulcsszó a MODBUS volt, soros vonalon, MODBUS-szal szinte mindent összeköthettünk mindennel. Ez a kapcsolat azonban master-slave, és bit- byte- word orientált, azaz elemi adatok átvitelére fejlesztett. A korszerű rendszerekben már nem bitek-bájtok szintjén kommunikálunk, hanem adatrekordok útján, melyek legalább három mezőből állnak: TERVJEL, ÉRTÉK, IDŐBÉLYEG. (Az érték is fizikai mértékegységben, nem pedig 16 bites "MZ/X" formátumban...)
Kellett hát egy adatkapcsolati mód, mely adatrekord alapú, és a versengő automatizálási cégek egyaránt elfogadják. A közös nevező: MICROSOFT. Az automatizálási rendszerekben alkalmazott PC-ken 99%-ban Windows az op.rendszer. Olyan megoldás kellett hát, mely Windows alapokon nyugszik. Bill Gates hamar rájött, hogy az automatizálási felhasználók igen fizetőképesek, így belépett az OPC Foundation-be, mely feladatul tűzte ki a szabványos adatkapcsolati ajánlás kidolgozását. 1996-ban előállt a legelső verzió.

Tömörítünk

Az OPC működésének megértéséhez nélkülözhetetlen a Windows néhány tulajdonságának megismerése. Minden OPC ismertető leírja, hogy "az OPC a Windows COM, OLE technológián alapuló módszer". Ha azonban meg akarjuk érteni a COM-ot, OLE-t, ActiveX-et, OPC-t, több ezer oldal tömény számítástechnikán kell átrágnunk magunkat. Ezt a többezer oldalt sűrítjük most ebbe a rövidke cikksorozatba.

Multitasking

azt jelenti, több feladat (látszólag) egyidőben való futtatása. Ha a Windows-unkban megnézzük, milyen programok (taszkok) futnak, láthatjuk hogy van jónéhány. Egy részüket mi indítottuk el, a többi része a Windowsnak. A legszebb az a dologban, hogy ezek nem vakon futnak egymás mellett, mint a bolygók a nap körül, hanem egymással folyamatosan kommunikálhatnak. Futó taszkjainkat úgy tekinthetjük, mint egy család tagjait, akik megegyeztek egy szabályrendszerben, pl. a garázskulcs mindig a villanyóratokban van, vagy ha a hűtőből elfogyott a tej, felírjuk a faliújságon a bevásárlólistára, stb.

OLE

Amikor telepítünk egy szoftvert a Windows-ba, nem csak az történik hogy a szükséges fájlokat átmásoljuk a winchester-re. Egy nagy adatbázisba (registry) bejegyzésre kerül a telepítés alatt álló szoftver minden kommunikációs képessége is. Innen a futó programok megtudhatják a másikakról, hogy mit bízhatnak rájuk. Mint ahogyan én is tudom, hogy a fiamra nyugodtan rábízhatom a fűnyírást, mert képes a

parancsot értelmezni és végrehajtani. A programok között persze nem csak szöveginformációk vándorolnak, hanem különböző formátumú képek, dokumentumok, adattáblák, stb. Ezeket objektumoknak nevezzük.
Az objektumok leírása a Windowsban meghatározott, így egy "text", "adatcella", vagy "gif" ugyanazt kell jelentse minden alkalmazás számára. Ez a leíró szabályrendszer - erősen egyszerűsítve - a Component Object Modell, azaz COM. Ezekkel az objektumokkal háromféle dolgot csinálhatunk:

- Csatoljuk:
A Word-be becsatolhatunk pl. egy XLS-t (Beszúrás/Objekum/Fájlból készíti/Csatolás) ebben az esetben a táblázat nem kerül bele a DOC fájlba, csak a címe és megjelenése. Amikor megnyitjuk a DOC-ot, az XLS aktuális tartalma megjelenik benne. Ez azért jó, mert mindig az XLS aktuális tartalma jelenik meg. Ha viszont az XLS-t áthelyezzük, a kapcsolat szétszakad.
- Beágyazzuk:
Ha a fenti műveletsor végén a Csatolás jelölőnégyzetet nem pipáljuk ki, a Word beágyazza az objektumot. A tábla pillanatnyi állapota eltárolódik a DOC-ban. Bármi történhet ezután az XLS-sel, a DOC nem változik.
- Vezéreljük
A fenti kettő eljárásból származik az OLE név: Object Linking and Embedding. Van azonban egy harmadik lehetőség is, a vezérlés. (Microsoft terminológiával: Automation) Némely - definiált - adatobjektumok ugyanis programozhatóak. Az Excel-nek pl. kívülről nem csak adatokat küldhetünk, hanem végrehajtandó parancsokat is! Ezáltal "automatizáltuk" az Excel működését.

Láthattuk, hogy az OLE folyamataiban mindig két alkalmazás vesz részt: Az egyik, amely képes szolgáltatni az objektumot, ezt szervernek (OLE server) nevezzük. A másik, mely képes tárolni a kapott objektumot, ezt tárolónak (OLE container) hívjuk. Hogy egy szoftver képes-e OLE szerver vagy konténer lenni, és milyen tipusú objektumokat képes kezelni, az a registryben szépen le van írva. A Notepad-be például hiába akarunk képet beágyazni, nem megy. A Windows meg se próbálja neki odaadni a képet, mert a registry-ből látja hogy nincs képfeldolgozó képessége. Szöveget viszont szépen kezel, akkor is, ha azt nem TXT-ből, hanem DOC-ból copy-paste-eltük.

Hogy jön ide az OPC?

Tetszőleges tipusú objektumot és eljárást (mit csináljunk az objektummal) definiálhatunk a Windowsban. A lényeg, hogy ezek a definíciók alaposak és nyilvánosak legyenek. Az automatizálási szakmának is megvannak a tipikus objektumai (mért érték, kiadott parancs, sémakép, napi jelentés, batch report, stb.) és tipikus eljárásai (megjelenít, végrehajt, nyugtáz, archivál, riaszt, stb.) Ezeket kell korrekt módon leírni. Ki képes erre? Csakis a profi automatizálási cégek. Ki ismeri a Windows belvilágát? A Microsoft.
Ez a közös munka eredményezte azt az objektum- és eljárás-leíráshalmazt amit OPC ajánlásnak nevezünk.