TwinCAT 3 SOA-PLC. Az Ipar 4.0 előfutára és a Dolgok Internetje

Átírás

1 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 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 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). 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, 18

2 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. 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 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 ben, az IEC 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 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 kategóriát, a tény az, hogy a kommunikáció az IoT-ben és az Ipar 4.0-ban már nem pusztán adatokon és az adatkommunikáció együttműködési képességén alapul majd. Információs modellek cseréjére, így a szemantikai együttműködési képességre (interoperabilitásra) fog összpontosulni. 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 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 Hivatal, a BSI (Bundesamt für Sicherheit in der Informationstechnik) szerint az OPC UA-ba integrált tervezett biztonság lényegesen jobb, mint más protokollokban, ezért most elemezzük aktuális projektünkben, tekintettel arra, hogy mennyire fontos az Ipar 4.0 számára. Az adatok konszolidálásának, valamint Az OPC UA kliens funkcióblokkok az IEC szabványhoz elnevezésű PLCopen specifikáció elfogadása lett a további konstruktív csoportmunka következő lépésének eredménye 2014 áprilisában. Így a szokásos elosztó szerep mellett, vagy annak alternatívájaként (3. ábra) a vezérlő játszhatja az aktív, vezető szerepet a kommunikációban. 3. ábra: a PLCopen/OPC UA kliens blokkok terepibusztól független, gyors kommunikációt tesznek lehetővé. A TwinCAT PLC az integrált OPC UA klienssel kezdeményezi az adatkapcsolatot. Ennek eredményeként a PLC képes horizontálisan komplex adatstruktúrákat kicserélni más kontrollerekkel, vagy vertikálisan egy OPC UA szerveren keresztül metódusokat TechMonitor október 19

3 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 szivatytyúkat az IEC 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). 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. SOA (Service Oriented Architecture szolgáltatásorientált architektúrájú) PLC Az IEC 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 , 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 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 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 20

4

5 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 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 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: október 30. 9:50-10:15. Dr. Josef Papenfort, Beckhoff Automation GmbH: Effective Engineering for Integrated Industry 22