2 products
PC-Control 03 | 2014
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. Nagymennyisé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? A gyors, dinamikus termelést lehetővé tevő Ipar 4.0 koncepció megfelelő
szintről érkező kérésekre reagálnak. Az alsóbb szint mindig szerverként működik
hálózati kapcsolatot és kommunikációt igényel az eszközök és szolgáltatások
és reagál; egy képi megjelenítés kérhet például állapotra vonatkozó adatokat
között. Képeseknek kell lenniük az egymás közötti közvetlen kommunikációra.
a PLC-től, vagy új termékreceptúrákat továbbíthat a PLC-nek. Az első lépés az
Az érzékelők, mérőeszközök, RFID chipek, PLC vezérlők, HMI, MES és ERP
elektromos érzékelő jelének az átalakítása digitális információvá. Ezt a PLC-ben
rendszerek mind fontos termelési adatokat szolgáltatnak a vállalatok számára.
egy időbélyeg kiosztása követi valamint az információnak a MES-IT szintre
Hagyományos vezérlési architektúrákban az adatkérések eseményvezéreltek,
történő átvitele további szolgáltatások segítségével (1. ábra).
vagy ciklikusan kezdeményezik őket, és mindig „fentről jövő”, azaz a kliens-
PC-Control 03 | 2014
products 3
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.
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, pl. az IT kontextusában (2. ábra). 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:
2. ábra: az „IT” és az „automatizálás” kommuni-
egy ERP alkalmazás információt cserél egy MES alkalmazással. A csere,
kációs összefüggésében három potenciális kom-
például a HMI és MES, a MES és MES, vagy az érzékelő és a felhő
munikációs átmenetet lehet megkülönböztetni,
között néhány milliszekundumtól több percig is eltarthat.
függetlenül a „kemény” és „puha” valósidejű
2. “B2M” kommunikáció: egy „puha valósidejű” folyamat kommunikál a
követelményektől: “B2B”, “B2M” és “M2M”.
„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ő, pl. é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.
4 products
PC-Control 03 | 2014
3. “M2M” kommunikáció: két folyamat kommunikál automatizálási kontextus ban 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ósidő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ú, pl. 100 μs-os válaszidő fogja meghatározni.
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é-
Az „M2M” kifejezést már használják a mobil rádiókommunikációban, ahol az
nyezi az adatkapcsolatot.
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. 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
4. ábra: a módszer meghívásának blokkdiagramja.
é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
külsőleg OPC UA-n keresztül szemantikailag azonos módon teszik elérhetővé,
Hivatal, a BSI (Bundesamt für Sicherheit in der Informationstechnik) szerint az
pl. képi megjelenítéshez és MES/ERP feladatokhoz. Ez jelentősen csökkenti a
OPC UA-ba integrált „tervezett biztonság” lényegesen jobb, mint más proto-
műszaki ráfordításokat. Például egy 20 adatpontot tartalmazó funkcióblokkban
kollokban, ezért most elemezzük aktuális projektünkben, tekintettel arra, hogy
ahelyett, hogy az egyes adatpontokat vizualizációs maszkhoz vagy egy MES
mennyire fontos az Ipar 4.0 számára.
rendszerhez kötnénk, most már elegendő egyetlen objektumhoz csatlakoztatni – és ezt más gyártókéihoz is ugyanúgy megtehetjük.
Az adatok konszolidálásának, valamint 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,
Az „OPC UA kliens funkcióblokkok az IEC 61131-3 szabványhoz” elnevezésű
intelligens alkalmazásokhoz anélkül, hogy magas szintű intelligenciára vagy
PLCopen specifikáció elfogadása lett a további konstruktív csoportmunka
központi tudásra volna szükség. Az OPC UA összetevőinek funkcionalitása
következő lépésének eredménye 2014 áprilisában. Így a szokásos elosztó sze-
skálázható, és már elérhető az érzékelők szintjén (pl. a szélturbinákat gyártó
rep mellett vagy annak alternatívájaként (3. ábra) a vezérlő játszhatja az aktív,
Areva jelenlegi érzékelőinek memóriahasználata 240 kB flash és 35 kB RAM
vezető szerepet a kommunikációban.
memóriánál indul) egészen az SAP rendszerig. Ennek eredményeként a PLC képes horizontálisan komplex adatstruktúrákat PLCopen: OPC UA kliens funkcionalitás a PLC-ben
kicserélni más kontrollerekkel, vagy vertikálisan egy OPC UA szerveren keresztül
A „kommunikációs feladat elindításához” szükséges a PLC vezérlőkben egy
metódusokat behívni egy MES/ERP rendszerben. Például új termék megren-
kliens komponens – ideális esetben szabványosított interfésszel. 2006 októbe-
deléseket lehívni vagy adatokat írni a felhőbe. Ez lehetővé teszi a gyártósor
rében a Beckhoff javasolta a PLCopen kommunikációs blokkok meghatározását
független működését (4. ábra).
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,
Ezekben a funkcióblokkokban rejlő lehetőségeket a megrendelők már korán
az IEC 61131-3 információs modellnek az OPC UA-ban (szerver) való leképezé-
felismerték és a Beckhoff termékekkel megvalósított alkalmazások előnyeiben
sét (mapping) közös specifikációként fogadták el. A gyakorlatban ez azt jelenti,
részesülhettek. Silvo Merz, a „Zweckverband Wasser und Abwasser Vogtland“
hogy egy PLC program, ami megfelel az IEC 61131-3 szabványnak, változatla-
(Vogtlandi Víz- és Szennyvíz Szövetség) kompakt beágyazott CX9020 PC-alapú
nul betölthető az IEC-be különböző gyártók saját, eltérő műszaki eszközeinek
vezérlőket használt egy intelligens hálózat létrehozására 300 helyi vízgazdálko-
a felhasználásával saját PLC-ikbe. A kontrollerek adataikat és információikat
dási rendszer között. A tényleges objektumokat, pl. szivattyúkat az IEC 61131-3
PC-Control 03 | 2014
products 5
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.
6. ábra: külső alkalmazás esetében az IEC 61131-3 PLC módszereit könynyedén lehet jóváhagyni.
PLC vezérlőben modellezték komplex objektumként, interaktív opciókkal. Mivel
SOA (Service Oriented Architecture – szolgáltatásorientált
az OPC UA szerver a vezérlőbe van integrálva, ezek az objektumok komplex
architektúrájú) PLC
adatstruktúraként automatikusan rendelkezésre állnak, annak érdekében, hogy
Az IEC 61131-3 szabványnak az OPC UA szerverrel történő összerendezésével
szemantikusan együttműködjenek a „külvilággal”. Az eredmény egy független
(mapping) és a PLCopen funkcióblokkok használatával a PLC gyártók már
döntéseket hozó decentralizált intelligencia, amely a problémamentes termelési
lefektettek egy fontos alapot. Az OPC UA szolgáltatásoknak egy PLC-ről más
ciklus biztosítása érdekében „szomszédainak” továbbítja az információkat vagy
eszközökbe történő meghívásának lehetősége olyan technológia, ami lehetővé
saját folyamataihoz kérdez le státuszokat és folyamatokra vonatkozó értékeket.
teszi a „B2M” eshetőségeket. Egy PLC például meg tud hívni egy szolgáltatást
A szabványosított PLCopen funkcióblokkokkal az eszközök OPC UA kliensként
egy képi/kamera alkalmazásból vagy RFID leolvasóból, közvetlenül tud kommu-
önállóan kezdeményeznek kommunikációt a PLC-től a folyamat többi eszkö-
nikálni a PLC-vel vagy adatokat tud továbbítani egy sok adatot igénylő alkalma-
ze felé, miközben képesek reagálni azok kéréseire, vagy a magasabb szintű
záshoz a felhőbe. A PLC meg tudja hívni ezeket a módszereket, de hogyan tud
rendszerektől (SCADA, MES, ERP), mint OPC UA szerverektől érkező kérésekre.
ő maga könnyen kezelhető módon szolgáltatásokat nyújtani?
Silvio Merz műszaki és üzleti szempontból is lelkesedik a megoldásért: „A korábés szerver, ami a kezdeti licensz-költségek több mint 90 %-os megtakarítását
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ő
eredményezte.”
valós időkben történő futtatására, miközben biztosított ezek egymással való
bi szabadalmazott megoldást felváltotta a CX9020 és az integrált OPC UA kliens
megbízható kölcsönhatása. Ennek alapja a TwinCAT modul nyelve, ami leírja A 2013-as Hannoveri Vásáron már bemutatták az OPC UA módszer meg-
a modulok jellemzőit, pl. a folyamat paramétereire vagy a módszerekre vonat-
hívásának egy gyakorlati megvalósulását: a Beckhoff PLC szerepelt OPC UA
kozókat.
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 folyamat-ada-
A megvalósítás nagyon egyszerű a PLC programozók számára: egy PLC eljárás
tokat továbbítottak, ellenőriztek és „OK” vagy „hiba” osztályozással láttak el.
(szabadon választható ki- és bemeneti paraméterekkel) áll rendelkezésre az
A meghívás módszere biztosította a teljesítmény és az adatok konzisztenciáját
OPC UA szerverben „service call”-ként, ami a PLC kontrollerbe egy egyszerű
(5. ábra).
„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 és programozási
6 products
PC-Control 03 | 2014
7. ábra: a MES-ből a PLC-be irányuló módszermeghívások növelik a korábban időigényes adatkézfogás mechanizmusok teljesítményét.
nyelvtől függetlenül meg tudják hívni a szükséges szolgáltatásokat, biztosítva
A jövőben az információcsere modelljei egyre fontosabbakká válnak. A PLC-nek
az adatok egységességét (6. ábra).
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
Előnyök: Hatékony, egységes adatokat nyújtó szolgáltatások
áramerősség-mérőként, ami egy mérőeszközöket gyártó vállalat specifikációján
a SOA-PLC-től:
alapul. A beágyazott vezérlőben használt operációs rendszer kívülről már nem
Jelenleg a MES szint és a PLC közötti adatcsere rendszerint időigényes kézfo-
lesz látható, biztonsági okokból az összes port le lesz zárva – az eszköz SOA
gásos eljárással történik. A MES rendszer jelzi az előírás továbbítását például a
szolgáltatásait csak az OPC UA-n keresztül kínálja, miközben megvan a biz-
vezérlőnek, és a PLC nyugtázza, hogy készen áll. Amint megtörtént a receptúra
tonság a szolgáltatások és adatok szintjéig. Az adatok és módszerek meghívása
(recipe) adatainak vétele, megtörténik az átadás nyugtázása. Egy SOA-PLC most
mellett az „OPC UA-n keresztül történő fájltovábbítás” érdekes lehetőségeket
már egyetlen kommunikációval teszi lehetővé az adattovábbítást a vezérlőhöz:
vet fel, nemcsak a helyi mérési adatok offline rögzítéséhez, hanem más felada-
az adatok értékeinek cseréje immár nem többszörös művelettel történik, hanem
tokhoz is, például az eszközkezeléshez.
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
A DKE (az elektromos, elektronikai és informatikai technológiák német bizottsá-
UA a távoli eljáráshívást (Remote Procedure Call – RPC) közvetlenül a programo-
ga) Ipar 4.0-ra vonatkozó szabványosítási ütemtervében szereplő egyetlen IEC
zott PLC funkcióblokkban teszi elérhetővé. Ez jelentősen lerövidíti a kommuni-
szabványú SOA architektúrában, az OPC UA-ban benne rejlik az a lehetőség,
káció oda-vissza útját a PLC és a MES rendszerek között és nagyobb termelési
hogy magát de facto szabványként határozza meg az Ipar 4.0 és IoT alkalmazá-
átviteli sebességhez vezethet. Emellett meglehetősen drámai módon csökkenti
sok adat- és információcseréjében. A biztonságos, horizontális és vertikális kom-
az adatkapcsolat műszaki költségeit az üzem és a felső, irányítási szint között.
muniká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-
A jelenlegi helyzet és a jövő kilátásai
t a legkisebb CX termékkel rendelkező beágyazott PC rendszerekbe is integrált
Egy SOA-PLC többet tesz annál, minthogy pusztán támogatná a PLC-be irány-
OPC UA klienssel és szerverrel kínálja. A PC-alapú TwinCAT szoftver vezérlési ar-
uló webes szolgáltatást azzal, hogy biztosítja VPN-en keresztül a biztonságot.
chitektúrája, amely az eszközök osztályainak széles körében futtatható, a Beck-
Objektumorientált adatforgalmat foglal magába aktuális és előzményadatokról,
hoff I/O terminálok nagy jelválasztékával társítva, és az integrált biztonsággal
riasztásokról és szolgáltatásokról (módszerekről) – ideértve a szükséges, biz-
rendelkező EtherCAT teljesítménye mind ideális platformot kínálnak skálázható
tonsággal összekapcsolt metaadatokat is közvetlenül a szolgáltatási és adat-
teljesítménnyel az összes jövőbeli Ipar 4.0 követelményhez.
szintbe, benne az információ modellek modellezési képességeivel – és mindez a nemzetközi IEC szabványon alapul.
A szerző: Stefan Hoppe, Beckhoff TwinCAT termékmenedzser, a PLCopen és OPC munkacsoport elnöke, az OPC Europe elnöke
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.
Bővebb információ: www.beckhoff.com/TwinCAT3
