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
FüvetNyír (kert, vasárnap)
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.
Mire használható?
Az OPC nem más, mint különböző windows-os alkalmazások ("programok") közötti "szabványos" kommunikáció. Lényeges kiemelni hogy alkalmazások közötti, nem pedig eszközök közötti. Jelen pillanatban a világon (egy kivételtől eltekintve) nincs olyan PLC, melyet közvetlenül OPC-n meg lehetne szólítani! Tekintsük hát, hogyan épül fel egy OPC-t alkalmazó összeállítás! A jobboldali ábrán egy egyszerű és gyakori séma látható: Egy PC valamilyen módon (soros vonal, Ethernet) kapcsolódik egy PLC-hez. A szakemberek azt mondták, a PLC-vel OPC-n fognak kommunikálni, tehát azt gondolhatnánk, OPC kommunikáció zajlik a köztük levő kábelen. Ez nem így van! Hogy miért nem, azt akkor láthatjuk, ha a szoftveres elrendezést nézzük, mely alább lesz látható. Figyeljük meg, hogy a PLC továbbra is ugyanazt a cégspecifikus kommunikációt (vagy Profibus DP-t, vagy Modbus Slave-et) beszéli mint OPC-t nem alkalmazó esetekben.
A különbség a PC-n belül van:
A baloldali ábrán jól látható a lényeg: Míg a "klasszikus" rendszerben a megjelenítőszoftver rendelkezett egy PLC interfész programmal (DLL), amin keresztül közvetlenül kommunikált a PLC-vel, az OPC használatakor a PC-n - a megjelenítőszoftvertől teljesen elkülönülten - fut egy OPC szerver alkalmazás, "aki" átveszi a PLC-vel, annak anyanyelvén való kommunikálás feladatát. Az OPC szerver egy definiált szoftveres felületen bármely olyan szoftvernek kiadja az adatokat, ill fogad utasításokat, amely szakszerűen tud kérdezni ill. parancsolni. Ezek az OPC kliensek.
Ez volt a lényeg, hiszen egy szerver több klienst is kiszolgálhat és egy kliens több szervert is kérdezhet. Ezáltal lehetővé vált, hogy mindenféle - szakszerűen megírt - windows-os alkalmazások a rendszer részévé váljanak. Lehetséges hogy egyik szoftvercégtől vesszük a megjelenítő (HMI) csomagot, a másiktól egy advanced control csomagot (neural, fuzzy, spc...), a harmadiktól az archiváló alkalmazást, a naplózó szoftvert pedig mi magunk írjuk... Az egyszem PLC "fölött" ülő OPC szerver kiszolgál mindenkit.
Ki adja az OPC szervert?
A PLC (és egyéb efféle) gyártók elemi érdeke hogy eszközeiket elérhessék az OPC kliensek. Ezért - ritkábban - saját szoftveres gárdával, vagy - gyakoribb - külső szoftveres cégekkel íratnak OPC szervert. Ezáltal még egy céggel számolni kell, amikor a kommunikációt tervezzük. Az az eset is gyakran előfordul, hogy ugyanahhoz a hardverhez több cég is kínál OPC szervert. Ezek szolgáltatásaikban nagyon különbözőek lehetnek. Szerencsére szoftvereknél gyakran működik a "try and buy" módszer, azaz módunk lehet a szoftvert kipróbálni és utána dönteni annak megvásárlásáról.
Miféle szerverek vannak?
Miként a nyelvtudásnak is vannak különböző fokozatai, úgy az OPC szerverek és kliensek is több kategóriába oszthatóak. Most röviden végigfutjuk, mik léteznek, a következő részben pedig megkezdjük a részletes tárgyalásukat. OPC Data Access A legalapvetőbb kommunikációs igények kielégítésére képes szerverek és kliensek az OPC Data Access specifikációnak kell hogy megfeleljenek. Ebben szerepelnek azok az objektumok és eljárások, melyekkel a PLC regisztereit írhatjuk-olvashatjuk, időbélyeget kezelhetünk.
OPC Alarms and Events
A riasztások és események kicsivel többet jelentenek mint a mért- vagy kiadott értékek. Más dolgokat kell velük csinálni. Van több jellemzőjük (aktív-nem aktív, nyugtázott-nem nyugtázott). Ha a felső szinten (a HMI-ben) képezzük az alarmokat, akkor erre nincs szükség. Ebben az esetben azonban sok mindenről le kell mondanunk, ilyen például a pontos időbélyegzés. Ha a megjelenítőszoftver adja az időbélyeget, sokszor nem a mért adattal egy rekordban utazó keletkezési idő kerül naplózásra, hanem az alarm fogadásakori rendszeridő...
OPC Historical Data Access
Miként a neve is mutatja, ez az ajánlás a mért adatok, események archiválásával kapcsolatos területekre fókuszál. Mivel itt adatbázisok kezeléséről van szó, szolgáltatásai hasonlatosak egy adatbázis-kezelőéhez, de annál kevesebb és az automatizálásra specializált szolgáltatásra számíthatunk. (Új archiválandó adat felvétele, tárolt adat kérelme adott időhatárok között, stb...) A helyzet tehát hasonlatos az előző fejezethez: Ha van OPC Data Access kapcsolat, mindent meg lehet az alkalmazásokon belül csinálni. Ha van Historical Data Access is, kevesebb szóval, egyszerűbben csinálhatjuk meg ugyanazokat. (Okos alkalmazások félszóból is megértik egymást...)
OPC Batch Interface
A Batch (szakaszos folyamatok automatizálása) egy külön világ. Nagy szemléletbeli fegyelmet, sok nemzetközi ajánlás és nem utolsósorban :-) az FDA előírásainak betartását igényli. A Batch-ben számos speciális objektumot kell kezelni (recept, riport, stb) ami önmagában is bonyolult rendszer, de még a bizonylati fegyelem is számos feladatot ad. Aki a gyógyszeripart kerüli, annak erre nem lesz szüksége... Interfészek Automatizálási Interfész: Minden szervernek kettő interfésze lehet. (Interfészen itt szoftveres felületet értünk.) Egyik interfész olyan, amelyet a Microsoft Visual Basic-jére optimalizáltak, és csupán a leglényegesebb dolgokat tudja. Azok viszont VB-ből egyszerűen használhatóak, aki már programozott VB-ben, az tíz perc alatt írhat egy progit, ami lekérdezi a PLC adott regisztereit egy OPC szervertől. Ennek a neve (a Microsoft-os szóhasználat miatt) Automatizálási interfész. Ez bennünket - automatizálási szakembereket - ne tévesszen meg, mi mást hívunk automatizálásnak mint Bill Gates. Emlékezzünk: Ő az Excel-t is "automatizálja", amikor utasításokat ad másik progiból neki. Hívhatnánk ezt az interfészt "easy"-nek vagy "light"-nak inkább.
Custom interface
Aki minden szolgáltatást ki akar használni, amit egy OPC szerver kínálni tud, az a Custom Interface-t használja. Ehhez C-ben kell programozni, és sokkal több dologra oda kell figyelni. Természetesen a Custom Interface gyorsabb is. Valamit valamiért... Ennek az interfésznek jobban állna a "professional", vagy a "deepwater" név.
Összefoglalva:
Mielőtt OPC szervert veszünk, járjuk utána, hogy a kiszemelt kliens alkalmazások melyik fajta szerver melyik interfészét használják. Lehet, hogy egyetlen szerver nem is lesz elég. Egy adott OPC fejlesztő cég kínálatából ezután ki kell választanunk azt a szervert mely ezzel az interfésszel rendelkezik, egyéb szolgáltatásai, kezelése, dokumentációja megfelelő! Ja, és az ár sem mellékes...