Miért építettünk saját operációs rendszert a böngészőbe?

Ha egy közepes ipari telephelyen végigkérdezzük, ki milyen rendszerrel dolgozik, ritkán kapunk rövid választ.

Az energiafelügyelet egy webes felületen fut. A technológiát egy SCADA-rendszer kezeli. A karbantartás egy másik programban — vagy még mindig egy táblázatban — él. A beszerzés az ERP-ben dolgozik. A riasztások e-mailben és telefonon érkeznek. A projekteknek, szerződéseknek és jelenléti adatoknak pedig megint saját eszközük van.

Ezek a rendszerek a maguk területén akár kiválóan is működhetnek. A gond nem feltétlenül velük van, hanem a közöttük maradó hézagokkal.

A döntés a rendszerek között vész el

Az OT-tudássorozat előző részeiben többször eljutottunk ugyanoda: a mért adat önmagában nem érték. Értéke akkor lesz, ha az eltérésből esemény, az eseményből feladat, a feladatból elvégzett munka, a munkából pedig visszamérhető eredmény lesz.

Ez a lánc azonban szinte soha nem fér bele egyetlen hagyományos szakrendszerbe.

A mérés az egyikben keletkezik. A döntést egy másikban hozzák meg. A munkát egy harmadikban rögzítik. Az alkatrészt egy negyedikben rendelik meg, a költséget pedig egy ötödikben könyvelik. Minden átadásnál valakinek másolnia, egyeztetnie és emlékeznie kell — vagy éppen elfelejtenie valamit.

Ilyenkor a vállalat gyakran nem adathiánytól szenved. Éppen ellenkezőleg: ugyanaz az információ öt helyen, öt különböző állapotban létezik.

Melyik az aktuális szám? Ki módosította utoljára? Megtörtént a beavatkozás? Valóban megszűnt a probléma? És ki látja egyáltalán a teljes folyamatot?

Nem még egy különálló alkalmazást akartunk

Erre a problémára nem egy újabb dashboarddal akartunk válaszolni. Egy újabb önálló alkalmazás ugyanis csak még egy szigetet hozott volna létre.

Ezért építettük meg az OrigSmart WebOS-t: egy böngészőben működő, közös operációs környezetet a fizikai és az üzleti működés számára.

Úgy is mondhatjuk: egy „sapka” a vállalat meglévő informatikai, energetikai és teljes adatvagyon-ökoszisztémáján. A szakrendszerek tovább végzik a saját feladatukat, a WebOS pedig közös munkakörnyezetbe kapcsolja az elérhető adatokat, felhasználókat, döntéseket és végrehajtható folyamatokat.

Ez nem pusztán egy közös képernyő vagy menürendszer. Alatta különböző rendszerek működhetnek, fölötte pedig már egy összefüggő vállalati működés követhető és irányítható. Az összekapcsolás természetesen integrációs munkát igényel: attól, hogy egy alkalmazás megjelenik ugyanazon a felületen, az adatai és folyamatai még nem válnak automatikusan közössé.

Az „operációs rendszer” elnevezés itt nem azt jelenti, hogy a Windowst vagy a Linuxot szeretnénk lecserélni. A hasonlat a működési modellről szól. Ahogy egy számítógépen az operációs rendszer ad közös alapot a felhasználóknak, jogosultságoknak, fájloknak, ablakoknak és alkalmazásoknak, úgy a WebOS közös alapot ad az eszközöknek, adatoknak, embereknek és vállalati folyamatoknak.

A felhasználó egy ismerős, ablakos munkafelületet lát. Egymás mellett nyithatja meg egy épület energiaadatait, a hozzá tartozó karbantartási feladatot, a beszállítói szerződést vagy egy kivitelezési projekt költségvetését. Az összekapcsolt folyamatokban nem kell külön rendszerekből kézzel összeraknia a teljes képet, és ugyanazt az adatot sem kell újra és újra rögzítenie.

Miért a böngészőben?

Mert a böngésző ma gyakorlatilag minden munkaeszközön rendelkezésre áll. Nincs szükség külön kliensprogram telepítésére, a frissítések központilag kezelhetők, a felhasználó pedig ugyanahhoz a munkakörnyezethez fér hozzá az irodai gépéről, egy üzemi terminálról vagy — a jogosultságaitól függően — mobil eszközről.

De a böngésző önmagában még nem tesz operációs rendszerré egy alkalmazást. Ehhez a különböző forrásokat összekapcsoló közös adatmodellre, egységes jogosultságkezelésre, valós idejű együttműködésre és egymással összekapcsolható alkalmazásokra van szükség.

Mitől több ez, mint egy újabb szoftver?

Különböző adatforrások — közös értelmezés

Az egységes működés nem jelenti azt, hogy minden adatot egyetlen adatbázisba kell költöztetni. A pénzügyi adatok maradhatnak az ERP-ben, a technológiai állapotok a SCADA-ban, a mérések az energetikai rendszerben, a dokumentumok pedig a meglévő dokumentumtárban.

A WebOS feladata, hogy ezeket közös összefüggésbe helyezze. Az egyik rendszer eszközazonosítója, a másik rendszer költséghelye és a harmadik rendszer karbantartási előzménye ugyanahhoz a valós berendezéshez kapcsolódjon. Egy ügyfél, telephely, projekt vagy szerződés így nem egymástól független rekordok halmaza, hanem közös hivatkozási pont a működésben.

Az integráció része annak meghatározása is, hogy melyik adatnak melyik rendszer a hiteles forrása, hol módosítható, és hogyan jut el a változás a kapcsolódó folyamatokhoz. Nem öt külön másolatot kell kézzel rendben tartani, hanem egy meghatározott eredetű, követhető információt használni több helyen.

Ez nem pusztán kényelmi kérdés. A közös értelmezés és a tisztázott adatgazdai felelősség csökkenti az eltérő verziókból, kézi másolásból és bizonytalan adatforrásokból eredő működési hibákat.

Valós idejű, közös munka

Ha két kolléga ugyanazt a dokumentumot, rekordot vagy költségvetési tételt nyitja meg, mindketten látják a másik változtatását. A rendszer kezeli a párhuzamos munkát, és megakadályozza, hogy valaki észrevétlenül felülírja a másik módosítását.

Ugyanez a valós idejű működés kapcsolja össze az embereket az OT-oldallal. Egy eszközről érkező új mérési adat, állapotváltozás vagy riasztás azonnal megjelenhet abban az alkalmazásban és annál a felhasználónál, ahol teendő kapcsolódik hozzá.

A közös munka így nem e-mailek és különálló fájlverziók cseréjét jelenti, hanem ugyanannak az aktuális működési állapotnak a használatát.

Pontosan szabályozott hozzáférés

Vállalati környezetben nem elég annyit meghatározni, hogy valaki hozzáfér-e egy alkalmazáshoz. Sokszor az is számít, hogy azon belül melyik adatot láthatja, és melyik mezőt módosíthatja.

Egy kivitelezési projektben például más jogosult dönteni a megrendelői árról, más rögzítheti az alvállalkozói ajánlatot, és megint más hagyhatja jóvá a beszerzést. Dolgozhatnak ugyanazon a tételen úgy, hogy mindenki csak a szerepéhez szükséges adatokat és műveleteket éri el.

Az OrigSmart WebOS ezt mezőszintig szabályozza. Nem pusztán a felület rejti el a tiltott műveleteket: a jogosultságokat a szerveroldal is ellenőrzi és betartatja. Egy nem engedélyezett módosítást akkor is elutasít, ha valaki a felület megkerülésével próbálja közvetlenül meghívni a WebOS háttérrendszerét.

Elkülönített szervezetek, közös platform

Több cég, telephely vagy ügyfél használhatja ugyanazt a platformot úgy, hogy az adatok szervezeti és jogosultsági határai elkülönülnek. Minden résztvevő a saját működési környezetét látja, miközben az arra jogosult központi szereplők összevont folyamatokat és kimutatásokat is kezelhetnek.

Ez különösen fontos szolgáltatói, cégcsoportos és több telephelyes működésben, ahol az egységes platform előnyeire szükség van, az adatok összekeveredésére viszont nyilvánvalóan nincs.

Bővíthető, nem lecserélendő

Ha új üzleti igény jelenik meg, arra új alkalmazás épülhet a meglévő felhasználókra, jogosultságokra, adatkapcsolatokra és közös szolgáltatásokra. Nem kell minden alkalommal külön belépést és önálló alkalmazási környezetet létrehozni, vagy elölről megépíteni a már működő integrációkat.

És nem kell kidobni azt sem, ami már jól működik. A WebOS nem azért készült, hogy mindenáron leváltson egy bevált ERP-t, SCADA-rendszert vagy könyvelőprogramot. Képes ezekhez kapcsolódni, átvenni vagy továbbadni a szükséges adatokat, és kezelni azt a működési láncot, amely a szakrendszerek között egyébként megszakadna.

Ugyanaz az adat, más-más döntés

Vegyünk egy egyszerű példát. Egy hűtőkompresszor energiafelvétele napok óta lassan emelkedik.

Egy hagyományosan széttagolt környezetben ezt valaki egyszer észreveszi a grafikonon. E-mailt ír. A karbantartó telefonon visszakérdez. A vizsgálat eredménye talán bekerül egy munkalapba. A cserealkatrészt egy másik rendszerben rendelik meg. A költség később megjelenik egy pénzügyi kimutatásban — de addigra az eredeti mérési eltérés és a javítás gazdasági eredménye között elveszett a kapcsolat.

Az OrigSmart WebOS-szal összekapcsolt környezetben a mérésből esemény lehet, az eseményből pedig munkalap a felelős karbantartónak. A munkalaphoz kapcsolódhat az alkatrészigény, a beszerzés és a jóváhagyás. A beavatkozás után a rendszer visszaellenőrizheti, hogy az energiafelvétel valóban visszaállt-e a normál tartományba.

Ehhez a mérés továbbra is érkezhet a meglévő energetikai rendszerből, a beszerzés történhet az ERP-ben, a feladat pedig kezelhető egy WebOS-alkalmazásban vagy egy integrált karbantartási rendszerben. A lényeg nem az, hogy minden lépés ugyanabban a szoftverben történjen, hanem az, hogy végig megmaradjon a kapcsolat az eredeti eltérés, a felelős, a beavatkozás és az eredmény között.

Ugyanazt az esetet minden szereplő a saját szempontjából látja:

• az energetikus az eltérést és a fogyasztási görbét;
• a karbantartó a hibát, az előzményeket és az elvégzendő feladatot;
• a beszerzés az alkatrészigényt és a jóváhagyott keretet;
• a pénzügy a költséget és a megtakarítás pénzügyi hatását;
• a vezető pedig a probléma teljes útját a felismeréstől az igazolt eredményig.

Nem öt különálló történetről van szó, hanem ugyanannak a működési eseménynek öt jogosultság és feladat szerint kialakított nézetéről.

Kell-e mindenkinek WebOS?

Nem.

Egy kis telephelyen, ahol egyetlen mérési és riasztási feladatot kell megoldani, elegendő lehet egy célzott alkalmazás. Ugyanez igaz arra a vállalatra is, amelynek minden lényeges folyamata valóban egyetlen, megfelelően testre szabott vállalatirányítási rendszerben működik.

Ilyen esetekben az OrigSmart egy-egy modulja — például az adatgyűjtés, a mérés vagy a riasztáskezelés — önállóan, a meglévő rendszerekhez illesztve is használható.

Sok ipari vállalat azonban nem így működik. Náluk több, különböző korú és célú rendszer él egymás mellett. Számukra a valódi kérdés nem az, hogy le lehet-e cserélni mindent egyetlen nagy projekttel, hanem az, hogy létrehozható-e a meglévő ökoszisztéma fölött egy közös, szabályozott és tovább bővíthető működési réteg.