Kontextus nélkül a gyártási adat értéktelen. Íme, mit érdemes figyelembe venni ahhoz, hogy a digitális szeméttelepből aranyrögnyi felismerések szülessenek.
Nem mindig könnyű megkülönböztetni a szemetet az értékes adattól. Emlékszünk arra a walesi mérnökre, aki 2013-ban véletlenül kidobta a laptopja merevlemezét, rajta a 8 000 darab Bitcoinjának privát kulcsaival, amelyek értéke megdöbbentő, 751 millió dollár volt? A merevlemezt (és a pénzt) soha nem találták meg. Ez értékes adat volt, szemétnek álcázva!
De a dolog fordítva is működik. Sok adat-tóban (data lake), adatbázisban és historizáló rendszerben találhatóak olyan üzemi adatok, amelyek értékesnek tűnnek, valójában azonban szemétnek számítanak.
Miért?
Mert minden kontextus nélküli adat szemét.
Az adatkontextus gazdagítja a nyers adatot
Mi az adatkontextus? Az adatkontextus (más néven adatkontextualizálás) az a folyamat, amely során a nyers adatot olyan kiegészítő információkkal látjuk el, amelyek lehetővé teszik annak teljesebb és pontosabb értelmezését. Ezek a kiegészítő információk magukban foglalják az időbélyegeket, az azonosítókat, a fizikai helyet, a szemantikát és még sok mást. A kontextus az adatot zajból cselekvésre alkalmas információvá alakítja.
Kontextus nélkül olyan vagy, mint az az ember, aki egy halom lótrágya tetején ül, és azt gondolja, hogy valahol ott kell lennie egy póninak. A lótrágya helyett most címkeértékek (tag value-k) halmán ülsz, és tudod, hogy valahol ott rejtőzik a hasznos felismerés.
Kontextus nélkül nem lehet megbízni az adatokban, nem lehet azokat értelmezni, összehasonlítani vagy automatizált döntéshozatalra használni. Nincs mesterséges intelligencia, nincs SCADA, nincs ERP és nincs üzleti intelligencia.
Az adatkontextus nyolc alapvető típusa
1. Időkontextus
A pontos idő az első és valószínűleg a legfontosabb tényező. Ha az adatokat nem lehet helyes időrendi sorrendbe állítani, semmi más nem számít. Pontos, szinkronizált idő nélkül az összefüggés-elemzés, az ok-okozati vizsgálat, az eseményrekonstrukció és a prediktív analitika is összeomlik. Mi történt előbb? A motor túlterhelődött, vagy a hőmérséklet ugrott meg?
2. Azonosítási kontextus
Ez pontosan meghatározza, mely eszköz, berendezés, modul vagy szenzor generálta az adatot. Ide tartozik az eszközazonosító, a szenzorazonosító, a hálózati azonosító és a firmware/verzió is, mivel ezek mind befolyásolhatják az adat értelmezését. Ez a hidraulikus szivattyú adata? A 14-es vagy a 15-ös présből származik? Minél közelebb kerül az adat a vállalati rendszerekhez, annál részletesebb azonosítási kontextusra van szükség.
3. Adat-eredet (data lineage)
Az adat teljes „életútját” írja le: honnan származik, hogyan gyűjtötték, mely átjárókon (gateway) vagy közvetítőkön haladt át, milyen átalakításokon esett át, változott-e a minőségi jelölése. Az erős adat-eredet megakadályozza a „rejtélyes értékek” megjelenését, biztosítja az auditálhatóságot, és kulcsfontosságú az AI/ML folyamatok validálásához.
4. Helykontextus
Két részből áll: fizikai és logikai hely. A fizikai hely sokat számíthat – nemcsak az üzem, hanem az is, hogy az üzemen belül hol történik az adatgyűjtés. Például a raktár közelében lévő gépeket eltérő hőmérséklet-ingadozás érheti. A logikai hely a gyártási szakaszt, a folyamatlépést és az ISA-95 szintet azonosítja, vagyis folyamatbeli relevanciát ad.
5. Szemantikai kontextus
A szemantika azt jelenti, mit jelent az adat: mi a célja, hogyan értelmezhető, mi a szakterületi jelentése. A nyers számokat olyan értelmes fogalmakká alakítja, mint „hűtőfolyadék-hőmérséklet”, „tengelypozíció” vagy „ciklus befejezve”. Ide tartoznak az enumerációk, állapotok és szabványos információs modellek (pl. OPC UA, ISA-95, UNS). Szemantika nélkül az adat szerkezetileg helyes, de funkcionálisan haszontalan.
6. Folyamatkontextus
Arra utal, mi történt a mérés pillanatában. Meghatározza az üzemmódot, receptet, batch számot, tételt, munkát, fázist, sebességet, terhelést stb. Ez teszi lehetővé az okfeltárást, optimalizálást és visszakövethetőséget.
7. Mérési kontextus
Az adat mennyiségi jellemzőit írja le: mértékegységek (°C, psi), skálázási tényezők, pontosság, felbontás, kalibráció, tűréshatár és minőségi kódok (jó, hibás, bizonytalan, elavult). Ez biztosítja, hogy különböző forrásokból származó értékek összehasonlíthatók és megbízhatók legyenek.
8. Szervezeti kontextus
Leírja, hogyan strukturálják és modellezik az adatokat a vállalaton belül. Ide tartozik az ISA-95 hierarchia, sablonok, standard tag-struktúrák, elnevezési konvenciók, OPC UA objektummodellek és UNS névterek alkalmazása. Ez teszi lehetővé a több telephelyes elemzést és a skálázható integrációt.
Miért fontos a kontextus?
A régi, Ipar 3.0 rendszerek kevés kontextust igényeltek. Elég volt egy kemence hőmérsékletét kiolvasni és elküldeni a SCADA rendszerbe megjelenítésre. Kevés adat mozgott az üzemi szintről a vállalati rendszerek felé.
Az Ipar 4.0, az okos gyártás és az AI chatbotok világában azonban minden megváltozott. Az adat teljes mértékben integrálódik a vállalati rendszerekbe. Az elégtelen kontextus hamis okfeltáráshoz, inkonzisztens riportokhoz, lassú hibakereséshez és félrevezető dashboardokhoz vezet. AI esetén a probléma felnagyítódik: rossz előrejelzések és „hallucinációk” jelenhetnek meg, rombolva az AI értékláncot.
Az adatkontextus multiplikátor: használhatóvá teszi az adatot. A pontos és teljes kontextus biztosítja:
- Gyorsabb hibakeresést
- Pontosabb KPI-ket
- Jobb döntéseket
- Gyorsabb OEE-javulást
- Hatékonyabb energiafelhasználást
- Megbízható adatfolyamokat
- Erősebb kiberbiztonsági pozíciót
- Szabványosított, telephelyek közötti integrációt
- Csökkentett mérnöki ráfordítást
Az adatkontextus megteremtése
A legtöbb mai edge gateway úgy kezeli az üzemi adatokat, mint egy tinédzser a szennyest: ami éppen kéznél van, azt egy kupacba dobja. Az adat mozog, megérkezik valahová – de nincs használatra kész állapotban. A tagek kriptikusak. A mértékegységek hiányoznak. Az idő csak iránymutatás. A „Press_4_Run” ENUM-ként kerül át, és „7-es számú rejtélyes értékké” válik.
Az edge gateway-ek három kategóriába sorolhatók:
1. Alap protokollkonverterek (a piac 90%-a) – például Anybus, Red Lion DA, RTA, ProSoft, Moxa, HMS Flexy, Weidmüller, Pepperl+Fuchs, Banner, ifm IoT gateway-ek. Ezek adatot mozgatnak, protokollt konvertálnak, payloadot publikálnak. Olyanok, mint a FedEx: „Nem érdekel, mi van benne, mi csak kézbesítünk.” Gazdag kontextust nem tudnak társítani.
2. Edge compute keretrendszerek – például Ignition Edge, AWS Greengrass, Azure IoT Edge, Siemens Industrial Edge, Rockwell FactoryTalk Edge. Ezekben scripteléssel vagy egyedi modellekkel lehet kontextust társítani – de ehhez dedikált mérnök kell.
3. Ipari adatközpontok (data hubok) – például HighByte Intelligence Hub, Litmus Edge (felsőbb kategória), HiveMQ Edge + Sparkplug. Ezek a komplex rendszerek képesek a fent leírt kontextusmodellezésre.
Alternatív megoldás a Real Time Automation egyszerűen használható, cellaszintű, beágyazott PLC historizálója.
Az RTConnect A-B PLC Historian könnyen telepíthető és gyorsan konfigurálható, ideális az idősoros adatgyűjtéshez. Több A-B PLC tagjeit gyűjti, normalizálja és tárolja. A felhasználó által definiált modellek igény szerint publikálhatók, előfizetés vagy külső middleware nélkül. Akár 1 TB tárhely, széles publikálási protokollkészlet (SQL, HTTP, FTP, WebSockets, USB, MQTT, e-mail) és közvetlen InfluxDB-integráció biztosítja, hogy értékes eszköz legyen az üzemeltetési, karbantartási és folyamatmérnökök számára.