Egy ipari digitalizációs projekt bemutatóján rendszerint két dolog látványos: a fizikai eszköz, amely mér, és a képernyő, amelyen megjelenik az eredmény. A kettő közötti út kívülről gyakran egyetlen nyílnak látszik.

Pedig ebben a nyílban van a munka jelentős része.

Egy nyers szenzorjelből nem automatikusan lesz megbízható üzleti információ. Közben kezelni kell az elektromos jelet, a protokollt, az időbélyeget, az eszközazonosságot, a mértékegységet, a hálózati kimaradást, az adatminőséget, a jogosultságot, a tárolást, a kontextust és végül azt is, hogy az adat milyen folyamatot indítson el.

A mérési pont: ahol a fizikai világ adattá válik

Az adatút a szenzornál, mérőnél vagy vezérlőnél kezdődik. Ez lehet villamos teljesítménymérő, hőmérséklet-érzékelő, rezgésérzékelő, vízmérő, inverter, PLC, impulzusadó vagy egyedi elektronika.

Már itt eldől néhány alapvető kérdés:

  • mit mérünk valójában;
  • milyen pontossággal és felbontással;
  • milyen gyakran kell mintát venni;
  • milyen fizikai és elektromágneses környezetben működik az eszköz;
  • milyen kommunikációs interfész áll rendelkezésre;
  • elveszíthető-e adat, ha átmenetileg nincs kapcsolat.

Egy kétmásodperces teljesítménymérés és egy ötpercenként érkező hőmérsékletadat nem ugyanazt az adatkezelést igényli. Egy rezgésanalízishez szükséges nagyfrekvenciás mintasor pedig teljesen más terhelést és helyi feldolgozást jelenthet, mint egy napi vízóraállás.

A terepi kommunikáció: a valóság ritkán REST API

Az irodai informatikában természetes elvárás az IP-hálózat és a dokumentált API. A terepen ezzel szemben gyakori az RS-485, Modbus RTU, Modbus TCP, impulzusjel, digitális vagy analóg I/O, gyártóspecifikus protokoll és évtizedes eszközpark.

Itt nem elég tudni, hogy „Modbus”. Ismerni kell többek között:

  • az egységazonosítót (unit ID);
  • a regisztercímzést;
  • az adattípust, a bájt- és a szósorrendet;
  • a skálázási tényezőt;
  • a lekérdezési gyakoriságot;
  • a busz fizikai kialakítását és lezáró ellenállását;
  • a kommunikációs hibák kezelését.

Egy hibásan értelmezett 32 bites lebegőpontos értékből könnyen lehet fizikailag képtelen mérési eredmény. Ha a rendszer ezt ellenőrzés nélkül továbbítja, a hiba a teljes adatláncon végigterjed.

A gateway: fordító, puffer és helyi döntési pont

A gateway köti össze a terepi és az informatikai világot. Feladata lehet a protokollok közötti fordítás, az adatok normalizálása, időbélyegzése, pufferelése, titkosítása és továbbítása.

Egy ipari gateway-nek azonban azzal is számolnia kell, hogy a hálózat nem mindig elérhető. Ilyenkor nem jó megoldás az adatok egyszerű eldobása. Helyi tárolásra, sorba állításra és későbbi szinkronizációra lehet szükség.

Bizonyos döntéseket szintén helyben kell meghozni. Ha egy határérték túllépése azonnali lekapcsolást vagy riasztást igényel, nem érdemes megvárni a felhőbe és vissza vezető adatút eredményét. A gateway ezért sok esetben edge computing eszköz is.

Üzenetközvetítés: adat helyett esemény

Az MQTT és más üzenetközvetítő megoldások lehetővé teszik, hogy az adatforrás és a feldolgozó rendszer ne közvetlen, merev kapcsolatban álljon egymással. A gateway publikál, a jogosult rendszerek pedig feliratkoznak a szükséges topicokra.

Ettől a rendszer rugalmasabbá válhat, de a tervezési kérdések nem tűnnek el:

  • hogyan épül fel a topic-struktúra;
  • hogyan azonosítható az eszköz és a telephely;
  • milyen QoS-szint (kézbesítési garancia) szükséges;
  • megengedett-e az üzenetek ismétlődése;
  • hogyan történik a hitelesítés és jogosultságkezelés;
  • mi garantálja az üzenet eredetét és sértetlenségét.

A jó üzenet nem csupán egy szám. Tartalmazza vagy egyértelműen meghatározhatóvá teszi, hogy honnan, mikor, milyen minőségben és milyen jelentéssel érkezett.

Feldolgozás és normalizálás

A beérkező adatot sok esetben tisztítani és értelmezni kell. Ide tartozhat:

  • a nyers érték skálázása;
  • mértékegység-konverzió;
  • hibás vagy hiányzó értékek felismerése;
  • duplikátumok kezelése;
  • eszköz- és helyadatok hozzárendelése;
  • határérték- és állapotlogika;
  • származtatott mutatók számítása.

Egy 23871 érték önmagában semmit nem mond. Lehet 23 871 W pillanatnyi teljesítmény, 0,1-es skálázással 2 387,1 kW, göngyölített energiaszámláló-állás vagy hibakód. Az adat csak a megfelelő metaadatokkal és üzemi kontextussal együtt válik értelmezhetővé.

Tárolás: nem minden adat ugyanabba az adatbázisba való

Az eszközök, ügyfelek, telephelyek és szerződések törzsadatai más jellegűek, mint a másodpercenként érkező mérési sorok. Ezért egy ipari platform gyakran többféle adattárolási megoldást használ.

A relációs (tranzakciós) adatbázis a kapcsolatok, jogosultságok és üzleti objektumok kezelésében erős. Az idősoros vagy oszloporientált tárolás nagy mennyiségű mérési adat gyors elemzésére alkalmas. A dokumentumtár pedig jegyzőkönyveknek, képeknek és kapcsolódó fájloknak ad helyet.

Nem az a jó rendszer, amely mindenre ugyanazt az adatbázist erőlteti, hanem amelyik egységes üzleti modellt épít a különböző tárolási feladatok fölé.

Az üzleti kontextus: ettől lesz értéke az adatnak

A mérési érték akkor válik vállalati információvá, amikor kapcsolódik valamihez:

  • egy berendezéshez;
  • egy helyiséghez vagy telephelyhez;
  • egy ügyfélhez;
  • egy költséghelyhez;
  • egy szerződéshez;
  • egy termelési művelethez;
  • egy karbantartási előzményhez.

Az OrigSmart platform egyik alapelve, hogy a fizikai és üzleti világ adatai közös környezetben találkozzanak. Így a mért értékből nemcsak grafikon, hanem riasztás, feladat, munkalap, elszámolás vagy vezetői döntési információ lehet.

Az adatút vége valójában egy új folyamat kezdete

Ha egy motor áramfelvétele eltér a megszokottól, a rendszer jelezhet. De az üzleti eredményhez azt is tudni kell, ki kapja a jelzést, milyen határidővel, milyen eszközadatokkal, hogyan dokumentálja a beavatkozást, és miként ellenőrizhető, hogy a probléma megszűnt-e.

Az OrigSmart teljes értékláncban gondolkodik:

szenzor → terepi kommunikáció → gateway → adatfeldolgozás → esemény → feladat → visszacsatolás.

Ezért tudunk ott is projektet indítani, ahol még nincs kész API, sőt akár megfelelő mérési pont sem. Ha szükséges, az érzékelési és kommunikációs réteget is megtervezzük, majd ugyanahhoz a platformhoz kapcsoljuk az automatizációt és az üzleti folyamatot.

Az ipari integráció valódi kérdése tehát nem az, hogy meg tudunk-e jeleníteni egy szenzorértéket.

Hanem az, hogy az érték teljes útja ellenőrzött, értelmezhető és végrehajtható működéssé alakítható-e.

Beszéljük át az Ön projektjét

Források