A TÉMA
CÍMLAPON
AUTOMATIZÁLÁS
TwinCAT 3 SOA-PLC Az Ipar 4.0 előfutára és a „Dolgok Internetje” Az Ipar 4.0 és a „Dolgok Internetje” (Internet of Things – IoT) olyan koncepciók, melyek az eszközök és szolgáltatások között nagyfokú kommunikációt és kapcsolatot igényelnek. Nagy mennyiségű adatok cseréjére van szükség az érzékelők szintjétől az IT szintig. A PC-alapú vezérlés megfelelő protokolljai és szabványai ideálisak erre a feladatra. Az IoT és az Ipar 4.0 megvalósíthatóságához hozzájáruló további alapvető tényező a SOA (Service Oriented Architecture – szolgáltatásorientált architektúrájú) PLC. A PLC webes szolgáltatáson keresztül történő elérése nem új dolog. Mi tehát a SOA és pontosan mi is az új a „SOA-PLC”-ben? Milyen hozzáadott értéket kínál?
1. ábra: a jövőben a hagyományos ’automatizálási piramis’ hierarchiája az OPC UA minden szinten történő integrálásával az automatizálási szolgáltatások hálózatává fog válni. Az eszközök és szolgáltatások közvetlenül fognak egymással „kommunikálni” SOA szolgáltatások meghívásával.
A gyors, dinamikus termelést lehetővé tevő Ipar 4.0 koncepció megfelelő hálózati kapcsolatot és kommunikációt igényel az eszközök és szolgáltatások között. Képeseknek kell lenniük az egymás közötti közvetlen kommunikációra. Az érzékelők, mérőeszközök, RFID chipek, PLC vezérlők, HMI, MES és ERP rendszerek mind fontos termelési adatokat szolgáltatnak a vállalatok számára. Hagyományos vezérlési architektúrákban az adatkérések eseményvezéreltek, vagy ciklikusan kezdeményezik őket, és mindig „fentről jövő”, azaz a kliens szintről érkező kérésekre reagálnak. Az alsóbb szint mindig szerverként működik és reagál; egy képi megjelenítés kérhet például állapotra vonatkozó adatokat a PLC-től, vagy új termékreceptúrákat továbbíthat a PLC-nek. Az első lépés az elektromos érzékelő jelének az átalakítása digitális információvá. Ezt a PLC-ben egy időbélyeg kiosztása követi, valamint az információnak a MES-IT szintre történő átvitele további szolgáltatások segítségével (1. ábra).
az automatizálási kontextus, például vezérlési célra meghatározott PLC), másrészt „puha valósidejű” szolgáltatások, például az IT kontextusában (2. ábra).
Az Ipar 4.0 megjelenésével a szinteknek ez a szigorú elkülönítése és az információáramlás felülről lefelé való haladása elkezd fellazulni és keveredni. Egy intelligens hálózatban az egyes eszközök vagy szolgáltatások önállóan kezdeményezhetnek kommunikációt más szolgáltatásokkal.
B2B – B2M – M2M
Általában az Ipar 4.0-ban és az IoT csoportokban meghatározott összes kommunikációs forgatókönyvet és felhasználási esetet elvonatkozott nézőpontból a kommunikációs architektúra kétféle összefüggésében lehet megkülönböztetni: egyrészről „kemény valósidejű” szolgáltatások (azaz 18
2. ábra: az „IT” és az „automatizálás” kommunikációs összefüggésében három potenciális kommunikációs átmenetet lehet megkülönböztetni, függetlenül a „kemény” és „puha” valósidejű követelményektől: “B2B”, “B2M” és “M2M”.
Ez pontosan három potenciális kommunikációs átmenetet eredményez, ahogy azt az Ipar 4.0 WG2 végrehajtó bizottsága meghatározta: 1. “B2B” kommunikáció: két üzleti folyamat kommunikál egymással. Példa: egy ERP alkalmazás információt cserél egy MES alkalmazással. A csere, például a HMI és MES,
Te chMonitor 2014. októbe r w w w.te chmonitor.hu
a MES és MES, vagy az érzékelő és a felhő között néhány milliszekundumtól több percig is eltarthat. 2. “B2M” kommunikáció: egy „puha valósidejű” folyamat kommunikál a „kemény valósidejű” folyamattal. Példa: egy vállalati alkalmazás információt cserél egy géppel. A cseréhez szükséges idő, például élő adatok cseréje HMI és PLC, vagy MES és PLC vezérlő között néhány milliszekundumtól több percig is eltarthat. 3. “M2M” kommunikáció: két folyamat kommunikál automatizálási kontextusban egymással „kemény” vagy „puha” valós időben. Példa: egy robot platform kontrollere vezérlési információkat cserél ki horizontálisan egy kézi robotvezérlővel. A cserének kemény, meghatározott valósidejű ciklusban kell megtörténnie néhány mikroszekundumtól néhány milliszekundum alatt. Egy másik példa: két vezérlő horizontálisan cserél adatot – gyorsan („puha” valós időben), ciklikusan és terepi busztól függetlenül. Itt a meghatározottság (determinizmus) „Szolgáltatási minőségként" (QoS) fogható fel, bizonyos olyan körülményekkel, amelyeknek vagy eleget tud tenni egy kommunikációs folyamat, vagy sem; ezeket a következményeket egy garantált időtartamú, például 100 μs-os válaszidő fogja meghatározni. Az „M2M” kifejezést már használják a mobil rádiókommunikációban, ahol az M2M az eszközöknek IT folyamatokkal végzett mobil kommunikációs összeköttetésére utal. Ilyen összefüggésben az a széles körben elterjedt nézet, hogy M2M-ről van szó minden alkalommal, amikor SIM kártyát használnak.
A TÉMA CÍMLAPON AUTOMATIZÁLÁS
szerkezetüknek és céljaiknak (metaadatok) köszönhetően az OPC UA különösen alkalmas a gépek közötti elosztott, intelligens alkalmazásokhoz anélkül, hogy magas szintű intelligenciára vagy központi tudásra volna szükség. Az OPC UA összetevőinek funkcionalitása skálázható, és már elérhető az érzékelők szintjén (például a szélturbinákat gyártó Areva jelenlegi érzékelőinek memóriahasználata 240 kB flash és 35 kB RAM memóriánál indul) egészen az SAP rendszerig.
PLCopen: OPC UA kliens funkcionalitás a PLC-ben
A „kommunikációs feladat elindításához” szükséges a PLC vezérlőkben egy kliens komponens – ideális esetben szabványosított interfésszel. 2006 októberében a Beckhoff javasolta a PLCopen kommunikációs blokkok meghatározását az OPC UA alapján. Három évvel később ez egy közös PLCopen és OPC UA munkacsoport létrehozását eredményezte a Beckhoff vezetése alatt. 2010-ben, az IEC 61131-3 információs modellnek az OPC UA-ban (szerver) való leképezését (mapping) közös specifikációként fogadták el. A gyakorlatban ez azt jelenti, hogy egy PLC program, ami megfelel az IEC 61131-3 szabványnak, változatlanul betölthető az IEC-be különböző gyártók saját, eltérő műszaki eszközeinek a felhasználásával saját PLC-ikbe. A kontrollerek adataikat és információikat külsőleg OPC UA-n keresztül szemantikailag azonos módon teszik elérhetővé, például képi megjelenítéshez és MES/ERP feladatokhoz. Ez jelentősen csökkenti a műszaki ráfordításokat. Például egy 20 adatpontot tartalmazó funkcióblokkban ahelyett, hogy az egyes adatpontokat vizualizációs maszkhoz vagy egy MES rendszerhez kötnénk, most már elegendő egyetlen objektumhoz csatlakoztatni – és ezt más gyártókéihoz is ugyanúgy megtehetjük.
Bármilyen kifejezés is fogja végül meghatározni a három Az „OPC UA kliens funkcióblokkok az IEC 61131-3 szabkategóriát, a tény az, hogy a kommunikáció az IoT-ben ványhoz” elnevezésű PLCopen specifikáció elfogadása lett és az Ipar 4.0-ban már nem pusztán adatokon és az adat- a további konstruktív csoportmunka következő lépésének kommunikáció együttműködési képességén alapul majd. eredménye 2014 áprilisában. Így a szokásos elosztó szerep Információs modellek cseréjére, így a szemantikai együtt- mellett, vagy annak alternatívájaként (3. ábra) a vezérlő működési képességre (interoperabilitásra) fog összpon- játszhatja az aktív, vezető szerepet a kommunikációban. tosulni. Az egyik fontos tényező az átvitel sértetlensége (integritása) és az egyes adatokhoz és szolgáltatásokhoz való hozzáférési jogok biztonsága lesz. Mindezek a követelmények alapvető szempontjai az OPC Unified Achitecture-nak (OPC UA – egységesített architektúra). Ez egy leíró nyelvet és az információs modellek kommunikációs szolgáltatásait tartalmazza. IEC 62541 szabványként az OPC UA-t úgy alakítottuk ki, hogy leképezze más szervezetek, egyebek mellett például a BACnet, PLCopen, IEC 61850, AIM AutoID és MES-DACH információs modelljeit. A német Információbiztonsági Szövetségi 3. ábra: a PLCopen/OPC UA kliens blokkok terepibusztól független, gyors kommunikációt tesznek lehetővé. Hivatal, a BSI (Bundesamt für Sicherheit in der A TwinCAT PLC az integrált OPC UA klienssel kezdeményezi az adatkapcsolatot. Informationstechnik) szerint az OPC UA-ba integrált „tervezett biztonság” lényegesen jobb, mint más protokollokban, ezért most elemezzük aktu- Ennek eredményeként a PLC képes horizontálisan kompális projektünkben, tekintettel arra, hogy mennyire fontos lex adatstruktúrákat kicserélni más kontrollerekkel, vagy az Ipar 4.0 számára. Az adatok konszolidálásának, valamint vertikálisan egy OPC UA szerveren keresztül metódusokat Te chMonitor 2014. októbe r w w w.te chmonitor.hu
19
A TÉMA CÍMLAPON AUTOMATIZÁLÁS
4. ábra: a módszer meghívásának blokkdiagramja.
behívni egy MES/ERP rendszerben. Például új termék megrendeléseket lehívni vagy adatokat írni a felhőbe. Ez lehetővé teszi a gyártósor független működését (4. ábra).
Ezekben a funkcióblokkokban rejlő lehetőségeket a megrendelők már korán felismerték és a Beckhoff termékekkel megvalósított alkalmazások előnyeiben részesülhettek. Silvo Merz, a „Zweckverband Wasser und Abwasser Vogtland“ (Vogtlandi Víz- és Szennyvíz Szövetség) kompakt beágyazott CX9020 PC-alapú vezérlőket használt egy intelligens hálózat létrehozására 300 helyi vízgazdálkodási rendszer között. A tényleges objektumokat, például szivat�tyúkat az IEC 61131-3 PLC vezérlőben modellezték komplex objektumként, interaktív opciókkal. Mivel az OPC UA szerver a vezérlőbe van integrálva, ezek az objektumok komplex adatstruktúraként automatikusan rendelkezésre állnak, annak érdekében, hogy szemantikusan együttműködjenek a „külvilággal”. Az eredmény egy független döntéseket hozó decentralizált intelligencia, amely a problémamentes termelési ciklus biztosítása érdekében „szomszédainak” továbbítja az információkat vagy saját folyamataihoz kérdez le státuszokat és folyamatokra vonatkozó értékeket. A szabványosított PLCopen funkcióblokkokkal az eszközök OPC UA kliensként önállóan kezdeményeznek kommunikációt a PLC-től a folyamat többi eszköze felé, miközben képesek reagálni azok kéréseire, vagy a magasabb szintű rendszerektől (SCADA, MES, ERP), mint OPC UA szerverektől érkező kérésekre. Silvio Merz műszaki és üzleti szempontból is lelkesedik a megoldásért: „A korábbi szabadalmazott megoldást felváltotta a CX9020 és az integrált OPC UA kliens és szerver, ami a kezdeti licencköltségek több mint 90%-os megtakarítását eredményezte.” A 2013-as Hannoveri Vásáron már bemutatták az OPC UA módszer meghívásának egy gyakorlati megvalósulását: a Beckhoff PLC szerepelt OPC UA kliensként és meghívott egy metódust az iTAC vállalat MES rendszeréből. Bemeneti paraméterként a MES rendszerben regisztrált RFID kódot és folyamatadatokat továbbítottak, ellenőriztek és „OK” vagy „hiba” osztályozással láttak el. A meghívás módszere biztosította a teljesítmény és az adatok konzisztenciáját (5. ábra).
SOA (Service Oriented Architecture – szolgáltatásorientált architektúrájú) PLC
Az IEC 61131-3 szabványnak az OPC UA szerverrel történő összerendezésével (mapping) és a PLCopen funkcióblokkok használatával a PLC gyártók már lefektettek egy fontos alapot. Az OPC UA szolgáltatásoknak egy PLC-ről más eszközökbe történő meghívásának lehetősége olyan technológia, amely lehetővé teszi a „B2M” eshetőségeket. Egy PLC például meg tud hívni egy szolgáltatást egy képi/kamera alkalmazásból vagy RFID leolvasóból, közvetlenül tud kommunikálni a PLC-vel vagy adatokat tud továbbítani egy sok adatot igénylő alkalmazáshoz a felhőbe. A PLC meg tudja hívni ezeket a módszereket, de hogyan tud ő maga könnyen kezelhető módon szolgáltatásokat nyújtani? A TwinCAT 3 lehetőséget kínál az IEC 61131-3, C++ és a MATLAB®/Simulink® modulok bevezetésére, különböző CPU magokba való betöltésére és különböző valós időkben történő futtatására, miközben biztosított ezek egymással való megbízható kölcsönhatása. Ennek alapja a TwinCAT modul nyelve, ami leírja a modulok jellemzőit, például a folyamat paramétereire vagy a módszerekre vonatkozókat. A megvalósítás nagyon egyszerű a PLC programozók számára: egy PLC eljárás (szabadon választható ki- és bemeneti paraméterekkel) áll rendelkezésre az OPC UA szerverben „service call”-ként, ami a PLC kontrollerbe egy egyszerű „Pragma" utasítássor hozzáadását jelenti. Az IT-biztonság és az OPC UA protokollba integrált engedélyek alapján az egyes OPC UA kliensek böngészni tudnak a TwinCAT OPC UA szerverben és az operációs rendszertől, illetve a programozási nyelvtől függetlenül meg tudják hívni a szükséges szolgáltatásokat, biztosítva az adatok egységességét (6. ábra).
6. ábra: külső alkalmazás esetében az IEC 61131-3 PLC módszereit könnyedén lehet jóváhagyni.
Előnyök: Hatékony, egységes adatokat nyújtó szolgáltatások a SOA-PLC-től
5. ábra: hatékony kommunikáció kézfogás nélkül: a TwinCAT PLC az RFID információt a MES rendszerhez OPC UA módszerű meghívással továbbítja, és utasítást kap a következő lépésre, mint ellenirányú paraméterre.
20
Jelenleg a MES szint és a PLC közötti adatcsere rendszerint időigényes kézfogásos eljárással történik. A MES rendszer jelzi az előírás továbbítását például a vezérlőnek, és a PLC nyugtázza, hogy készen áll. Amint megtörtént a receptúra (recipe) adatainak vétele, megtörténik az átadás nyugtázása. Egy SOA-PLC most már egyetlen kommunikációval teszi lehetővé az adattovábbítást a vezérlőhöz: az adatok értékeinek cseréje immár nem többszörös művelettel történik, hanem egyetlen szolgáltatásként kezeljük őket bemeneti paraméterekkel (receptúra) és kimeneti paraméterekkel (a PLC által történő nyugtázás). Más szavakkal az OPC UA
Te chMonitor 2014. októbe r w w w.te chmonitor.hu
A TÉMA CÍMLAPON AUTOMATIZÁLÁS
7. ábra: a MES-ből a PLC-be irányuló módszer-meghívások növelik a korábban időigényes adat-kézfogás mechanizmusok teljesítményét.
a távoli eljáráshívást (Remote Procedure Call – RPC) közvetlenül a programozott PLC funkcióblokkban teszi elérhetővé. Ez jelentősen lerövidíti a kommunikáció oda-vissza útját a PLC és a MES rendszerek között, és nagyobb termelési átviteli sebességhez vezethet. Emellett meglehetősen drámai módon csökkenti az adatkapcsolat műszaki költségeit az üzem és a felső, vezérlési szint között.
A jelenlegi helyzet és a jövő kilátásai
Egy SOA-PLC többet tesz annál, minthogy pusztán támogatná a PLC-be irányuló webes szolgáltatást azzal, hogy biztosítja VPN-en keresztül a biztonságot. Objektumorientált adatforgalmat foglal magába aktuális és előzményadatokról, riasztásokról és szolgáltatásokról (módszerekről) –, ideértve a szükséges, biztonsággal összekapcsolt metaadatokat is közvetlenül a szolgáltatási és adatszintbe, benne az információ modellek modellezési képességeivel – és mindez a nemzetközi IEC szabványon alapul. Napjainkban az OPC UA szerver és kliens funkcionalitásnak a vezérlőbe való integrálása intelligens hálózatok megvalósítását teszi lehetővé és magas szintű biztonságot nyújt, egyúttal pedig hozzáférési jogokat is a szolgáltatási szinthez. A jövőben az információcsere modelljei egyre fontosabbakká válnak. A PLC-nek akkor már nem egy IEC 61131-3 vezérlőként kell a „külvilág” felé mutatkoznia, ami OPC UA-n keresztül továbbítja egy folyamat adatait, hanem például áramerősség-mérőként, ami egy mérőeszközöket gyártó vállalat specifikációján alapul. A beágyazott vezérlőben használt operációs rendszer kívülről már nem lesz látható, biztonsági okokból az összes port le lesz zárva – az eszköz SOA szolgáltatásait csak az OPC UA-n keresztül kínálja, miközben megvan a biztonság a szolgáltatások és 22
adatok szintjéig. Az adatok és módszerek meghívása mellett az „OPC UA-n keresztül történő fájltovábbítás” érdekes lehetőségeket vet fel, nem csak a helyi mérési adatok offline rögzítéséhez, hanem más feladatokhoz is, például az eszközkezeléshez. A DKE (az elektromos, elektronikai és informatikai technológiák német bizottsága) Ipar 4.0-ra vonatkozó szabványosítási ütemtervében szereplő egyetlen IEC szabványú SOA architektúrában, az OPC UA-ban benne rejlik az a lehetőség, hogy magát de facto szabványként határozza meg az Ipar 4.0 és IoT alkalmazások adat- és információcseréjében. A biztonságos, horizontális és vertikális kommunikáció az érzékelőktől az IT rendszerekig tehát már ma is megvalósítható. A Beckhoff már korán megértette az OPC UA lehetőségeit és most már a SOA-PLC-t a legkisebb CX termékkel rendelkező beágyazott PC rendszerekbe is integrált OPC UA klienssel és szerverrel kínálja. A PC-alapú TwinCAT szoftver vezérlési architektúrája, amely az eszközök osztályainak széles körében futtatható, a Beckhoff I/O terminálok nagy jelválasztékával társítva, és az integrált biztonsággal rendelkező EtherCAT teljesítménye mind ideális platformot kínálnak skálázható teljesítménnyel az összes jövőbeli Ipar 4.0 követelményhez. Beckhoff előadás az IAC Nemzetközi Automatizálási Kongresszus Gyártásautomatizálás szekciójában:
Te chMonitor 2014. októbe r w w w.te chmonitor.hu
2014. október 30. 9:50 - 10:15. Dr. Josef Papenfort, Beckhoff Automation GmbH: Effective Engineering for Integrated Industry www.beckhoff.hu
