Írta: Tamás Hóringer
2019. december 11. 13:57:46 CET
Körülbelül másfél évvel ezelőtt egy partnerünk felkérésének eleget téve lehetőséget kaptunk, hogy csatlakozzunk egy olyan nagyszabású tervezési- és kivitelezési projekthez, amely amellett, hogy mind témáját, mind pedig méreteit tekintve országos szinten is figyelemre méltó, egyike a legnagyobb SCADA/HMI érintettségű munkáknak, amelyek fejlesztésében részt vettünk.
A megvalósuló rendszerben 22 egymástól földrajzilag is elkülönülő lokációban (helyszínen), közel száz GE iFIX 5.9 SCADA/HMI szoftver példány (node) működik együtt, ezeknek nagyjából a fele redundáns párba szervezett lokális csomóponti szerverként, a továbbiak ezek egyikével, vagy egyes esetekben akár minddel kapcsolatban álló kliensként funkcionál.
Egy helyszín alapértelmezésben egy szerverből (egy logikai node-ot képező két fizikai szerver node-ból) és két kliens node-ból áll. (Ezen felül van két, ettől eltérő kialakítású helyszín, melyre azonban az egyszerűbb átláthatóság érdekében nem térünk ki.)
A blokkvázlat a rendszer SCADA/HMI szempontból releváns arhitektúrájának részlete.
Egy-egy kliens node - szerepkörét tekintve - felhasználói vagy fejlesztői típusú lehet. Előbbi a rutin használatban történő, valós idejű megjelenítési feladatokat látja el, utóbbi pedig a rendszer - akár futásidőben történő - konfigurációját, fejlesztését teszi lehetővé. A szerepkör meghatározása az egyes node-ok gyári-, illetve az azt kiegészítő egyéb, hozzáadott konfigurációs állományai alapján történik automatikusan az adott node indításakor. (A szerepkör szerinti működés szükséges feltétele a megfelelő licensz lízingelése a központi licensz szerverek valamelyikétől, mely előre meghatározott módon történik és a megoldás ismertetése szempontjából nincs további jelentősége.)
Egyezményes alapon, valamennyi kliens node fel van készítve fejlesztői funkciók ellátására (amennyiben azt a lízingelt licensz lehetővé teszi), de üzemszerű működés közben ezt két, dedikált (mobil) kliens végzi, melyeknek egyéb (megjelenítő) feladatuk nincs, és a 22 helyszín, vagy az azt összekötő hálózat bármely pontjában tartózkodhatnak.
A valós idejű adatok gyűjtését a rendundáns párokon futó OPC szerverek végzik, míg a historikus tárolásért a helyszíneken telepített lokális illetve központi SQL szerverek valamint egy 30e pontos GE Historian szerver felel. A rendszernek - rendeltetése okán - szélsőséges üzemi szituációkban is hozzáférhetőnek kell lennie, ami a megvalósítás során számos merőben új vagy a szokványostól eltérő megoldást követelt meg. Mindemellett azonban végig elvárás maradt - a lehetőségekhez mérten - egyszerű és átlátható koncepció.
Amikor egy ilyen feladat szóba kerül, a lehetséges kihívások végeláthatatlan sorában általában valahol a sereghajtók táborát erősítve szerepel a felhasználói felület kérdésköre. Elsőre ez nem is meglepő, hisz annyi megoldandó feladat között ezt hajlamos az ember sokadrangú problémaként kezelni, ugyanakkor, ha végiggondoljuk, hogy a majdani felhasználói élmény (UX) jelentős hányadát adja, minősége közvetlen befolyással bír a felhasználó hatékonyságára és így végső soron a teljes rendszer teljesítményére, akkor a jelentősége szerint máris az elsődleges problémák listáján a helye.
Tárgyi rendszerben ezernél is több kép kezelését kellett megoldanunk úgy, hogy az mind a felhasználó, mind pedig a fejlesztő számára végig átlátható és könnyen kezelhető maradjon.
Felelős mérnökként, kritikus üzemű rendszerek tervezésekor az elsődleges megfontolás mindig a megbízhatóság. Ez azonban jóval túlmutat a megfelelő műszaki megoldások összességén. Az új, modern technológiákat - nyilvánvaló előnyeik miatt - könnyű megkedvelni, de időbe telik kiismerni. Megfigyelhető, hogy az ipari - nem pilot - rendszerekben, a termelési terület jellegétől függően, de általában minimum három-négy, sőt egyes esetekben akár tíz évvel az úttörő megoldások bemutatását követve alkalmazzák azokat. A magyarázat egyszerű: ez az időintervallum már kellően tág ahhoz, hogy alatta valamennyi jelentősebb, rejtett probléma, más rendszerekkel való koincidencia, sérülékenység felismerhető (és a gyártó által javítható) legyen, nem utolsó sorban indirekt bizonyítja a szoftver időtállóságát, így kisebb az esély rá, hogy egy ígéretesnek látszó, ám később technológiai tévútnak bizonyuló és emiatt kivezetett megoldásra alapoznak egy egyébként minimum 10-20 éves életciklusra tervezett berendezést.
A SCADA rendszer gyártója és a rendszerintegrátor egyanazon dilemma előtt áll: versenyképes és mai szemmel "fancy" megoldás vagy a "jó öreg" bevált megoldások. A kettő együtt nem megy. Vagy mégis?
A gyártók úgy próbálják ezt áthidalni, hogy az alapvető / kritikus feladatokat egy már bizonyított technológiával működő motorra bízzák, és az - amúgy is testre szabható - SCADA környezetet alacsonyabb, programozási szinten is megnyitják a fejlesztők számára, hogy az igényeiknek és a feladat természetének megfelelően használják/egészítsék ki vagy épp fejlesszék tovább belátásuk szerint. Erre szolgálnak a különböző API-k, toolkitek, SDK-k és script eszközök. Így viszonylag tág mozgásteret tudnak biztosítani az alkalmazott - akár külső, ún. 3rd party - megoldások tekintetében, mivel egyszerre használható a konzervatívabb, de végletekig megbízható core és akár a legfrissebb technikai megoldás.
Így van ez az iFIX esetében is. Az elsődleges SCADA funkciókért (adatgyűjtés, esemény/riasztáskezelés, stb.) a C kódra épülő robusztus, több mint 20 éve bizonyító és folyamatosan fejlesztett engine felel, de a rendszer valamennyi része hozzáférhető a fejlesztők számára biztosított eszközök, elsősorban a VBA (Visual Basic for Application) script felületen keresztül.
Fenti rövid kitérő azért volt fontos, hogy egyértelmű legyen, hogy az egyedileg fejlesztett navigációs rendszer elsődleges célja nem az iFIX-ben egyébként többféle alternatív módon megvalósítható képernyőkezelés kiváltása volt, hanem sokkal inkább azt, mint stabil alapot felhasználva, arra építkezve egy, az adott feladathoz végletekig illeszkedő megoldás létrehozása.
Az iFIX projekt / HMI szerkesztő, konfigurációs és megjelenítő felülete, a Workspace esetén a létrehozott képernyők elrendezése egymáshoz képest nem hierarchikus, és nem állt rendelkezésre olyan a szoftver részét képező gyári megoldás, amely ezt a projekt elvárásainak megfelelően képes volna ezt rendezni. (A termékhez ingyenesen biztosított Productivity Toolkit ugyan kínál egy lehetséges választ, ám ez első sorban azok számára alternatíva, akik az IT világában egyébként otthonosan mozognak, és például egy fába szervezett - egyébként a maga nemében kiválóan átlátható struktúra kezelése nem riasztja el őket. A végfelhasználók egy jelentős hányada azonban nem tudja ezt magabiztosan használni és legtöbbször már emiatt meg sem próbálja.)
Számunkra tehát adott volt a feladat: Kidolgozni egy olyan navigációs szisztémát, ami képes a relatíve nagy számú képernyőt úgy hierarchiába szervezni, hogy a felhasználó számára az ne tűnjön bonyolultnak, és a komfortérzet a maximális maradjon, mindezt úgy, hogy rendszer hatékony használata sem szenved csorbát.
A kihívásra Hrubi Gyula kollégámmal közösen vállaltuk a válasz kidolgozását, aki végtelen türelmével és szakmai tudásával kétségtelenül a projektet tartó oszlopok egyikévé vált. Az eredményt pedig alább olvashatjátok és akár értékelhetitek Ti is a rendszer felhasználóihoz csatlakozva.
A megoldás összeállításakor számba vettük a rendszer adottságait, a partner elvárásait, mi az, amit az adott projektben lehet- és amit nem, mi az, amit a témában már próbáltunk és mi az, amiben potenciált látunk, végül de nem utolsó sorban pedig mi az, amire a GE iFIX SCADA/HMI rendszer megbízhatóan képes.
Említettem, hogy az iFIX gyári megoldásként kínál egy fastruktúrát alkalmazó eszközt. A helyzet az, hogy hasonlót mi is implementáltunk korábban, elsősorban gyógyszeripari környezetre szabva, melynek célja - a hierachikus szervezésen túl - az volt, hogy a végfelhasználó akár egyénre szabott, önállóan konfigurálható struktúrát hozhasson létre, mindezt úgy, hogy annak konfigurálására futásidőben legyen mód, a Workspace fejlesztői módba kapcsolása nélkül. Az így kialakított eszköz mérnöki szempontból jól teljesített, azonban felhasználói oldalról nem váltotta be a hozzá fűzött reményeket, a lefejlesztett funkciók jelentős részét sosem használták a gyakorlatban. Ami mégis kiemelte a projektet, az a menü mögé felépített SQL adatstruktúra, mely az egyébként - navigációs szempontból - egydimenziós iFIX képernyőkezelést számtalan új lehetőséggel egészítette ki.
A képernyők adatstruktúrában való kezelését ezúttal (is) evidens megoldásnak tekintettük, azonban az egyes HMI node-ok fallback üzemben elvárt működése a központi az egyes helyszínektől független kezelés kérdését jelentősen megnehezítette. Az első megközelítés szerint itt is az SQL-re támaszkodtunk volna úgy, hogy a “szigetüzem” elvárás kérdésének a menürendszert kiszolgáló, annak felépítését tartalmazó háttéradatbázis egyes helyszíneken található szerverekre történő leosztásával (SQL Replication) teszünk eleget. Bár a megoldás stabil és elegáns, de a megrendelő számára túlzottan összetettnek bizonyult, így más alternatívát kellett keresni.
Mielőtt a megoldás lényegi részének ismertetésébe belekezdenénk, annak könnyebb megértése kedvéért fontos tisztázni mit értünk a képernyő szó jelentése alatt. A SCADA szoftverek általában megkülönböztetve kezelik a megjelenítő (monitor, TV, stb.) és a képernyő vagy kép fogalmát. A szoftverekhez mellékelt felhasználói kézikönyvek többsége angol, ahol a monitor, screen és picture kifejezések írásképben/hangalakban is markánsan eltérnek egymástól, míg ha magyarul a képernyő vagy kép terminusokat használjuk, ez - egy bonyolultabb szövegkörnyezetben - könnyen összezavarhatja az olvasót, különösen ha azt vesszük, hogy a képernyőt a monitor - mint tárgy - szinonimájaként is gyakran használjuk.
Az iFIX esetében egy képernyő (picture) egy grafikus objektumokat és azok működését meghatározó programblokkokat tartalmazó konténer. A felhasználó a képernyőn grafikus elemeken keresztül megjelenített információkat valamilyen elv szerint összerendelt adatforrások logikai csoportja felett értelmezi, így általában a képernyő kialakítása, elrendezése, meghatározott aspektusból reprezentálja azt. (pl.: egy gyártósor egyes állomásainak áttekintő képe, vagy egy raktár alaprajzának megjelenítése a rajta lévő hőmérséklet érzékelőket szimbolizáló adatpontok megjelenítésével)
A képernyő nem szükségszerűen tölti ki a megjelenítő teljes hasznos területét, sőt bevett gyakorlat, hogy egy monitor 3-4 képernyő megjelenítését végzi egyszerre. A felosztás - szemben egy CCTV rendszernél látott kép-a-képben vagy mátrix alapú elrendezéssel - itt elsősorban funkcionalitás alapján történik. A megjelenített képernyők közül van, amelyik kvázi statikus és/vagy a rendszerre vonatkozó általános információkat tartalmaz, mások a képernyők közötti navigációt segítik, megint mások a kapcsolódó rendszerekre nézve technológiai adatokat szolgáltatnak. Cikkünkben a továbbiakban a fenti megközelítésben használjuk a képernyő fogalmát.
Az XML, amely bár kezelési, kényelmi és távlati szempontokat figyelembe véve nem összemérhető az előbb ismertetett megoldással, az adott feladatra mégis kiválónak bizonyult. Minden nodecsoport (vagy akár node) rendelkezik egy hozzá szerepköre alapján kapcsolódó XML leíróval, amely a nodenév nomenklatúra és egy konfigurációs állomány megfelelő paraméterei alapján egyedileg beazonosítható, és tartalmazza az adott node számára szerepköre szerint elérhető hierarchikusan szervezett navigációs struktúra modelljét. A központi szerkesztés a fejlesztői node-on keresztül valósul meg és automatikusan kerül leosztásra az érintett kliensek számára. A XML fájl minden esetben lokálisan elérhető, így a funkció egy esetleges leszakadás esetén is működőképes marad.
Az ötlet alapjában véve jó, de mi kerüljön a leíró állományba?
A kérdés egyszerű, a válasz mégis összetett:
Az első verzió - elvárások hiányában és az egyszerűség elvén - csupán a képernyő “felhasználóbarát” megnevezését, és a kapcsolódó képernyőt tartalmazó konténer fájl nevét tartalmazta, ám ez hamar kibővült. A prototípusok működési tesztjével nagyjából egy időben érkezett ugyanis a kérés, hogy a navigáció - egy esetleges riasztási esemény bekövetkezésekor - legyen képes “útjelzőkkel irányítva” elvezetni a felhasználót a megfelelő képernyőkre. Maga az elgondolás nem újkeletű, a hagyományos HMI navigáció során gyakori, hogy egy-egy képernyőről egy másikra vezető parancsgomb az adott terület riasztási eseményei alapján (is) animált. Az iFIX gyári megoldásként kínálja és ajánlja a riasztási területek használatát, így nem volt más dolgunk, mint ezeket is integrálni az XML állományba. Itt viszont egy nem várt kihívásba ütköztünk, melynek megértéséhez előbb azonban még fejezzük be a képernyőstruktúra működésének elemzését.
Az ilyen méretű rendszereknél belátható, hogy egy-egy felhasználói csoport számára nem az összes terület / funkció (és így képernyő) releváns, hanem azok egy relatíve kis csoportja. Jelen esetben a szervezés nem (kizárólag) jogosultságon, hanem a rendszer architektúrájának elvi szervezésén alapszik: egy adott csoport adott, kis mennyiségű (~ n x 10 db) képet kíván elérni. Ennélfogva számukra az összes képernyő felkínálása nemcsak fölösleges, de zavaró is. Erre választ egyrészről az XML maga ad, másrészről az azt felhasználó navigáció képernyőt úgy kellett kialakítani, hogy mindig csak az adott csoport számára releváns elemeket jelenítse meg, viszont a nagy számú node miatt az óhatatlanul jelentkező káros redundanciát maximális mértékben kerüljük el, a repetitív dolgokat pedig "by design" elimináljuk. Ezt úgy valósítottuk meg, hogy maga a navigációs képernyő ténylegesen is egyetlen képernyő objektumot használ, melynek tartalma valós időben, az XML állomány függvényében renderelődik, követve a felhasználó mozgását a logikai képernyőfában (azaz az XML által leírt struktúrában).
Az iFIX rendszerben egy-egy grafikus objektum animálása valamilyen adatforrás alapján viszonylag könnyedén megoldható, az adott objektum tulajdonságainak túlnyomó többségét lehetőség van akár kifejezés alapon egy tetszőleges forrás aktuális állapotának megfelelően automatikusan változtatni. Ezek a források legtöbbször statikusak, futásidőben a módosításukra nincs szükség. Ha mégis, akkor erre több lehetőség kínálkozik:
A legtöbbször előforduló igény, hogy egy-egy általános szerepet betöltő képernyő (pl.: szivattyú állapotának megjelenítése) egy adott típusú adatforrás valamennyi példányára sablonszerűen alkalmazható legyen, azaz ne kelljen minden egyes darab felett implementálni, elég legyen a hozzá tartozó adatforrásokra linkelve a sablon alapján automatikusan generált külön képernyő példányt létrehozni. Erre gyári megoldásként elérhető az ún. TagGroupok használata, mely során a linkeket szimbólumokkal helyettesítve a képernyővel - akár futásidőben váltogatva - kezelhetünk több különböző, de struktúrában megegyező eszközt.
Ezen felül az iFIX Workspace mögött futó VBA környezet segítségével mód van egy-egy objektum animációs forrásainak scripten keresztül történő megváltoztatására.
A menüstruktúra renderelése szigorú értelemben véve nem berendezésekre és az azok felett értelmezett működési paraméterekre linkelő forrásokra épít, így első nekifutásra mi a VBA-t választottuk, ami látszólag teljesítette is az elvárásokat, azonban a tesztek során szembesültünk vele, hogy a kirajzolás folyamata még akkor is kimondottan lassú, ha az adatforrások állapotát nem egyenként, hanem a csoportos olvasást megvalósító FDS objektum közbeiktatásával valósítjuk meg. Más megoldás kellett, ami kikerüli a VBA-t és annak egyik legnagyobb hátrányát, az egyszálas folyamat kezelést.
Itt egy kicsit elakadtunk. A koncepció átalakításával kapcsolatosan felmerülő ötletek alapjaiban rázták meg azt és a menü a későbbi fejlesztés során történő használatát körülményessé tették volna.
Biztos Ti is megfigyeltétek már, hogy egy-egy ilyen probléma megoldása testközelből, célzottan milyen nehéz tud lenni, míg eltávolodva tőle, indirekt módon sokszor csak úgy “beugrik”. Velünk is ez történt.
Partnerünk részéről két, több évtizedes szakmai múlttal rendelkező szenior kolléga tartja szárnyai alatt a projektet, akikkel az aktuális ütemezés függvényében heti, vagy akár napi szintű konzultációk során keressük közösen az épp fennálló problémákra adható optimális megoldásokat. Ez a kapcsolat tökéletes példája annak, hogy a jó mérnököt nem csupán egy adott területhez kapcsolódó direkt szaktudása, hanem (sokkal inkább) az általános értelemben vett problémamegoldó képessége, a probléma megoldásának szisztematikus keresése és az arra történő rávezetés képessége minősít. Ezek a beszélgetések rendkívül fontosak nem csak a projekmenedzsment, vagy a szakmai kapcsolatok, de az inspiráció szempontjából is.
A felmerült problémát eléjük tárva hosszas ötletelés vette kezdetét, melynek során - a szó legpozitívabb értelmében vett - kívülállóként próbálták velünk együtt keresni a probléma feloldását. Azzal, hogy őket nem kötötték azon gondolatmenetbeli konvenciók, amelyekkel egy iFIX-szel egyébként napi szinten dolgozó fejlesztőmérnök megszokásból együtt él, olyan aspektusokat és támpontokat vittek a beszélgetésbe, amely végül egy magunkban három másodperces gondolatsor eredményeként adta az egyébként utólag kézenfekvő megoldást.
Az animációs forrásként szolgáló Alarm Area-k továbbra is az XML leíróban, a struktúra részeként találhatóak, azonban a futásidőben történő felhasználásuk egy erre a célra dedikált TagGroup file tartalmának valós idejű (újra)generálásával történik, a képernyő tartalmának frissítése (azaz a navigációs fában történő váltás) végrehajtását közvetlenül megelőzve, de annak szükséges feltételeként. Az említett TagGroup file feldolgozása natív C engine oldalon történik, így a VBA kódnál tapasztalt problémák itt nem jelentkeztek.
Külön érdemes megemlíteni (mintegy igazolásként), hogy az így kialakított megoldás mellesleg jóval egyszerűbb és letisztultabb kódot eredményezett, mint az eredeti elképzelés.
A menüstruktúra leképezésén felül akadt néhány direktíva, amely nem elsősorban a programozási, mint inkább a tervezési területen állított minket kihívások elé.
A Com-Forth Kft. nagyjából három éve döntött úgy, hogy az iparban, Magyarországon akkor még teljesen újszerű, ismeretlen megközelítésnek számító High Performance HMI paradigma szerint kezdi fejleszteni a felhasználói interfészeit. Ez az elhatározás azóta többszörösen bizonyított, így ebben a projektben sem volt kérdés az alkalmazása. Annak ellenére, hogy a speciális területből adódóan felmerültek olyan koincidenciák, amely miatt egyes irányelveket szabadabban kellett értelmezni, a projekt egyik komoly sikereként könyveltük el, hogy mind partnerünk, mind pedig a végfelhasználó nemcsak elfogadta az így kialakított felületeket, de a projekt folyamán el is köteleződtek a szemlélet mellett.
A kialakított menürendszer megjelenítése bár elsőre puritánnak tűnhet a szürke különböző árnyalataival operáló megjelenítéssel, különösen ha a ma - akár csak az alaplapra integrált - videóvezérlők és úgy általában egy átlag asztali munkaállomás képességeit tekintjük, azonban ezzel elértük, hogy mind az aktuálisan kiválasztott, mind pedig az esetleges riasztási eseményt tartalmazó elem csupán a színe révén (kék / illetve prioritástól függően narancssárga, citromsárga, türkiz) szignifikánsan kitűnjön. Így a navigációs sáv megnyitását követően egyetlen pillantás elég az aktuális állapot áttekintésére és nagyjából ugyanennyi idő alatt egyértelművé válik a felhasználó számára, hogy a menüben merre kell továbbhaladni ahhoz, hogy az eseményt kiváltó elemet tartalmazó technológiai képernyőre eljusson.
Maguk a navigációs gombokat szimbolizáló primitívek (körök és négyzetek) méretüket tekintve úgy lettek definiálva, hogy a felhasználási pontokon telepített megegyező típusú, adott képátmérővel és felbontással rendelkező érintőképernyős monitorokon a kezelésük - egy átlagos felnőtt ujjméretetét figyelembe véve - kényelmes, hibatűrő és ergonomikus legyen.
Bár ma már a 16:9 képarány megszokott, mely kedvez a horizontális képernyő-elrendezéseknek, a menüsáv megjeleníthető és elrejthető annak megfelelően, hogy a felhasználónak az adott pillanatban szüksége van-e rá, így a megjelenítés szempontjából leghasznosabb terület mindig az elérhető maximális marad.
Az “i”-re a pontot annak a dashboardnak keresztelt, állandóan a felhasználó előtt lévő, a rendszer általános kezelőszerveit tartalmazó keretfelületnek az ergonomikus, lekerekített, letisztult formákat alkalmazó kialakításával igyekeztünk feltenni, amellyel - azt gondolom - sikerült kihozni az iFIX Workspace-ben ebből a szempontból rejlő lehetséges maximumot.
Már maga a nagyszámú képernyő és a többszintű hierarchia megkívánta, a menü elrejthetősége pedig egyenesen szükségszerűvé tette, hogy az aktuálisan megjelenített képernyő rendeltetéséről a felhasználó az azon található elemekből való következtetésen túlmenően is információval rendelkezzen. A kisebb rendszereknél ezt általában a képernyő alsó vagy felső részén elhelyezett statikus, ritkább esetben dinamikus fejléc célú szöveges objektummal megoldják, azonban itt az XML struktúra ennél valami sokkal többet kínált. A renderelés során a dashboard különálló fejléc képernyőjében egy erre a célra dedikált szöveges objektumába dinamikusan, egy változó közbeiktatásával futásidőben kerül betöltésre az éppen aktuális képernyő felhasználóbarát elnevezése a hozzá tartozó útvonallal együtt. Így külön a kódba ágyazott információk nélkül egyszerre van mód megjeleníteni a képernyő nevét és azt, hogy az a hierarchiában hol található. A webes fejlesztői múlttal rendelkező kollégák persze egyből rávágják, a breadcrumbban nincs semmi forradalmi, azonban ennek desktop SCADA/HMI rendszerekben történő alkalmazására jóval kevesebb (használható) példát lehet hozni.
A funkció fejlesztése - sok más egyéb között - megerősítette azon meggyőződésünket, hogy a HP HMI paradigma szerinti felhasználói felület megvalósítása túlnyomórészt - neve szerint - elsősorban gondolkodás- illetve szemléletmódbeli kihívás, nem pedig egy szoftvertermék által kínált dobozos megoldások meglétének kérdése.
Bár a GE az iFIX Workspace esetében is igyekezett a fejlesztők munkáját egyszerűbbé tenni a tekintetben, hogy különböző “out-of-the-box” grafikus objektumcsaládokból álló dynamo készletekkel egészítette ki a rendelkezésre álló repertoárt, azonban ez önmagában tárgyi projekt esetében sem tervezés, sem implementáció tekintetében sem volt elég.
Ennek ellenére - kisebb kiegészítésekkel - a Workspace is bőven képes kiszolgálni az iparban még csak szárnyát bontogató HP HMI paradigmaváltással érkező új igényeket, a nem túl távoli jövőben pedig már valószínűleg az Operations Hub használatával ez tovább egyszerűsödik.
A hétköznapi életben számos olyan megoldást használunk, melyek egy az egyben átültetve elképzelhetetlenek egy SCADA rendszer részeként, azonban megfelelő módon adaptálva, a “valahonnan ez ismerős” érzését adva intuitívvá, egyértelműbbé, felhasználóbarátabbá tehetik egy első ránézésre bonyolult rendszer kezelését is. A szituáció feletti kontroll érzése a magabiztos kezelés elengedhetetlen feltétele, a magabiztos felhasználó pedig hatékonyabban végzi a munkáját.
Ezúton is köszönöm kollégáim, Szalárdy Zsuzsanna, Hrubi Gyula és Sós András segítségét akik nélkül az fenti cikk nem születhetett volna meg.
